nbohr1more

Yeah. It doesn't seem too bad but... drawing the light texture and aligning the light might be a little tedious if you're a perfectionist. To use a real light-map bake would be a real pain in the ass. Something like: 1) Export your map as a bunch of models (cut up geometry by visportal and or ease of building) 2) Rebuild your map from these models in PovRay or another program that does Photon Maps 3) Setup lights 4) Create the Photon Map 5) Bake all the "Bounces" and secondary lighting (anything that steals performance) to UV Mapped Textures on the models Then pick your poison: A: 6) Unwrap the texture 7) Cut up the texture in a image editor and try to re-UV map your Brush-work or B: 6) Import all the Models and replace your Brush-Work with Models 7) (see STiFU for details for seamlessly connecting the models with internal Brush-Work? ) Then finally: 8) Remove any small lights that you already baked into the UV map

The performance win here is that you do not need to use lots of lights. You can use one light texture and have it look like the area was lit by many little lights.

The look should be equivalent of Light Baking but also the Light Gem will work with it (Strombine method). But I did allude to Photon Mapping in the wiki and will expand that area as well if I can find the references. I have a cached copy of the old Doom3world baking article and I'll see if I can make that into a wiki as well but that would probably have the same visportal issues that the original post in this thread has. http://forumtgmonline.futuregamer.it/showthread.php?t=5137

No screen-shots yet and I haven't fiddled enough in Dark Radiant or Gimp yet either but here is a skeleton wiki: http://wiki.thedarkmod.com/index.php?title=Light_Textures_and_Falloff_Images#Links_and_References

I will try to keep it to paint-by-the-numbers with pictures and clicks 'n all. I'm sure that Rich will find it amusing (and or somehow technically incorrect). But I will test the method so it should work whether my words are fools-gold or not.

Thanks for the additional clarification Rich. I'll have to fuss around in Dark Radiant and Gimp so I can get the full scope of how this is done (step-by-step) but I think I've got enough here to cobble together a wiki. Unless someone with more noodles in the noodle-bowl wants to write a well-written one ...

Congrats. Perhaps this is superstition but I would recommend you uninstall any FMS before your next update...

I have a P4 3.0ghz and a HD4650 AGP (so kinda lowish...) Caveats: But I am no expert ghoster and I find every FM challenging and fun because of my lack of skills My wife has a tendency to limit my CPU time... (copied from Jesps beta... ) (cant resist the chance to see this in action BC...)

Just wanted to make sure. I have a bad habit of writing twisty sentences and forgetting to include enough context .... I hope you get it running.

I would completely clear out the TDM directory and then just run the latest updater before you decide to blow out everything (reload, FFR, etc). (make sure that no conflicting Mods are in the Doom 3 directory as well). Just to clarify, I was saying to copy the DevIL.dll from TD to TDM then delete TD.

Yes. If you want to play the old TD then you'd also need to put the DevIL.dll into the Doom 3 folder (and create a description.txt with a different name...). Once you've got your precious DevIL.dll I'd recommend deleting the old DM demo unless you can somehow avoid confusion between that and TDM...

Download the old Thief's Den demo, it has a current version of DevIL.dll: http://www.fidcal.com/darkuser/missions/thiefs_den_v1.0.exe Also, clear "Trapped!" out of your currentfm file.

How about your DevIL.dll file? Do you have the latest version in place? I forgot what it's called but I believe there's a config file that specifies that a mission is installed, perhaps that's the problem? Other than that I can only guess that something like security software is preventing either updates or the access to the scripts??? Edit: currentfm.txt ?

Yeah... It makes the entities "think" about their "distance to you" so it will only be beneficial if that thinking takes less processor than the geometry that is being hidden. (works better when there is more "stuff" to hide.). The dist_check_period is where the bug is, it doesn't work well with fractions of a second. I think the default is one second so the bug may not be a problem there? (damn Bold-ing can't un-bold...)

Melan had a similar problem not long ago. He deleted both the gamex86.dll and DoomConfig.cfg. (Cant get this to un-bold ... ) Anyway. I would make sure that your autoexec.cfg, DoomCfg.cfg and gamex86.dll files are gone along with any saved games (not compatible between updates.). I'm sure a brighter bulb will come along and give you more options and better advice.

:laugh: (A prelude to what will happen when we start replacing actors with robots )

Cool!

I don't think that: lod_hide_probability - 1 hide_distance - 750 will work in 1.02... XXXXXXXXXXXXXXXXXXXX You will need to use: editor_float hide_distance - 750 (OK... the "editor_float", etc... part is probably redundant to what happens in TDM and Dark Radiant internally... So editor_float hide_distance = hide_distance... if hide probability is not in 1.02 then it probably ignores it...)

Oh yeah, lights cannot currently be culled via LOD. Not sure if that is just a lot of extra work or impossible (requires Source Code?). Probably just very difficult because of all the other custom SDK stuff Tels put into the lighting system. You'd have to treat every LOD light like an extinguishable candle?

There may be trade-offs with that approach Biker because as soon as you turn around to look at the objects that were out of view the engine will have to recompute silhouettes for anything that casts shadows and the engine will get hit with a bunch of draw calls. But I suppose for far away stuff that is behind you it should yield some benefit (meaning it will probably take some tweaking to find the optimal "make me invisible" distances). I would caution that this type of LOD use should not be used as a crutch for folks who are bad at working with visportals (for any newbs reading this... ) but it may help bulldozer some geometry away when you want it gone. Actually NHAT was what inspired me to investigate Object LOD in Doom 3. I always figured that Doom 3 had an Object LOD system like every other engine so I went running around Doom3world to see if there were any tricks to help it run better. I found out the Doom 3 does not have object LOD at all and there were serious questions about whether it could be made to work because you'd have to build it with what's available in the external SDK (instead of the Renderer). (When I posted the thread here I still couldn't believe that Doom 3 doesn't have a native LOD solution...) I'm not sure Mortem Desino was aware that you could specify distance checks to make entities disappear when he worked on NHAT 3. (Given that it's kinda broken I don't think that it's a widely used feature...). Edit (Late redundant post )

I don't see a bloom cvar but I know that Denton's mod has been known to cause this type of trouble due to Bloom. You could try: r_bloom "0" or r_bloom "3" You could also drop in an updated HDR pk4 from the HDR thread at Doom3world... http://www.doom3world.org/phpbb2/viewtopic.php?f=56&t=22822

Looks great! Any hint of how many more of that quality you have cooking Serpentine? (That mesh looks like it took "awhile" so I wouldn't be surprised if this is the only one with that much goodness to it... )