ZDoom

Indeed it has. You can close this one as fixed.

Correct me if I'm wrong, but hasn't this been fixed?

[quote="dpJudas"]
Only catch is, we can only do this for polyobjs. For closed doors we have no idea which sectors may open or close, right?
[/quote]

Mostly correct. From analyzing the map it will be possible to detect all regular doors but it's by no means foolproof. There is always a chance that some sector might open up that is initially closed but has no clear indicators - and the reverse can only happen. So, since the code needs to be careful it may only have a 99% success rate of finding doors - and it will also require some changes to the exclusion logic, which right now only looks at a line's one-sidednesss.

Also, can you please do any work on this in a work branch? Even the one commit you pushed today is something I wouldn't add to the upcoming release for lack of stress testing.

It currently uses 16 bytes per linedef (AABBTreeLine). The tree nodes use 32 bytes per node (AABBTreeNode). There is one node per linedef, plus the additional ones needed to build the tree. For a perfectly balanced tree and 10,000 lines it would be about 160,000 bytes of line data and 1,048,000 bytes of node data.

The lines are currently organized in the same order as in level.lines. The nodes depends on how they end up sorted into AABB groups. I need to check the code, but I think it should be possible to store the polyobjs at the end for both lists.

Only catch is, we can only do this for polyobjs. For closed doors we have no idea which sectors may open or close, right?

Edit: fixed my broken binary tree size math.

[quote="dpJudas"]
1) It does a full re-upload of the AABB tree. The larger the map, the more expensive this will get. Right now it uses glBufferData to upload it, but maybe we can find a more efficient way to upload the changes as most of the tree isn't changing.
[/quote]

Considering that the shadow map requires shader storage buffers I think we can use a persistently mapped buffer here and only copy the changed parts. It's hard to say how this will affect shader performance, though, but it should always be better than a full buffer upload by the driver. These can bring down performance quite efficiently. The main question, of course, is, how large is an AABB tree for a map with 10000 single sided linedefs?

I don't know how this is organized, but if the polyobject stuff is always at the end of the buffer and its size does not change, it may be better to use glBufferSubData to upload it, if a persistently mapped buffer does not work that well.

I pushed a version that updates the AABB tree when the polyobj lines move. There's two main problems left, though:

1) It does a full re-upload of the AABB tree. The larger the map, the more expensive this will get. Right now it uses glBufferData to upload it, but maybe we can find a more efficient way to upload the changes as most of the tree isn't changing.

2) UpdateShadowMap() is called before interpolation is done. That causes some visual glitches on the wall itself for Marisa's map. I tried to move the UpdateShadowMap() call into RenderViewpoint, right after R_SetupFrame was called, but this doesn't work for some reason.

[quote="dpJudas"]I'm a bit surprised shadowmaps are blocked by polyobjs. Unless the lines of polyobjs happens to also be stored in level.lines - I don't know enough about the polyobjs to say.
[/quote]

Of course they are. What I saw in one Hexen map was that the shadowmap reflected the polyobject's position right after map load and never got updated - which makes sense considering how it all works.

[quote]
About updating cost - the shader time will be the same regardless. What needs to be done is to update the AABB tree and upload it. If the polyobj lines are stored at the end of the list of lines then it could probably get away with just doing a partial update of the storage buffer.

The nodes in an AABB tree has the nice property that the AABB for each node is allowed to overlap other nodes - it will just make it less efficient. This means the general node tree does not have to be rebuilt if some lines move. It can just update the AABB's of the parent nodes. Is there a way to know which level.lines belong to polyobjs?
[/quote]

Yes, of course this is known. There's a flag for this on the sidedefs but this can be accessed by the linedefs as well if needed.

[quote]
For closed door lines the biggest problem is figuring out when they open or close. LevelAABBTree needs a fast way to know which lines changed without iterating over all.[/quote]

Figuring out when they open or close can be done from the playsim. I guess the bigger issue is to know which two sided lines are actual candidates for changing their clipping state.

I'm a bit surprised shadowmaps are blocked by polyobjs. Unless the lines of polyobjs happens to also be stored in level.lines - I don't know enough about the polyobjs to say.

About updating cost - the shader time will be the same regardless. What needs to be done is to update the AABB tree and upload it. If the polyobj lines are stored at the end of the list of lines then it could probably get away with just doing a partial update of the storage buffer.

The nodes in an AABB tree has the nice property that the AABB for each node is allowed to overlap other nodes - it will just make it less efficient. This means the general node tree does not have to be rebuilt if some lines move. It can just update the AABB's of the parent nodes. Is there a way to know which level.lines belong to polyobjs?

For closed door lines the biggest problem is figuring out when they open or close. LevelAABBTree needs a fast way to know which lines changed without iterating over all.

From what I have experienced, shadowmaps do not get updated when polyobjects move. The main question here is, how costly would a per-frame update be? This could also be useful for closed doors. But in the end what decides what can be done here is solely the performace of the whole thing.

Even on fast modern graphics hardware, shadowmaps can adversely affect performance.

[url=https://marisakirisa.me/tmp/polyshadow_m.zip]Here[/url]'s a map showing this in action.

Normally I would assume that they wouldn't cast shadows at all, or at least, that the shadows cast would move with them, but neither of those are the case.

Shadowmaps also seem to be affected by the size of sectors behind static portal lines, but that's another issue.