Thing rendering by touched sectors

Post a reply

Smilies
:D :) :( :o :shock: :? 8-) :lol: :x :P :oops: :cry: :evil: :twisted: :roll: :wink: :geek: :ugeek: :!: :?: :idea: :arrow: :| :mrgreen: :3: :wub: >:( :blergh:
View more smilies
BBCode is OFF
Smilies are ON
Topic review
   

Expand view Topic review: Thing rendering by touched sectors

Re: Thing rendering by touched sectors

by Graf Zahl » Mon Dec 26, 2016 10:57 am

Then I guess it was the lights and nothing else.

Re: Thing rendering by touched sectors

by Major Cooke » Mon Dec 26, 2016 10:49 am

OpenGL.

Re: Thing rendering by touched sectors

by Graf Zahl » Mon Dec 26, 2016 10:37 am

Major Cooke wrote:It appears the performance drops have been fixed. Still doing more testing but it feels definitely better now.

Were these with OpenGL or software rendering?

Re: Thing rendering by touched sectors

by Graf Zahl » Mon Dec 26, 2016 10:36 am

ZZYZX wrote:Latest GZDoom code doesn't crash for me anymore.
Graf Zahl wrote:ADynamicLight requires setting RenderRadius to -1 anyway so that should solve this problem.
Disabling the additional sectors was not solving the problem for me before. Also, this would still mean that if someone somehow sets RenderRadius for dynamic lights it will start to crash again.
Keep in mind that there's two kinds of dynamic lights: placed ones and attached ones. I think the problems come from the attached ones because they are doing some weird things. But those will never be a child class, they'll always be plain ADynamicLight.

Placed ones just act like regular actors.

Re: Thing rendering by touched sectors

by Major Cooke » Mon Dec 26, 2016 10:35 am

It appears the performance drops have been fixed. Still doing more testing but it feels definitely better now.

Re: Thing rendering by touched sectors

by ZZYZX » Mon Dec 26, 2016 10:12 am

Latest GZDoom code doesn't crash for me anymore.
Graf Zahl wrote:ADynamicLight requires setting RenderRadius to -1 anyway so that should solve this problem.
Disabling the additional sectors was not solving the problem for me before. Also, this would still mean that if someone somehow sets RenderRadius for dynamic lights it will start to crash again.
I mean, it'd still be nice to understand why DynamicLight was unlinked successfully from it's sector, but then still attempted to render. And why this doesnt happen to any other kind of actors.
Anyway seeing as it got fixed when you deleted the forward_list, it was probably some unobvious bug with the allocators or something.

Also, unless you find yourself interested in it first, I might try to fix the software lightlevel error myself. Later. Tomorrow or so.

Re: Thing rendering by touched sectors

by Major Cooke » Mon Dec 26, 2016 10:11 am

I'm working on it now.

Re: Thing rendering by touched sectors

by Graf Zahl » Mon Dec 26, 2016 9:42 am

No idea. I need some info about stuff that caused a slowdown which I can reproduce. None of the people who reported it said whether they tested with software and hardware rendering and the dynamic light issue definitely was causing problems.

Re: Thing rendering by touched sectors

by Rachael » Mon Dec 26, 2016 9:32 am

What mod do you want to test with? I will compile a build myself.

Re: Thing rendering by touched sectors

by Graf Zahl » Mon Dec 26, 2016 9:17 am

ADynamicLight requires setting RenderRadius to -1 anyway so that should solve this problem. I also wonder if that may have been the cause of the slowdowns because lights can get quite large.
Aside from that I'm still waiting for feedback if the latest changes have improved matters.

Re: Thing rendering by touched sectors

by ZZYZX » Mon Dec 26, 2016 8:50 am

Anything on the dynlights though?

Re: Thing rendering by touched sectors

by Graf Zahl » Mon Dec 26, 2016 4:52 am

ZZYZX wrote:Some bugs showed up. Sorry for not testing this thoroughly enough before it was merged, currently actively working on it.
In software, "currently rendered" sector is used as the source of thing's brightness as opposed to thing->Sector. This didn't matter before, but now it means things receive wrong illumination when they are rendered from different sector.
Currently I see only one way of fixing this — duplicating some of the R_FakeFlat logic per-thing to calculate their own light levels (but only if the thing is linked to more than one sector).

That's bad. It took me quite a while to find out where it messes up and it's just business as usual for the software renderer: Fetching data from some global variable that gets set in an entirely unrelated part of the code. The global variable in question here is 'basecolormap'. This is stuff I once gave up upon when trying to add per-tier coloring of walls, because it's utterly messed up.
I marked the place in the code where this needs to be handled, but I'm sorry, this exceeds my comfort level with the software renderer.

Re: Thing rendering by touched sectors

by ReX » Sun Dec 25, 2016 6:41 pm

ZZYZX wrote:... if you don't want your physical collision box to be large.
The problem with using a radius as the measure for blocking is that, while it works well for circular (even square) actors, it works pretty badly for elongated actors. Enjay's example of a pipe illustrates this problem very well. Thankfully, we can use invisible 3D sectors or invisible bridge things for proper blocking.

But, it sounds like the RenderRadius method will solve the underlying problem of odd-shaped or long models disappearing. Many thanks for tackling this visual glitch.

Re: Thing rendering by touched sectors

by Major Cooke » Sun Dec 25, 2016 6:22 pm

Using AEoD, it causes slowdowns. Testing on D4D now.

Re: Thing rendering by touched sectors

by ZZYZX » Sun Dec 25, 2016 5:53 pm

Some bugs showed up. Sorry for not testing this thoroughly enough before it was merged, currently actively working on it.
  • In software, "currently rendered" sector is used as the source of thing's brightness as opposed to thing->Sector. This didn't matter before, but now it means things receive wrong illumination when they are rendered from different sector.
    Currently I see only one way of fixing this — duplicating some of the R_FakeFlat logic per-thing to calculate their own light levels (but only if the thing is linked to more than one sector).
  • OpenGL crashes. OpenGL crashes in an extremely weird way, only after some time playing, claiming that on line 373 thing is nullptr. Which is plainly not possible because if thing was nullptr it wouldn't get added to the list in the first place. edit: In debug build, it always crashes like this.
    Tested by playing TUTNT for 15 minutes in software, no crash. Testing in OpenGL, always (in debug build) receiving the same crash after killing second hellknight on spawn of TUTNT TNT01.
    Graf's opinion on this would be appreciated, as I don't even know where to start. It looks like some actor is M_Free'd without calling Destroy/UnlinkFromWorld (along with P_UnlinkRenderSectors) somehow. BUT ONLY IN OPENGL.
    UPDATE: by logging all linked/unlinked actors, I've narrowed the issue down to actors deriving from class DynamicLight, for example:

    Code: Select all

    actor 1239B4A8 linked in (as DynamicLight) - 1 sectors
actor 1239B4A8 linked out - 1 sectors
    Yet afterwards it crashes anyway while trying to render actor 1239B4A8. Definitely awaiting Graf's input. He knows his dynamic lights better.
  • Major Cooke also reported some extreme slowdowns, but hasn't yet told me the name of the wad to test against. Waiting on that.
    UPDATE: The slowdowns don't reproduce for me using a combination of AEoD+Chillax. Waiting until crashes are fixed, to test again.

Top