Jump to content
The Dark Mod Forums

TDM Engine Development Page


Recommended Posts

Still here, for some reason pm's are not forwarded to my email ? so i missed out on the discussion here.

 

Still hard at work on porting BFG's features to vanilla, so far i been adding RBDoom3BFG's depthbounds testing for both lights and shadow volumes.

Entity and Surface sorting (to prevent GPU pipeline bubbles), refining vanillas thread handler (runs 12 threads on my rig now).

Replacing malloc with nedmalloc.

 

Also discovered a nasty bug with msvc2013, compiling vanilla with 2013 causes shadow volumen cut off's. I reported the bug to microsoft but untill they have it fixed i recommend using an earlier compiler.

Msvc 2010 works best.

 

Copied out my own project to a new project also and removed all the editors so my new version is quite lightweight now, old version is still on github though,

latest changes are in my new version but ill merge those changes when im satisfied that things work allright.

 

Latest change, i created code to expose the code for copying depthimages to the game dll's so real ssao is possible now,

unfortunatly im crap at shaders and sikkpins versions wont work correctly with it unless rewritten so someone would have to fix them before it will be usable.

  • Like 2
Link to post
Share on other sites
  • Replies 1.1k
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Video #1 is up. I'll add the second one to this post in about half an hour.   http://youtu.be/iumyzCicOzM   Note to self: I really must learn to put a proper light or two in even if it's only a test m

Good news, this works out better all round.   The 2.02 release shader (that doesn't have the extra colours) uses far fewer samples than the one I was adapting above, so I've put in the extra sample to

Yes it can be fixed using currentDepth but as expected it creates a slightly calm area round the object:     Although that's probably better than the distortion.

Posted Images

Still hard at work on porting BFG's features to vanilla......

 

...... removed all the editors so my new version is quite lightweight now, old version is still on github though,

latest changes are in my new version but ill merge those changes when im satisfied that things work allright.

 

That's what I don't get, and probably never will. Dhewm3 did that - removed tools. And no one wanted to used dhewm3 in their projects because of that. They also made the whole thing incompatible with old mods and no one cared to port mods to Dhewm3. Back-porting BFG into idTech 4, and removing tools is like .... fixing BFG to be moddable. I know some folks here have high hopes for your project, but it seems like what will come out will not be what they are hoping for.

Link to post
Share on other sites

Also discovered a nasty bug with msvc2013, compiling vanilla with 2013 causes shadow volumen cut off's. I reported the bug to microsoft but untill they have it fixed i recommend using an earlier compiler.

Msvc 2010 works best.

Is that bug report on a open ticket that I can access / track? I've had what could be the same problem, with the release config only. Debug works fine.

Link to post
Share on other sites

frag machine over at inside3d brought up something that might explain why 2013 breaks.

We started discussing if the problem could be related to precision loss when casting doubles to float, made me wonder so i checked RBDoom3BFG and it works fine with 2013.

Funny thing is that BFG uses double precision floats in idlib.

Link to post
Share on other sites

Played around with the EPSILONS for light and shadows (LIGHT_CLIP_EPSILON) original value was 0.1 which is a double so i changed it to follow DBL_EPSILON

const float LIGHT_CLIP_EPSILON = 2.2204460492503131E-16; // as pr DBL_EPSILON

 

n222bt.jpg

 

result seems promissing :) i had some rather nasty shadow bleed in this map and its all gone now.

Link to post
Share on other sites
Played around with the EPSILONS for light and shadows (LIGHT_CLIP_EPSILON) original value was 0.1 which is a double so i changed it to follow DBL_EPSILON const float LIGHT_CLIP_EPSILON = 2.2204460492503131E-16; // as pr DBL_EPSILON

result seems promissing :) i had some rather nasty shadow bleed in this map and its all gone now.

 

Wow you zeroed in on that quickly. It's a big change though isn't it? I don't know what that epsilon is used for, but going from 0.1 to 2.0E-16 seems to change its purpose from an epsilon meant to make changes to one that catches floating point errors only. 0.1 is the epsilon used by dmap to collapse parallel planes to a single plane. No idea whether that's a coincidence.

 

I'll try your new epsilon in my vs2013 TDM build and see whether it fixes the problem here too.

Link to post
Share on other sites

Aye it should not have worked at all since the number im using is the same as defined for DBL_EPSILON and as you point out its for checking floating point rounding errors.

 

BFG uses the floating point checks in idlib so a better fix would probably be to grab the code for that,

vanilla also has some of the floating point checks but uses a rather old version with only single precision.

 

should probably rename LIGHT_CLIP_EPSILON to PLANE_CLIP so that it does not confuse people to its real purpose ;)

Link to post
Share on other sites

I changed the FLT_EPSILON in idlib to be DBL_EPSILON and reverted the above, so far all seems hunky dory :) ill test some more though,

would be nasty to call it a day and then its not working correctly. Atm tracking where idlib uses it so i can pin the exact bugger.

Link to post
Share on other sites

Fingers crossed!! And thanks for sharing your findings.

 

I keep tripping over 0.1 epsilon values causing problems when I'm debugging specific map issues by the way. The places they're used don't seem to be logically connected so I've been wondering whether they really all got tested and tuned to be 0.1 or whether that's just a handy default.

 

Most recent examples: 0.1 is used in FlowViewThroughPortals_r. If the player is within that distance of the plane of a VP, then the view is allowed to flow both ways through the portal. That was partly responsible for some game freezes in special circumstances (since patched for our next release), plus it's not enough to stop some visleafs from disappearing entirely if the player is standing next to the portal. AH found an example last night, with an angled VP. When I checked it in the debugger, the view origin was judged to be a whacking great 0.5 the "wrong" side of the portal, so 0.1 wasn't enough to ensure that both visleafs generated interactions.

 

It's also implicated in causing dmapping errors. Parallel planes < 0.1 apart get consolidated to the same plane by FaceBSP. That's fine unless you somehow end up with a brush fragment thinner than that in an open (reachable) area of the map. When that happens, no separate BSP leaf gets generated for the fragment, so when dmap later comes to FilterBrushesIntoTree, it'll place the fragment in a leaf larger than itself and conclude that the entire leaf is opaque. What you see in game is some missing walls (if the leaf abuts visible world geometry), and when the player stands in that spot the entire map gets rendered because the view origin isn't in a recognised bsp area so there's no culling of interactions by portals. The player can stand in that spot because it causes only BSP to go missing: the world collision model is generated separately and leaves the leaf open.

 

However, (reminding myself) that's not what you're looking at. You're on the trail of something that works fine in vc2010 but not when optimized in vc2013. Gotta say that one's beyond my diagnostics skills so I'm glad you're looking at it :)

Link to post
Share on other sites

Hehe is ok im interrested in whatever fixes turn up :)

Changing idlibs FLT_EPSILON to DBL_EPSILON does not seem to have any adverse effects and i havent run into any shadow corruption yet because of this.

Tbh i think its ok to use these, example FLT_EPSILON is used the same way as in vanillas code checking if the value is newer above 1F and newer below -1F same goes for DBL_EPSILON

it checks 1.0F vs -1.0F though.

Link to post
Share on other sites

found a good read here on epsilons http://www.cygnus-so...m#_Toc135149455

 

To my surprise its actually stated that the best way for comparing float epsilons is with ints Oo the number for comparing can be any value actually depends on how fine a mask you want.

 

The value it seems most use today is 0.00001 so way lower than vanillas 0.1 mask which may actually be to high.

Edited by revelator
Link to post
Share on other sites
  • 4 weeks later...

Just a little self-frustration...

 

BFG now has an experimental PBR \ BRDF \ branch:

 

https://github.com/RobertBeckebans/RBDOOM-3-BFG/tree/PBR

 

I guess it should be mentioned that Sikkpin accomplished something akin to this on a smaller scale in vanilla:

 

Download: https://dl.dropboxusercontent.com/u/17706561/ambientcube_test.rar

 

Wayback archive: https://web.archive.org/web/20130909073250/http://www.doom3world.org/phpbb2/viewtopic.php?t=24193

 

Another thing that may eventually come in handy since it was lost, a skin shader (sub-surface scattering):

 

https://github.com/RobertBeckebans/Sikkpin-Feedback/tree/master/shaders/glprogs

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 post
Share on other sites

 

That skin shader looks usable... no difficult inputs.

 

@nbohr1more: are you aware of an efficient way to get a copy of the current depth buffer into a texture for use in post processing? I'm wanting to make or import a soft particle shader as my first rendering project now that I've read that book. I studied sikkpin's code but he uses an expensive full rendering pass (front AND back end) to get the depth map into a texture, presumably because the engine was closed source back then. I've been jotting down notes but I expect I'm trying to reinvent the wheel here...

 

EDIT: I think idImage::CopyDepthbuffer might be what I'm looking for.

Edited by SteveL
Link to post
Share on other sites

Excellent thanks. That post by revelator ticks off several of the questions I had on my to-do list plus a couple I hadn't thought of :) Although I'm a bit confused why he copies the depth buffer before filling it in RB_STD_FillDepthBuffer. I'll have a play with it when I get home and maybe figure out why. In the meantime it looks like he's solved two problems: how to capture the depth map to a global image every frame unconditionally, and how to let the game get hold of a copy on demand.

Link to post
Share on other sites

i made a small mistake in my tutorial that i need to fix.

 

This is probably it, but you also pasted RB_CopyRender and said to put it next to RB_CopyDepth instead of the other way round.

 

Thanks for the guidance by the way :) I'll try it out tomorrow. Right now I'm trying to work out whether I can use GLSL shaderprogs in TDM.

Link to post
Share on other sites

Should be possible MH over at inside3d made a mixed mode ARB2 / GLSL renderer some time back, it only handles interactions though.

A full GLSL renderer should also be possible copying of some of the BFG code for it. A few of its functions need some exports from BFG's idlib though.

Maybe a simplified version can be made without copying those parts, still investigating ... im pretty new to C++ so i may still make silly mistakes heh.

Link to post
Share on other sites

Yeah, Serpentine had GLSL working in his TDM branch I believe.

 

To get a general idea how GLSL was originally added to vanilla, look at the commit history of Pat Raynor's old

iodoom3 branch:

 

https://github.com/iodoom-gitorious/raynorpats-glsl_iodoom3

 

commit:

 

https://github.com/iodoom-gitorious/raynorpats-glsl_iodoom3/commit/85e0166ad43b865b22b44faa6851b5e8dccf4bfa

 

then compare that to his most recent GLSL implementation that he ported from BFG to vanilla:

 

https://github.com/raynorpat/morpheus

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 post
Share on other sites

Thanks, but wow! That's a bit more code than I expected. I didn't realise that glsl requires the client code to set up an entirely different context. I'll shelve that for now and just learn ARB assembly to play with soft particles, which will take an hour instead of weeks.

 

Do we want glsl? While reading Real-Time Rendering I noticed that the authors warn repeatedly against branching code because all branches have to be executed. I can see why that's a problem in assembly, but does glsl solve it? If so it's worth working on. But we couldn't use the full glsl port without translating all existing shader programs to glsl. Even so, that might be less work than a hybrid solution if the one that revelator linked supports only interactions. I've not checked it out yet but I'm sure they'd have supported everything if it were easy.

Link to post
Share on other sites

I have opened a bountysource tracker for porting BFG's GPU skinning to vanilla Doom 3:

 

https://www.bountysource.com/issues/2883499-port-gpu-skinning

 

This would be for raynorpat's morpheus branch which already has BFG's VBO and GLSL backend.

 

Whether this ever helps TDM, at least the campaign may help getting more activity going on the vanilla Doom 3 scene.

 

Donated

I always assumed I'd taste like boot leather.

 

Link to post
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.


×
×
  • Create New...