Immutable level sections

[Major Cooke]

What may be doable is to designate larger areas as immutable (i.e. you are not allowed to make any changes whatsoever to its geometry) so that they can be excluded from the BSP and rendered as one large batch from static data. But that's not something that's quickly added and it will require mapper intervention. But yes, that could at least partially solve the outside area performance problems.

Yes. Yes, yes, all my yes. This is something so powerfully needed in a few maps I know of with SUPERNatural, and I sure don't want this lost in the Closed section.

[Graf Zahl]

And I'm still moving this to "on hold". This is not something 'just' to be added. Otherwise I'd have done this long ago.

[Major Cooke]

Only curious... While I know this may affect things like vertex/floor/ceiling heights and slopes, what about color changing? Would that also be prohibited for the immutable sectors?

[Graf Zahl]

Sure. Anything that alters the properties would be off limits, otherwise it wouldn't be immutable, would it?

[Major Cooke]

GL lights affecting the surfaces too?

[Rachael]

GZDoom has always needed a static lighting system of some sort, we just got away with not having one because for the most part hardware has advanced to the point of not suffering huge performance losses by not having them.

But that being said, even in immutable levels on Unreal/Quake, movable objects that carry lights have always been allowed to illuminate immutable sections on their own. It does not make sense not to allow that.

[Major Cooke]

dpJudas - Today at 2:39 PM
btw it IS feasible to update things only when they change
its just that nobody has volunteered to write the function that marks what the playsim just invalidated

Well, I do think this would be of help.

[Graf Zahl]

dpJudas - Today at 2:39 PM
btw it IS feasible to update things only when they change
its just that nobody has volunteered to write the function that marks what the playsim just invalidated

Some may be easy, others are not. It definitely gets messy if vertices are getting moved around.
The main issue here is not the marking but setting the whole thing up so that it actually results in a performance gain - and that is far from trivial.

[Major Cooke]

Now, assuming there are no monsters in immutable sectors, would using models still present a bigger gain in performance for lots of map geometry over immutable sectors?

Something tells me it would simply because fewer vertices and lines, etc.

And even with no monsters in immutable sectors, BSP traversal will still be needed, I think...

[Graf Zahl]

As long as there is no collision detection needed, a model will always result in less overhead - simply because it can be rendered as one object and does not cause further complexity in the BSP tree.

[Apeirogon]

So gzdoom slowdowns because of an area size of a map?
Because if so, it can be solved using math, I think.