[Added] Thing rendering by touched sectors

Moderator: GZDoom Developers

Thing rendering by touched sectors

Postby ZZYZX » Sat Dec 24, 2016 10:07 pm

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.
Last edited by ZZYZX on Sun Dec 25, 2016 4:55 pm, edited 8 times in total.
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: Thing rendering by touched sectors

Postby Nash » Sun Dec 25, 2016 1:45 am

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.
User avatar
Nash
AKA Nash Muhandes! Twitter/Facebook/Youtube: nashmuhandes
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Twitch ID: nashmuhandes
Github ID: nashmuhandes

Re: Thing rendering by touched sectors

Postby Graf Zahl » Sun Dec 25, 2016 4:06 am

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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Thing rendering by touched sectors

Postby ZZYZX » Sun Dec 25, 2016 4:12 am

Graf Zahl wrote: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.)
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: Thing rendering by touched sectors

Postby Graf Zahl » Sun Dec 25, 2016 4:20 am

ZZYZX wrote:
Graf Zahl wrote: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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Thing rendering by touched sectors

Postby Nash » Sun Dec 25, 2016 4:23 am

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.
User avatar
Nash
AKA Nash Muhandes! Twitter/Facebook/Youtube: nashmuhandes
 
 
 
Joined: 27 Oct 2003
Location: Kuala Lumpur, Malaysia
Twitch ID: nashmuhandes
Github ID: nashmuhandes

Re: Thing rendering by touched sectors

Postby _mental_ » Sun Dec 25, 2016 4:26 am

ZZYZX wrote: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 allExpand view
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.
_mental_
 
 
 
Joined: 07 Aug 2011

Re: Thing rendering by touched sectors

Postby ZZYZX » Sun Dec 25, 2016 4:41 am

Graf Zahl wrote: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!
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: Thing rendering by touched sectors

Postby ZZYZX » Sun Dec 25, 2016 5:40 am

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.
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: Thing rendering by touched sectors

Postby Graf Zahl » Sun Dec 25, 2016 7:33 am

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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Thing rendering by touched sectors

Postby Major Cooke » Sun Dec 25, 2016 11:26 am

Perhaps a function to change the RenderRadius would be handy, since we can now change radius and height with A_SetSize.
User avatar
Major Cooke
QZDoom Maintenance Team
 
Joined: 28 Jan 2007

Re: Thing rendering by touched sectors

Postby Graf Zahl » Sun Dec 25, 2016 12:29 pm

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?
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Re: Thing rendering by touched sectors

Postby Enjay » Sun Dec 25, 2016 1:20 pm

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...)
Spoiler:

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.
Spoiler:


If so: Image that'll make working with big model actors much easier.
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Re: Thing rendering by touched sectors

Postby ZZYZX » Sun Dec 25, 2016 3:43 pm

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:
Graf Zahl wrote: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)?
User avatar
ZZYZX
le chat du rabbin
 
 
 
Joined: 14 Oct 2012
Location: Ukraine
Discord: ZZYZX#1394
Github ID: jewalky

Re: Thing rendering by touched sectors

Postby Graf Zahl » Sun Dec 25, 2016 3:57 pm

I just merged it.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Next

Return to Closed Feature Suggestions

Who is online

Users browsing this forum: No registered users and 3 guests