HMart
-
Posts
1560 -
Joined
-
Last visited
-
Days Won
11
Posts posted by HMart
-
-
Merry Christmas to all.
-
2
-
-
On 12/13/2022 at 9:51 PM, stgatilov said:
What's the point of instancing?
Ask yourself: how often you see many objects with exactly the same model in one view?Instancing may not be necessary for TDM dark and relative small spaces, but afaik, before UE5 nanite tech, was the only way using conventional polygon rasterization, to be able to render large open scenes. Scenes filled with large amounts of vegetation and other stuff, ala Crysis and others, those games are filled with cloned/instanced geometry all over the place and personally, I don't remember people strongly complaining about them felling very repetitive.
That's because there's ways to break the repetition and make the scene feel more unique/varied, even if they are just rendering hundreds or millions of the same geometry/model.
Just look at this IMO fantastic in-game forests scenes, in the medieval simulator game, Kingdom Come Deliverance. These are made in Cryengine 3.x, using instanced geometry and Imposters.
-
1
-
-
On 12/4/2022 at 2:25 PM, MirceaKitsune said:
making a func_static go to different rotations
Func_statics are the wrong entity for that, those are optimized and used for static objects, meaning objects that don't move at all.
What you want is to use a func_mover, these don't move unless you script them to move but they are specially handled by the engine and have dedicated script code that func_statics don't have, for example func_movers have special rotating functions called RotateDownTo, RotateUpTo, RotateOnce, etc and special moving functions as well, those should be defined in TDM_events.script.
Btw don't confuse with func_movable that is for rigid body physics objects only.
-
14 minutes ago, kano said:
Thanks for the improvement to stencil shadows; any and all improvements are always appreciated.
That being said, I'm actually surprised that the team isn't preparing to kill stencil shadows entirely. I know it would render the game unplayable on old hardware, but hardware that old will struggle to play the game anyway. And with a full transition to shadow maps, more pretty graphical features can be implemented (like the volumetric shadows and hopefully eventually transparent materials casting shadows), and manpower can be focused on improving one shadowing method instead of two.
Not only do I think it's a great idea to drop stencil shadows, but I also think it would be cool to have a checkbox/option in the editor to allow materials that make use of alpha textures like leaves and grass to cast accurate shadows. Making this into an option that must explicitly be switched on by a mapper would avoid screwing up existing missions that were designed without said functionality in mind, as someone else pointed out, while simultaneously opening up new options for mappers who are creating new content today.
However, the biggest downside to what I am proposing is that shadow maps really tax the GPU and tank performance hard, especially if you crank the quality. It is probably the most impactful performance setting in the game.
I agree and I remember saying something similar before and the answer if I recall correctly was, stencil stays in, that was a few years ago, and they add (and still have) very valid reasons, one was because maps in TDM, was still in its infancy and not well optimized, but it has improved much since (stencil also with the soft shadow option).
Thou I know this is not a easy decision for the team, you can't just delete the stencil shadow code and everything will be fine, TDM age and success, is also a big problem for the way it handles shadows, because of how old and popular it is, it has hundreds of assets and missions made, with stencil shadows alone in mind, changing those assets today (materials mostly), in particular those with alpha enabled, will require free work, from someone, and will also with no doubt, break shadows in all missions made until now and not forget, decrease performance, by the simple fact that, more stuff that didn't cast shadows, trees, grass, banners, decals, etc, now will and some of them shouldn't, so the missions will have to be updated, and it may never happen if the mission maker is gone. Is not a easy problem to solve.
SpoilerBut having said that, to me, not removing stencil shadows, will forever be "a torn in TDM feet", why, because of its existence, shadow maps, the better tech IMO, will never be the main focus for shadows, condemned to be a after thought, so never used to its full potencial, mission makers will forever be forced to make their missions, with stencil shadows limitations in mind, meaning alpha mapped materials, will never cast shadows. (unless they are willing to go to the trouble of modifying the assets themselves and override the default ones from TDM in their mission, afaik is totally possible)
-
56 minutes ago, MirceaKitsune said:
Thanks, that was it. Set the model to it directly as that's easier and seems better than creating a fake brush.
One problem then however: Some signs swing in the wrong direction. Seemingly there's no way to override the angle... the entity suggests an "angles" spawnarg, I tried setting it to either "90" or "90 0 0" but neither affect it. Any thoughts?
(250.86-306.53182.09).thumb.jpg.d8467baeb7ba21461d8e2b5d47e3ca50.jpg)
Looking at the func_pendulum c++ class, shows that it doesn't care or use angles var for anything. So the only thing I can think right now, to solve this, is to bind the visible entity, to a invisible pendulum mover, moving in the direction you want the visible one to follow, its own axis doesn't matter (visually but do matter to the pendulum movement), you can even make it a brush box. Hope you get what I mean.
Also here is a old Doom 3 pendulum tutorial that I found, I didn't bother to search in TDM wiki, so perhaps there's one there as well, but just in case see if this helps.
-
1
-
-
To add to frost_salamander reply about performance, game objects/entities, created by native c++ code and used in editor, through the entity definitions func_* whatever, imo should be faster than a custom pure script based object, for the simple reason that like I mentioned, they are made/call directly from a c++ based class, and c++ is objectively faster than DoomScript.
-
On 9/6/2021 at 10:33 PM, Dragofer said:
The question is, would it be possible to store these LOD distances within the model file?
Sorry for the extremely late reply to this.
First not that any of this matters, as I don't think LOD's will ever be done in this way, but for academic reasons, you don't need to save LOD distances in the model, just hardcode in the engine c++, reasonable default distances for each layer and give the ability to change them later if necessary, like always editor entity spawnargs, but if the defaults are well thought out, you the mission maker, probably wouldn't even need to mess with the distances most of the time, everything would be automatic for the mission maker, like the shadow and collision model.
And please to everyone reading, even thou this may sound cool, don't think any of this is easy to code, because is not. Many times making life easy to the end user, requires a ton of work and knowhow from the coder.
But the answer to the question is yes, how to do it, does depend on the format you are exporting.
SpoilerI personally only use lwo for static models and I know by reading the c++ code handling the lwo, that how it is used by the engine, is very underutilized, many of its information capabilities are ignored by the model parser, only caring about the required info for the static models, but the parser, as is written, is still capable of reading more from the file, than is used in the end.
For example, it detects all extra layers in a lwo file and goes to the trouble of saving them into a list for later use, but the following code reading the list, only cares about and handles the geometry info in the first layer and skips the rest, but even so, there's some Doom 3 lwo models, with extra layers, but they were obviously only used, as save/store slots for extra geometry, for the modeling software, info that the idSoftware artist may wanted to use or not later.
The lwo parser, also detects and saves into a list, extra polygon tags but ignores most of them, only caring about the smoothing group info and is this polygon tags, at lest as used/done in Luxology Modo, that imo could be used to encode the LOD distances. Polygon tags is a lwo powerful feature, for example there's a modo plugin/tool to create user GUI's for custom tools, a tool made by Seneca a idSoftware artist and it uses polygon tags (strings) to create GUI cards from geometry from within Modo itself, imo the guy is not only a excellent artist, is also a good programmer!
Another way would be name each LOD layer, with the distances range in it and parse the name string, for example that is how Frictional Games made Penumbra, using only Maya to make the levels, all their models used special layer/mesh names and sufixes/prefixes.
-
11 minutes ago, nbohr1more said:
It seems that there is a reverse engineer group ( Amernime \ Nimez ) who are back-porting newer AMD drivers to older GPU versions. Terrascale 1 support is currently a "work in progress" :
If you are interested, they might have beta versions up on their terrascale discord. The downside is that these are community created drivers rather than official ones by AMD.
Maybe AMD will release some sort of maintenance for terascale like they did for some of their other old GPU's.
That's cool,
I remember when i was a kid installing modded GPU drivers on my ATI GPU, the same with my Audigy Creative sound card that enabled stuff that they only add available in more expensive models.
But personally today, I'm not sure if i would do that, call me paranoid but with all the cripto and nft bs going around, I want such software to come from a reputable source, at lest one that has much to lose if caught doing bs. But that is just me.
-
Sorry if I felt a tad sensitive also, today was not a good day on the job, a tad stressed. But you are not to blame.
-
32 minutes ago, stgatilov said:
Good story, but it does not explain why they copy/pasted the whole section of C++ code instead of adding second string comparison with OR operator in the condition for the existing section.
Don't know if it was your intention but this reply makes it sound like I'm lying or something! Or I'm just reading it wrong? If I am, sorry for my reaction, but is hard to detect intention in text. If I'm not, then I'm not asking for you or anyone to believe me and I even said that.
Why they copy pasted the entire C++ code instead of reusing? Only the original programmer knows that, but perhaps they were to be different in some special case that never came to happen? Just assuming here.
And yes they totally could just have parsed the same keywords in the same c++ code, and in the Quake4 editor (made by Raven software) that comes with Doom 3, they do that.
else if ( !token.Icmp ( "definefloat" ) || !token.Icmp ( "float" ) ) { idToken token2; idStr result; if ( !src.ReadToken ( &token2 ) ) { src.Error ( "expected define name" ); return false; } idWinFloat var; idUserInterfaceLocal ui; idWindow tempwin ( &ui ); idStr out; src.SetMarker ( ); tempwin.ParseExpression ( &src, &var ); src.GetStringFromMarker ( out, true ); wrapper->GetVariableDict().Set ( token + "\t\"" + token2 + "\"", out ); continue; }I Just know for certain is that Quake4 removed definefloat (at lest is not discussed in their wiki) and QuakeWars removed definefloat and definevec4 entirely, for float and vec4 respectively.
And what about what I asked about supporting vec4 keyword in TDM guis?
-
On 11/13/2022 at 4:10 PM, stgatilov said:
...
I don't understand why two keywords "float" and "definefloat" exist.
In the code, there are two identical pieces of code for handling them.I don't have a link and don't take my word for it but I remember this being discussed in the old Doom3World forum and I clearly remember a idSoftware dev saying that definefloat keyword came early, while the script and gui language was being developed, later they decided to support the keyword float alone but because many in world GUI's, were already made with the older keyword, to not waste time converting things that already worked they decided to let it stay, despite doing the exact same thing.
Why they made "float" to replace "definefloat" but not "vec4" to replace "definevec4", is something that I always wondered why.
What would be your opinion and doing that yourself? Meaning instead of "definevec4" users can write just "vec4" in new GUI's, just like in QuakeWars, thou this last one also supports, vec2 and vec3 but not sure if those are something useful in TDM case.
-
4 hours ago, datiswous said:
I guess you could also use this for different colored animals for example?
Yes it could but wouldn't using the skin system be better for that?
I know that using the colored system, permits to do variable colors very easily, good for carpets, flags, cloth, etc and also only have a single material, but if your idea is to make more varied looking characters, with a single model, I think the skin system is better, it means more materials need to be created but it also means more flexibility and power.
The skin system is very powerful, was designed exactly to make different material variations for a single model and it does way more than just swap colors, you can have characters that look somewhat different geometrically, by hiding or showing hidden peace's on a model, etc.
On a animal for example you can have a model with fur and another without it by just hiding the fur geometry, or one with a collar on his neck and another without it, without swapping models, just the skin.
-
10 minutes ago, vomoc said:
I can play thief 3.And i can play doom 3 with lowest graphics setting.But i cant run doom 3 BFG edition.
The fact that you can't play Doom3 BFG explains why you can't play modern TDM, afaik both use more or less the same OGL system, thou TDM has since surpassed even BFG graphics.
Also if I'm not mistaken Thief 3 is not even a OGL game but a DirectX 8 game, it uses Unreal 2 engine, Doom 3 is a OGL 1.4/2.0 game that came out in 2004 and you already have to play it at lowest graphics settings!? Man that means your GPU is just to slow, I assume is a laptop?
-
9 minutes ago, vomoc said:
Radeon HD 3000 support:
OpenGL -- 3.3
Direct3D -- 10.1
Shader model -- 4.1
So?can i play this game?any solutions?
The fact you really can't update drivers and not even OGL 3.2 seams to be fully supported, the only solution for now that I can think of, is to play a older version of the game, one that still has support for the original Doom 3 render based on OGL 2.0, but I don't remember which one, others may help better.
Playing a older TDM, does means you will be unable to play the more modern missions, but even so, your GPU is very old anyway and would very probably suffer with the more heavy modern missions and there's still plenty of older ones that are very nice to play.
-
Unfortunately his are the latest available drivers. But yes based on this link the Radeon HD 3000 should be OGL 3.3 compatible, is TDM using some non core extensions?
-
I saw totally unrated movies as kid, in national TV, even porn movies and didn't turned into a sexual deviant or a murderer, with such restricted age rating and censorship that we have today, we still have as many sexual deviants and murder cases today, perhaps even more (thou I think that is because they get reported more now) then we add when I was a kid. Just my opinion.
-
Write what stgatilov says, I didn't looked at the code like he did, only transmitting what idSoftware has said themselves in their old wiki but even their employees, could have been wrong when writing that or it did worked like that but then they updated the gui handling code and forgot to updated the wiki.
Only way to be sure, is to look at the c++ code and or test a GUI.
-
4 hours ago, stgatilov said:
namedEvent: I got the same idea myself at some moment.
Something like this.
QuoteguiCommandDef_t commandList[] = {
.....
{ "namedEvent", Script_NamedEvent, 1, 1 },
.....
};/*
=========================
Script_NamedEvent
=========================
*/
void Script_NamedEvent(idWindow *window, idList<idGSWinVar> *src) {
auto* parm = cast(idWinStr*)((*src)[0].var);
if (parm) {
window->GetGui()->HandleNamedEvent(parm->c_str());
}
}not sure if well done but works for me and was really easy, don't know why idSoftware never implemented it originally, seems very obvious and useful, only Quake 4 has similar ability.
edit:
Took a fast look at the wiki being done and saw this there...
QuoteHMart in Ref 10 recommended TDM try to implement a way for GUIs to "use colors defined with #define on transitions as well [as float parameters], instead of having to use definevec4 in the Desktop window."
That is wrong and not what I recommended at all, if I passed the wrong idea then my bad, was not my intention. What I really said, is exactly the contrary, what i said is that I add problems using, in this case colors, defined with preprocessor macro #define in transitions, only when using definevec4 for that coupled with the $ sign did they work. But the better and widely used method by idSoftware was to input color values directly!
Also #define macros aren't really "float parameters", like definevec4 or definefloat, they are exactly like C macro preprocessors like stgatilov said, just text substitution.
-
3 hours ago, stgatilov said:
Speaking of putting double-quotes vs not putting them: I think it is a good idea to enclose every item in double-quotes.
Literal numeric values are perhaps the only exception.I remember some idSoftware dev on Doom3World forum saying exactly that, they also said that in
float "somevar" "0" the "0" is ignored
QuoteAdditional user variables may be defined with the 'definevec4', 'definefloat', and 'float' commands. Note you cannot set the initial value for the variable (it will always be 0). There are guis in Doom 3 that specify an initial value, but it is ignored
From iddevnet, but you can look at the c++ and see if is true or not just to make sure.
3 hours ago, stgatilov said:The section User Variable says this is OK syntax:
float crouch_scale=0;
I'm sure this is not correct, and hope that recent dev builds produces a warning on it.
That is indeed not correct, unless is for Doom script...
idSoftware says for Gui script user var definitions you should do:
float myfloat
or
float "myvar" "0" // see above about zero or other value being defined here at user var definition
3 hours ago, stgatilov said:
String comparison section says that there is some special "quoted comparison operator":if ("LSGSaveGameNameEntry::text" "!=" "") {
I don't recall seeing anything specific regarding double-quotes around operators.
Hum you maybe right but Doom 3 main menu does uses that "!="
if ( "SGC1Title::text" "!=" "" ) { set "forecolor" "0.6 1 1 1" ; set "SGCBtn1EdgeG::matcolor" "0.5 0.7 0.8 0.5" ; set "SGCBtn1BorderG::matcolor" "0.5 0.7 0.8 0.5" ; set "SGCBtn1CornerG::matcolor" "0.5 0.7 0.8 0.5" ; set "noevents" "0" }3 hours ago, stgatilov said:There is Multiple If section, which totally lacks the most important caveat of GUI ifs that usually kills all attempts of writing any complicated logic in GUI scripts!
While you can write expressions inside If conditions (and now also on the right side of Set command), they are evaluated not when you normally expect it to!
All the expressions are evaluated before script commands are executed. So if you Set the value of "gui::myvar" from 0 to 1, the following "if (gui::myvar)" will still be considered false.
I believe all the expressions are evaluated at the same time, regardless of whether they are on the right side of property definition (aka 'visible "gui::LootIconVisible"') or inside script.This is very important to understand when you write expressions, since normal people assume that script commands are evaluated sequentally, and their changes are propagated immediately.
And yes, you can write nested ifs, but with the caveat of early evaluation they probably won't give you much.
This is awesome info and explains why some of my ifs didn't seem to do what i expected.
but is that
Quote"gui::myvar" from 0 to 1, the following "if (gui::myvar)" will still be considered false
still true, if you change it through c++, using "_gui->SetStateInt("gui_var", value);" or is only when doing it from Doom Script?
-
Hey thanks that does teach me a lot about how the gui language works and clears some things, thou I did knew definevec4 was not a macro, that is why I put macro, word within quotation marks.
-
I have not read your wiki about the gui scripting, so sorry if this was already known by you and talked about, but if not, imo is always good to know that gui scripting language, can do a little more than what idSoftware used and talked about. Unless i failed to see where idSoftware talked about this stuff.
I discovered this by accident, when I tried a few stuff that Doom Script supports, to see if they worked with gui scripting and they did.
For example the gui language, other than #include also supports #define, just like Doom Script, thou in a more limited way, so you can do basic text substitution using #define like:
#define COLOR_WHITE 1,1,1,1
#define WIND_HEIGHT 480
#define WIND_WIDTH 640
or more complex
#define RECT_SIZE ((WIND_HEIGHT/2)-(320/2)),((WIND_WIDTH/2)-(240/2)),320,240
then used as:
rect RECT_SIZE
-----------
It also has basic support for pointers! using $ sign, example:
transition "start_white::matcolor" "$Desktop::COLOR_WHITE" "$Desktop::COLOR_BLUE_07" "1000";
and other capabilities that I may be forgetting, have not messed with gui scripting for ages now.
Thou i remember macro and pointers support was not free of problems, there's some idiocentricities with this stuff, for example macros using #define and defined in the global space, meaning outside the main desktop windowdef or any other windowdef, work globally and are accessible directly by name (just like in Doom script), but seem to work, only in some things, like "rect", "backcolor" and others but not in transitions, I remember having trouble with those, the only thing that worked well for this ones, was defining the "macro" in another way, like this and inside the main desktop windowdef:
definevec4 "COLOR_WHITE" 1,1,1,1
Despite #define COLOR_WHITE 1,1,1,1 and definevec4 "COLOR_WHITE" 1,1,1,1 looking similar and apparently do the same thing, behind the scenes they seem to be handled totally differently.
I don't claim to have tested this macro stuff very deeply but imo has potencial to make gui scripting life easier, but caution in the few tests I made, transitions using macros, were the most unstable GUI feature, they work the best inputting values directly, specially because those are separated by spaces not commas. Thou using pointers like I show above, even using colors defined using commas worked, sometimes...
I think this, spaces versus commas, most be why macros and pointers were mostly ignored by idSoftware, most of their GUI's only use a "safe" subset of the GUI script language and I unless I missed it, I never saw #define being used in any of their gui's.
But they do work in the basic tests I made, Gui scripters just need to be aware of the limitations.
-
1
-
-
4 hours ago, datiswous said:
I must say, I expected a much smaller map. The frob-animated boxes are cool.
That brought some memories
is a very old test map/thing that I used to learn DR and TDM modding, I spend a few weeks messing with it only. I add almost no idea what I was doing the scale is all wrong for example. Thou If I remember correctly, this test map has at lest 2 or 3 custom models that i made that I don't recall ever being used on any real mission, would be a petty if no one took a look at them to see if they are of any use.
Btw those frob-animated boxes, were my first foray into coding and Doom Scripting, also trying to code any ingame interaction with the language, to see if i could do it, so the script code logic most be a absolute mess and perhaps hardly useful but happy you find it cool.
-
1
-
-
Personally I don't like depth of field, in real gameplay at lest, for screenshots and cinematics is fine but if you want to try including it yourself, sikkmod for Doom 3 has a ARB shader for it, so if you learn basic Doom 3 ARB and TDM GLSL shader code, you could translate it to TDM, both engines follow the same basic principles.
-
2
-
-
11 hours ago, SeriousToni said:
Im always confused which one is better. Stencil or mapped shadows. I can't even tell which I chose right now in the game. Could this be renamed for 2.11 to just shadow quality high and low maybe?
IMO that is not a good idea, stencil shadows and shadow maps, are two totally different things, technically and visually, putting them both under a single shadow quality option, IMO is not correct and may lead to way more confusion by mission makers.
SpoilerStencil shadows and shadow maps, have visual diferences and IMO you cannot say one, is higher quality than the other, depends on preference and implementation.
Stencil shadows look very sharp (if you disable soft shadows), no matter the quality level, maps can look very pixelated if you use lower shadow map sizes.
Stencil shadows is extruded geometry (triangle mesh's).
Shadow maps is textures simulating shadows (there its perfect support for alpha mapped materials).
The only reason some may think, stencil and maps are the same, is because afaik, in TDM the team is forced to limit shadow maps to what stencil shadows can do. What I mean by this is, for example, transparent textures, grass, tree branches and other stuff using alpha maps, shadow maps support those perfectly, stencil shadows don't, so because TDM started historically with stencil shadows alone, afaik no "perforated" materials (alpha mapped materials) in TDM cast shadows.
This is a historical limitation and one that TDM may never be able to change, because has the potencial to break shadows on many older missions, also saves performance...
-
1
-
(250.86-306.53182.09).jpg.088f25e68ca3ea3a8f8d0cc03750eb91.jpg)
Dark Mod trying to roast some guy.
in The Dark Mod
Posted · Edited by HMart
Like a console warning? If yes, first personally, I don't see any use in it, because IMO console messages, are meant for developers not players but if you or anyone really want to do that, then use the script printLine function for a fake console message.
But remember, they will only be visible, in the console, hidden to players that would need to toggle it to see it, unless you force con_noPrint to zero, this will show all console messages, no matter if the console is visible or not, that I don't recommend at all for something meant to players.