motorsep

So I take it there is no interest porting TDM to BFG derivative ? P.s. Yes, I am aware there is no publicly available stable, production ready fork yet

It's for Unity and it does't save into Cg / GLSL.

I would be nice to have Cg shader editor

Aye, cool. I had a few issues with redrawing windows and selection, but I guess those aren't show stoppers and can wait until 2.0.1

If that's for LOD, it's quite an elaborate setup to make one LOD iteration "softly" transition to another. Even AAA games you straight LOD transitions. Crysis 2+ uses alpha blending afaik. Not quite sure about other games.

@greebo: What about resizing rotated lights ? Would it be an easy fix ?

Thanks SteveL! Afaik the only entity that can have inline key is func_static, that's why I didn't bother with the check. So just to summarize, this script would only roll through the entities with inline key, not through all available entities on the map ? As for entity count, I though there is a cmd in the engine that prints entity count like fps, on the HUD. But script will do for testing purposes

@SteveL: I am quite new to scripting in DoomScript, so I have a question about the usage of this script function I need to run a loop until $null_entity is returned. And inside that loop I need to check for "inline" spawn arg on each entity getNextEntity gets and then if it's "1", I need to remove it. would it be something like: entity e; while ( e != $null_entity ) { e = sys.getNextEntity("inline","1", e); e.remove(); } And I need to call it after level is loaded, to remove inlined entities. What am I missing? Also, is there a way to see entity count on the map? I'd like to spawn as usual, check entities count, then trigger the script and see if it did remove inlined entities. Thanks.

@SteveL: Ported, adopting it to Doom 3 code base (compiled successfully). However I have a question. Since Doom 3 has no EventArgs(), I needed to convert this: const idEventDef EV_GetNextEntity( "getNextEntity", EventArgs( 's', "key", "Optional string: prefix for spawnarg key match. E.g. \"target\" will match \"target\", \"target1\" etc.", 's', "value", "Optional string: spawnarg value to match. Can be used independently of ''key''. If ''key'' is not set, all spawnargs will be checked for the value.", 'E', "lastMatch", "Last match: search will start after this entity. Use $null_entity or pass an uninitialized entity variable to start a new search." ), 'e', "Discover all entities in the map. Returns $null_entity when no more found."); into Doom 3 format, and this is what I got: const idEventDef EV_GetNextEntity( "getNextEntity", "ssE", 'e' ); Is it correct ? Also, how does it look like in events.script ? Like this: scriptEvent void getNextEntity( string key, string value, entity lastMatch ); ?

Cool, I'll check it out. The name of the function looks close to what Doom 3 has natively.

Currently the only way to query an entity in script is by name. So if you don't know the name, you can't do anything. And even if I have a name and suffix, so I could put it into a loop, it's a major slow down. I recall someone saying there are active entities and inactive ones, and C++ code only works with active entities, which is efficient. Is it possible to pull something like that in script (exposing a new function to script) ? I'd really like to have a small pool of entities to go through and reference them by index instead of their name.

No buts. Have you played Doom 3 BFG ? There is glass and there is warp it creates. All done using heathaze shader. I personally made glass in my game and it warps space behind it perfectly fine. Unless we are talking about entirely different effects. Maybe when they just started developing Doom 3 they had heathaze shader hardcoded and later on it migrated into ARB, but some of the C++ code remained ?

Reported: http://bugs.thedarkmod.com/view.php?id=3860

Alright, I will make a video and submit formal bug report.

@greebo: I am sure it could be considered as a feature, not a bug, but due to different lighting techniques I feel like it would be beneficial to fix it (if it's an easy fix). Basically, when I rotate light volume around Y or X axis, I not longer can resize it. Or rather, if I drag the sides, it's being resized in unexpected manner (I can record video explaining what's happening after work). Is it possible to make rotated light volume to be resized as if it's normal light volume?

I don't have TDM. You saw I was using Doom 3.

That makes me chuckle - all effects from vanilla Doom 3 are in BFG. Just instead of ARB shaders they are GLSL shaders. And heathaze (glass warp) is the only shader that is used in Doom 3 materials, afaik.

So, what happened to testing? I tried parallel light and it doesn't work the same way as rotating light volume.

TDM / Hexen use ARB shaders written from scratch. But again, the issue is that it's virtually impossible to find graphics programmers who can (or will, even if they could) write shaders using assembly. So maintenance and long term support are the major issues too.

Apparently not in DR, because in DR you only have 1 vertex to work with. In DOOMEdit, light has vertices indeed (I recall I saw vertices in Vertex mode), but I haven't tried rotating them. I dare you to try that, nbohr1more, and post screenshots of the results

How do you do that with standard omni ambient light?

That's what I meant about falloff image (I didn't mean the wall is white). Here is modified gradient showing what happens exactly: Don't make your ambient lights with this approach overlapping. I'd use one big light for each block of the level (one floor). Again, this is not Strombine's approach. Lights' Z projection image goes horizontally on Strombine. This technique we are discussing now is standard Doom 3 vertical projection. I don't know is Quake 4 editor allows easier way for resizing of rotated lights, but DR definitely makes it impossible.

That looks absolutely wrong for the example mod you posted. That image looks like projected light shining onto the wall. And the sample test you gave us is about ambient light. Here is how it works. Falloff image is stretched vertically, covering vertical spaces (walls) and the light image is "projected" onto floors/ceilings: It would be nice to have floor and ceiling projection separated.

That doesn't make things clear, sorry :/ I guess with art related stuff it has to be visual (video or screenshots). EDIT: So I finally deconstructed this setup. It's not the same method Strombine map uses. Here we have standard projection in the shape of the rooms, and standard fall off. The only thing I don't get is why Rich added 100% transparency to the projection image. I decomposed it in GIMP, removed alpha and recomposed it into RGB image. Still get same results in the game. Strombine guy was writing about rotating the light entity (or swapping falloff image with projection image). What what exactly he meant by that, I don't understand, because not only it makes no sense, but also the light can not be sized properly on DR after it's rotated around X or Y axis. Rich's method is quote interesting, because I could make entire level get lit with only a few big lights, textures for which have all the ambient/bounced lighting painted. Hell, can probably just render it Cycles in Blender (all indirect lighting), and the place direct lights in DR. I wonder if TDM already tried such approach.

Is there a link available with description of the process or just showing how it was done in Prey ? I've read the tutorials on TDM wiki, and Strombine's author write up, but all of them are confusing. A video tutorial or easier to wrap head around written document would be very welcome