Thing rendering by touched sectors

[ZZYZX]

subj.

CODE ALREADY DONE:
ZDoom PR: https://github.com/rheit/zdoom/pull/964 (closed/merged)
GZDoom PR: https://github.com/coelckers/gzdoom/pull/130 (closed/merged)

So basically, as a mapper, I've always had this problem with actors not being drawn if the sector that their CENTER is in is not drawn.
Primitive test case: http://www.mediafire.com/file/ic36up6g7 ... ermind.wad
The spider mastermind sprite is quite large, as well as it's radius, and it will be hidden from view in most Doom-related ports. My engine edit prevents the disappearance.

Currently, the largest value of Radius/RenderRadius properties is used to query sectors around an actor, and if any of these sectors is drawn, the actor is drawn as well, as opposed to old way where an actor is only drawn along with it's center sector.
The main reason why RenderRadius was chosen to add instead of simply always using Radius, is because it's quite hard to edit your map when it's filled with huge rectangles that overlap everything. Besides, things like street lamps and trees are generally larger than their collision box.

Accept pls, this would infinitely help with large models constantly disappearing from sight like they do in Total Chaos beta.


P.S. I've tested this on Frozen Time as a very open map with a lot of things being rendered at once and found no noticeable performance regressions. Maps with huge thing counts (-->nuts2.wad tier) might become a tiiiiiiny little bit slower due to more complex operation performed instead of just checking a single sector. Not very much slower anyway.
P.P.S. Haven't tested looking at the same thing physically and through a portal at the same time (might break due to validcount being introduced). Nevermind, it doesn't break. Works properly.
P.P.P.S. Pull request made into GZDoom since it affects both normal and hardware renderer. Pretty sure if it's accepted it can be easily backported to ZDoom. Sorry for that.

[Nash]

I would very much like this. When used per-actor this would be a great way to help with large decorative models not disappearing from the view.

[Graf Zahl]

Can you do a PR for ZDoom? Merging this would be a bit messy otherwise.
Also, this needs some provisions to exclude invisible actors - especially bridge things - from being inserted into the render lists. Having this bogged down by a large amount of stuff that requires processing but won't be rendered can be quite costly, especially since bridges can be quite large. It's probably best to give InvisibleBridge a RenderRadius of 0.

[ZZYZX]

Can you do a PR for ZDoom? Merging this would be a bit messy otherwise.
Also, this needs some provisions to exclude invisible actors - especially bridge things - from being inserted into the render lists. Having this bogged down by a large amount of stuff that requires processing but won't be rendered can be quite costly, especially since bridges can be quite large. It's probably best to give InvisibleBridge a RenderRadius of 0.

It takes the max value between Radius and RenderRadius to support classic actors. I think it's easier to put a check for RenderStyle being None in addition to already existing NOSECTOR check.
Also, the processing is only done when things move around (and bridges usually don't move around), so it won't matter much. Although I'm going to add the check anyway.

Also, for whatever reason I'm unable to fork both zdoom and gzdoom. When I click on "fork" at https://github.com/rheit/zdoom, it just redirects me to gzdoom page in my own repo. Is that normal? What to do?
(any way to make a pull request to ZDoom from a level 2 zdoom->gzdoom fork? Because right now, if I simply select zdoom repo to make a pull request into, the page says "top 250 commits displayed" and hangs up.)

[Graf Zahl]

Can you do a PR for ZDoom? Merging this would be a bit messy otherwise.
Also, this needs some provisions to exclude invisible actors - especially bridge things - from being inserted into the render lists. Having this bogged down by a large amount of stuff that requires processing but won't be rendered can be quite costly, especially since bridges can be quite large. It's probably best to give InvisibleBridge a RenderRadius of 0.

It takes the max value between Radius and RenderRadius to support classic actors. I think it's easier to put a check for RenderStyle being None in addition to already existing NOSECTOR check.
Also, the processing is only done when things move around (and bridges usually don't move around), so it won't matter much. Although I'm going to add the check anyway.

Trust me, it does matter. I tried a similar approach some 12 years ago and it caused massive performance issues with mods that made heavy use of bridge things which due to their large size can get linked into several sectors. Do this with a few 100 things and you will notice.

[Nash]

ZZYZX:

At 6:53 in your video, you remarked about why is the view "snapping" / teleporting when climbing the steps, instead of smoothly moving upwards?

The answer is simple. ZDoom's built-in first person camera has Z interpolation, and this is what prevents the view from snapping when you climb up steps in Doom.

The interpolation only works for the first person camera - if you activate the chasecam, you will see the view snapping when you climb up steps (even in stock Doom).

The problem with Total Chaos is that it's not letting the game natively render to the first person camera, and instead is just placing a fullscreen HUDMessage camera texture in front of the player, and it seems the Z isn't interpolated in camera textures.

I wrote a long post here encouraging to Wad'a'holic ditch the entire camera texture setup, and it looks like this Z view snapping is another reason to.

Sorry for the offtopic. Carry on.

[_mental_]

Also, for whatever reason I'm unable to fork both zdoom and gzdoom. When I click on "fork" at https://github.com/rheit/zdoom, it just redirects me to gzdoom page in my own repo. Is that normal? What to do?
(any way to make a pull request to ZDoom from a level 2 zdoom->gzdoom fork? Because right now, if I simply select zdoom repo to make a pull request into, the page says "top 250 commits displayed" and hangs up.)

Instead of forking add a remote to your local repository. From command line it will like this:

Code: Select all

git remote add rheit https://github.com/rheit/zdoom.git
git fetch --all
git checkout -b z_master rheit/master

You will have ZDoom's master branch checked out. Now you can create PR branch as usual and do PRs to ZDoom too.

[ZZYZX]

Trust me, it does matter. I tried a similar approach some 12 years ago and it caused massive performance issues with mods that made heavy use of bridge things which due to their large size can get linked into several sectors. Do this with a few 100 things and you will notice.

Do you remember any particular mod/level names? (I'm curious of the current performance of the build that I have here, and, I'll have to test the optimization on something)

edit: https://github.com/rheit/zdoom/pull/964 here's the ZDoom PR. STYLE_None actors are now excluded.
Thanks to _mental_ for the tip!

[ZZYZX]

On a second thought, RenderStyle can easily change at runtime. Reverted that, and did it like you said with RenderRadius -1 disabling the additional checks (i.e. only center is used).
Rest of the logic is left untouched, that is, RenderRadius 0 is basically "use Radius instead".

Classes CustomBridge and InvisibleBridge were given RenderRadius of -1.

[Graf Zahl]

Ok, so far. Two things needed fixing. First, RenderRadius needs to be serialized and CustomBridge must handle its radius normally because it can be visible. Only the Hexen bridge is invisible.

One other thing: Essentially this implements just a variation of the existing touching_thinglist and touching_sectorlist with some minor variations in semantics so ideally it should use the same code after some generalization. But it uses a completely different underlying data type and now I'm wondering which is more efficient - Boom's msecnodes or std::forward_list.

[Major Cooke]

Perhaps a function to change the RenderRadius would be handy, since we can now change radius and height with A_SetSize.

[Graf Zahl]

Now that this has been merged with ZDoom, can you please do a PR for the GL related changes in GZDoom so I can close this thread?

[Enjay]

Question: from an end user's perspective (particularly when working with models), does this now mean that if an actor has a radius value that means its longest visible dimension is inside its actual underlying dimension, the actor should remain visible regardless of whether the sector that the centre of the actor is placed in is visible or not?

So, for example, if an actor for a long, thin pipe model
(something like...)

---

is given a radius big enough that the model's full length fits inside the square of the actor, the model will always be drawn whenever the model should be visible.

i.e.

---

If so: that'll make working with big model actors much easier.

[ZZYZX]

Enjay, yes.
But you can also use RenderRadius if you don't want your physical collision box to be large.
Also, brb, GZDoom PR.

edit:

Now that this has been merged with ZDoom, can you please do a PR for the GL related changes in GZDoom so I can close this thread?

This is merged into ZDoom, but not GZDoom. At least it's not in master. Which means I can't simply add the code and make a PR. Wut do (x2)?

[Graf Zahl]

I just merged it.