Jump to content
The Dark Mod Forums

TDM Engine Development Page


zergrush

Recommended Posts

GNU General Public License?! I guess demagogue can answer this.

FM's: Builder Roads, Old Habits, Old Habits Rebuild

Mapping and Scripting: Apples and Peaches

Sculptris Models and Tutorials: Obsttortes Models

My wiki articles: Obstipedia

Texture Blending in DR: DR ASE Blend Exporter

Link to comment
Share on other sites

Yeah, it's GPL. But it isn't all that straightforward to port the multi-threaded renderer over (and the other improvements). And there will likely be some issues with trying to rebase TDM onto BFG since the tools, etc. aren't there. So until a more "dev/mod friendly" branch is available with the tools and all, we might need to "watch this space". But there are people working on it (e.g. RBDOOM-3-BFG )

 

Edit: and people making some moves to port stuff from vanilla to BFG like nbohr1more stated above.

I am the bat. The night is mine.

Link to comment
Share on other sites

BFG is a wacky engine. By wacky I mean raw. There are quite a few large fixes need to be done to fix texture compression issues, to get it more development friendly (besides adding tools), etc.

 

Performance wise TDM would definitely win from moving to BFG. Game code is identical to vanilla Doom 3.

 

The issue is that if you want intricate lighting and shadows, and lots of it, you perhaps want to look at UE4 instead. Save yourself headaches and focus on actual gameplay and art. I know it's not really feasible for TDM. However if you have TDM 3.0 planned, might as well go for UE4.

Edited by motorsep
Link to comment
Share on other sites

So it seems that Revelator has now ported BFG's thread handler. This doesn't rely on OpenMP so it should be more stable

for Windows:

 

http://forums.inside3d.com/viewtopic.php?f=1&t=5476&start=45#p54087

 

Revelator is claiming that this enhances performance more than the OpenMP patch but I am leaving that open for judgement as his performance

claims seem to vary wildly due to bugs in his ATI drivers (etc). I am more hopeful this time though :) .

 

Executable for testing:

 

http://sourceforge.net/projects/cbadvanced/files/gtkradiant/Revelation_sources-23-08-2014.7z/download

 

(I haven't had a chance to test it yet.)

 

The executable just prior to this didn't improve FPS in the standard timedemo for me but OTOH it was one of the few

Doom 3 GPL executables that "actually opened for me" besides TheDarkMod.exe. Strangely, the timedemo was worse in

both vanilla and revelator's previous build seemed to run worse than TDM. It looks like he had problems with stencilopseparate

which means he's probably using something less ideal for shadowing optimization than TDM even with his other shadows fixes.

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

Better if you can get it to compile. :)

 

Often I'm wasting time jumping through hoops to get someone's source to compile. The instructions say there is an sln file for VS 2010....opened up 2010 and it spat out an error that it was made with a newer version. Checked the sln and it's for 2012. lol Drives me crazy.

Link to comment
Share on other sites

It runs and is a bit faster (not dramatically so). I think the resolution detection is borked because I cannot get it to run properly in fullscreen

though that is probably Intel's fault :( . I was even able to enable the ARB_MAP_BUFFER_RANGE extension without crashing (which is problematic

for older ATI hardware apparently). I wanna see how well this would work if stencilopseparate were added back though.

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

Yeah, I guess if a few more things were covered it may improve performance a bit more. It's a step in the right direction though and any extra performance gained might help offset the soft shadows later on down the road.

 

This doesn't include multi-core support does it? I don't really know the tech behind threading and multi-core.

 

Was there a visible increase in FPS?

Link to comment
Share on other sites

Yeah, it's supposed to have some course-grained multi-core support such as having the render backend and frontend on different threads

on different cores.

 

I gained about 5 to 10fps in the timedemo and I think I'm somehow GPU bound there so not too shabby.

 

I haven't had a chance to look at threads in task manager yet.

  • Like 1

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

While we're over here thinking about multi-core stuff, RaynorPat quietly begins adding a Deferred Renderer to Dhewm3:

 

https://github.com/raynorpat/dhewm3

  • Like 1

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

Deferred Rendering would mean that mappers could place an almost unlimited number of lights in a map with negligible performance

loss. Whether existing maps would benefit that much is an open question but the other benefit is that almost no unseen triangles are

rendered with Deferred Renderers so we would also expect larger polygon counts to be possible.

 

The last time RaynorPat tried this, he found that the Deferred Renderer took too much memory to work with shadow maps so he tabled the

idea. I suspect he's gonna try using Treb's shadow map implementation to see if it fares better.

 

The downside of deferred renderers is that you must pack all the surface data into a buffer which often leads to a more restricted number

of materials per scene or compression artifacts.

This can be mitigated via the use of large texture atlases, using hybrid rendering, or deferring only the lights (Light Indexed Deferred Rendering).

 

The other downside is that it's hard to do AA with deferred renderers.

Edited by nbohr1more

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

Deferred rendering also means that only certain GPUs and up will be able to play the game. Older (but still very capable) hardware will be cut out.

 

Not to mention that people with lower VRAM bandwidth will be out of luck too.

 

Tr3b's shadow maps are _slow_ and VRAM bandwidth consuming making Doom 3 BFG unplayable of the hardware that plays Doom 3 BFG vanilla at 50-60 fps.

Link to comment
Share on other sites

Well, if hardware support is a problem, you can always add it as an alternate render path (eg, arb, arb2, cg, best, etc). UE3 can do deferred rendering

on DX9 SM2.0 hardware so it should be possible to cover TDM's audience with that but... OpenGL is notoriously behind on specification compliance and

driver support so things that existed in DX7 only just recently arrived in OpenGL. Hopefully Valve's push for OpenGL will pressure ATI and Nvidia to create

better drivers for older hardware so that you don't need (for example) DX10 hardware to do MRT's. Some really dumb political shit.

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

Deferred Rendering would mean that mappers could place an almost unlimited number of lights in a map with negligible performance

loss. Whether existing maps would benefit that much is an open question but the other benefit is that almost no unseen triangles are

rendered with Deferred Renderers so we would also expect larger polygon counts to be possible.

 

The last time RaynorPat tried this, he found that the Deferred Renderer took too much memory to work with shadow maps so he tabled the

idea. I suspect he's gonna try using Treb's shadow map implementation to see if it fares better.

 

The downside of deferred renderers is that you must pack all the surface data into a buffer which often leads to a more restricted number

of materials per scene or compression artifacts.

This can be mitigated via the use of large texture atlases, using hybrid rendering, or deferring only the lights (Light Indexed Deferred Rendering).

 

The other downside is that it's hard to do AA with deferred renderers.

 

The problem with deferred rendering is that shadow casting lights are as performance heavy and have the same limitations (8 shadow casting lights per frame, is a hardware limit) as normal rendering, and coupled with the much higher memory requirements for it, some if not all limit shadow casting to a single light, for example that is how Amnesia does it, a bunch of no shadow casting lights and a single (hero) light casting shadows. This can also be accomplished with the normal idtech 4 forward rendering, also deferred rendering only wins in the number of small (not shadow casting) lights 100 or more per frame, that is why all deferred rendering demos have small lights moving and jumping around and afaik idtech also claims to gain performance with small radius lights. Deferred Rendering also wins on scene complexity (number of polygons per frame) but if levels continue staying as simple as they are now then any performance gains will not be notice and it can even be worse because of the memory requirements.

 

Deferred rendering also means that only certain GPUs and up will be able to play the game. Older (but still very capable) hardware will be cut out.

 

Not to mention that people with lower VRAM bandwidth will be out of luck too.

 

Tr3b's shadow maps are _slow_ and VRAM bandwidth consuming making Doom 3 BFG unplayable of the hardware that plays Doom 3 BFG vanilla at 50-60 fps.

 

Deferred Rendering is supported on any dx9 shader model 3 and up GPU's, does are considered very old cards by now, and any dx10 card can be bought by less of 50€ nowadays, no reason to lock a engine progress because of ancient hardware. Btw Tr3B's shadow maps aren't more performance heavy per ce, is just that because Doom 3 was not made to support shadow maps it is not optimized for it, and so for example many lights that were not casting any shadows on the vanilla engine become shadow casting lights with the shadow maps, for example all lights behind alpha mapped surfaces. Is totally possible to have a performante game with shadow maps if you know how to optimize them.

 

Interesting...perhaps then it's best to stay clear of something like this until further down the road. Threading / Multi-core enhancements are probably the best way to go for now.

 

Implementing Deferred rendering is still a good idea and if well used (lead to more scene complexity) can indeed improve performance.

Link to comment
Share on other sites

...OpenGL is notoriously behind on specification compliance and

driver support so things that existed in DX7 only just recently arrived in OpenGL...

 

What? Where do you eard that? Any links? OpenGL is fully dx11+ compliant by now (OpenGL 4.5) and was always fully dx9 compliant before and with extensions it was even more advanced than DirectX in some expects (but some only worked on a single GPU vendor for example Nvidia). You can say bad things about OpenGL, driver support being one especially from AMD, being a convoluted mess with so many backward compatibility paths another, but being behind even dx7 support is not one of them, at least that is not what i learned about it.

Link to comment
Share on other sites

Deferred Rendering is supported on any dx9 shader model 3 and up GPU's, does are considered very old cards by now, and any dx10 card can be bought by less of 50€ nowadays, no reason to lock a engine progress because of ancient hardware. Btw Tr3B's shadow maps aren't more performance heavy per ce, is just that because Doom 3 was not made to support shadow maps it is not optimized for it, and so for example many lights that were not casting any shadows on the vanilla engine become shadow casting lights with the shadow maps, for example all lights behind alpha mapped surfaces. Is totally possible to have a performante game with shadow maps if you know how to optimize them.

 

GLQuake was not designed for anything modern and yet DarkPlaces has shadow mapping and deferred rendering and real-time GI, and it performs way better than xreal/rbdoom3bfg when it comes to shadow maps. It's an excuse for not optimizing shadow mapping implementation in RBDoom 3 BFG. Instead of going "because I can!", it would be much wiser to take DarkPlaces' shadow mapping and implement that.

 

I can play Crysis 3 with quite decent quality on my rig, and Crysis 3 has a way more taxing graphical features than RBDoom 3 BFG that only has shadow mapping. On some levels in RoE all timers go red. It absolutely has nothing to do with original engine and it has everything to do with how new stuff (shadow mapping) was implemented.

 

Either way, the point is that when you begin supporting wide range of hardware and different rendering paths, you get a mess in the code. You need an experienced dedicated programmer (or a few) to support it, not to mention to engineer it to be fast and stable. Once you begin pulling pieces from different forks into one, without having experienced software engineer who has at least 10 years of experience hands on with game renderers, you will quickly find yourself in a world of pain.

 

Does TDM team really need/want to be in a world of pain? What TMD really needs is GLSL back-end and GPU skeletal. That alone will boost fps and that's not something crazy to implement. Threading, deferred rendering and shadow mapping are much harder to get right (fast and stable).

Link to comment
Share on other sites

What? Where do you eard that? Any links? OpenGL is fully dx11+ compliant by now (OpenGL 4.5) and was always fully dx9 compliant before and with extensions it was even more advanced than DirectX in some expects (but some only worked on a single GPU vendor for example Nvidia). You can say bad things about OpenGL, driver support being one especially from AMD, being a convoluted mess with so many backward compatibility paths another, but being behind even dx7 support is not one of them, at least that is not what i learned about it.

 

I say nothing bad about OpenGL for "new" hardware. It is at parity or better than the DirectX equivalent. The problem is "old hardware" such as DX9 class hardware. Here, the

vendors were arguing for ages during the whole OpenGL 3.0 specification debacle. They never went back and added the features from OpenGL 3.x and higher to drivers

for "old hardware" even though that old hardware had the capability to render those features. I will try to find some references.

Please visit TDM's IndieDB site and help promote the mod:

 

http://www.indiedb.com/mods/the-dark-mod

 

(Yeah, shameless promotion... but traffic is traffic folks...)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recent Status Updates

    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
    • OrbWeaver

      I like the new frob highlight but it would nice if it was less "flickery" while moving over objects (especially barred metal doors).
      · 4 replies
×
×
  • Create New...