TDM portal culling improved

[anonreclaimer]

Hello people I have back ported the render matrix code from Doom 3 BFG to TDM to improve the portal code and I have also added depth testing for lights. The depth testing for lights cvar is r_useDepthBoundsTest I didn't really want to add a new cvar. There's also a experimental anti portal code in CullEntityByPortals to activate set r_useEntityPortalCulling to 2 but transparent surfaces are broken. The render matrix code used for portals can use C++ generic and intrinsics but intrinsics is enable by default. My TDM source was compiled in vs2015 using the vs2010 platform toolset all of my code changes can be found by searching for the "anon" comment. I hope this code can be beneficial and useful to the TDM developers.

 

NEW Cvar

r_useEntityPortalCulling

r_useLightPortalCulling

r_useLightAreaCulling

 

Binary here -> https://drive.google.com/file/d/0B5lilm1KI-BhNTlKdWRUQzNmYk0/view?usp=sharing

Source Here -> https://drive.google.com/file/d/0B5lilm1KI-BhbTNjN0UyTFVzRGc/view?usp=sharing (.rar file)

 

 

 

 

[duzenko]

Thanks a lot.
Do you think you would be able to do the same with the threading model? (game tic + front renderer run on a thread in BFG)
...
Your exe crashes at startup for me. (darkmod.exe has stopped working...)
...
You release seem to be based on 2.04 version. Is it possible to apply this change to current trunk?

[duzenko]

Merged changes into svn rev 6685.

Controlling cvar - r_useAnonreclaimer.

Quick test: skybox not rendered.

...

vid_restarts fixed the skybox but fps appears to be the same using the old and new code.

[nbohr1more]

Try Rightful Property, Penny Dreadful 3, or another mission with wide open areas. Biker has done too good of a job optimizing our missions with expert portal placement so it may be hard to find ones that benefit.

[grayman]

WHOA!

 

That is a massive code change to do two days before code freeze.

 

It will require a lot of testing, and I'd rather do that in 2.06 than in the few weeks remaining before we release 2.05.

[nbohr1more]

I was thinking the same but its hidden by a cvar so the risk should be minimized. Your call

[grayman]

So there's a cvar wrapper around every code line that was changed?

[duzenko]

Eww
I thought code freeze means don't change after day X, not before

No, really. It's all under a cvar. Nothing changes by default.

(I think )

[grayman]

Yes, code freeze means get your tested stuff in before that date.

 

But, this just happened this morning, and it's a lot of code that might be full of lots of splinters.

 

Had it been introduced a month ago and discussed by everyone and tested by the performance folks and really wrung out, it would have been fine wrapping up a couple days before the freeze and including in the release.

 

But not like this; the runway is too short.

[duzenko]

The code comes from d3 bfg, which we should strive to adopt anyway IMHO

[New Horizon]

Even though it's too late to test it properly before 2.05, that is one awesome update to see come through for 2.06. Nice. Hope we can have more improvements like that come through.

[grayman]

What does it do, in laymen's terms?

[New Horizon]

My understanding is that there should be some performance enhancement due to better handling of portals and lights but that's my limited understanding of how the engine works.

[duzenko]

It is supposed to do the culling like bfg does, using a certain "rendering matrix".

I tried down by riverside, pd3, rightful property and can't see any fps gain.

 

man, pd3 is a bitch to load

 

[anonreclaimer]

Well it nothing more then a math matrix code being used to help to cull entity's and light's. I replaced the old crappy culling code with render matrix for better performance but it wasn't too much. This is just a math matrix code that use C++ generic and Intrinsics if enabled can speed up math calculations being applied to the portal culling system so it's suppose to be a bit faster, with this in mind I believe you guys can use this to further improve the culling system.

[grayman]

Okay, let me reword my question ...

 

If we write up a blurb for a release, what would the blurb say that a player would understand? (I.e. this improves performance in large open areas on older systems.)

 

Players don't give a hoot if all we say is we refactored something.

[duzenko]

Personally I don't see any immediate benefit but it could save time in the future when/if we want to borrow more stuff from bfg.

[Goldwell]

in the few weeks remaining before we release 2.05.

 

Oh nice! I didn't know it was so close, 2.05 includes a whole heap of assets for us mappers as well right?

[nbohr1more]

Yes. A big asset release.

[grayman]

As our new president might say, "this will be the biggest heap of assets you've ever seen, and I only use the best assets, and these are the best assets!!"

[Springheel]

I created well over two hundred architectural models over the last year that will all be released with this update. Not to mention a slew of other things I made along the way--new lights, decorative props, scattered junk, etc.

[AluminumHaste]

Thank you for the hard work, I'm sure we'll find a use for it!

Were you planning on any other contributions good sir?

 

A huge one would be GPU Skinning from BFG.

 

Huh, apparently Doom 3 BFG code contains an HLSL to GLSL converter (ConvertCG2GLSL)

Might be worth looking at also.

[duzenko]

Whatever you do, just please try to do it with the latest source code in svn.

It's a pain to merge changes to an old release.

[Anderson]

WHOA!

 

That is a massive code change to do two days before code freeze.

 

It will require a lot of testing, and I'd rather do that in 2.06 than in the few weeks remaining before we release 2.05.

By the way, is the time constraint the reason for postponing EAX until 2.06? My conclusion is drawn from and according to the bugtracker.