Negative values disable additional sectors disregarding Radius value! This means that the actor with RenderRadius -1 will only be drawn if the sector under its X/Y coordinates is visible.
negative renderradius disables rendering
Moderator: GZDoom Developers
Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.
- drfrag
- Vintage GZDoom Developer
- Posts: 3141
- Joined: Fri Apr 23, 2004 3:51 am
- Location: Spain
- Contact:
negative renderradius disables rendering
According to the wiki actors should be rendered and they were in latest ZDoom devbuilds. But after the refactoring they are not rendered at all. It happened in 2.3 and 2.4 and still happens now.
- drfrag
- Vintage GZDoom Developer
- Posts: 3141
- Joined: Fri Apr 23, 2004 3:51 am
- Location: Spain
- Contact:
Re: negative renderradius disables rendering
It already happened in "- use msecnode_t's for the touching_renderlists instead of std::forward_list."
https://github.com/coelckers/gzdoom/com ... 37e4e6211a
https://github.com/coelckers/gzdoom/com ... 37e4e6211a
- drfrag
- Vintage GZDoom Developer
- Posts: 3141
- Joined: Fri Apr 23, 2004 3:51 am
- Location: Spain
- Contact:
Re: negative renderradius disables rendering
Yeah it's the first commit exhibiting the problem, it didn't happen on "- removed the global 'sector_list' variable."
Re: negative renderradius disables rendering
Man, who wrote that?
i don't understand why anyone would use a negative render radius. It's obviously an invitation to obtain weird undefined behavior. I can't think of a valid use-case for the effect described.
i don't understand why anyone would use a negative render radius. It's obviously an invitation to obtain weird undefined behavior. I can't think of a valid use-case for the effect described.
- drfrag
- Vintage GZDoom Developer
- Posts: 3141
- Joined: Fri Apr 23, 2004 3:51 am
- Location: Spain
- Contact:
Re: negative renderradius disables rendering
But i think it was the intended effect, to get the old Doom behaviour. Why would a negative value disable rendering? That makes little sense.
Re: negative renderradius disables rendering
The old Doom behavior is to just not provide a RenderRadius.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49056
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: negative renderradius disables rendering
According to the source, render radius 0 restricts it to the source sector, and -1 removes the actor even from its origin sector's render list. Some actors like invisible bridges use this because they can otherwise put a huge drag on that list's performance.
Sounds like a problem on the Wiki.
Sounds like a problem on the Wiki.
- drfrag
- Vintage GZDoom Developer
- Posts: 3141
- Joined: Fri Apr 23, 2004 3:51 am
- Location: Spain
- Contact:
Re: negative renderradius disables rendering
For me this was really confusing from the start but that's not what i see here:
viewtopic.php?f=18&t=54718#p964839
As i understand it when it's zero radius was meant to be used the same way to query sectors around the actor.
The 'logic' changed several times too. Well i see that it worked differently before.
viewtopic.php?f=18&t=54718#p964839
As i understand it when it's zero radius was meant to be used the same way to query sectors around the actor.
The 'logic' changed several times too. Well i see that it worked differently before.
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49056
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: negative renderradius disables rendering
I can't really say. It's just what I got from a quick look.
- drfrag
- Vintage GZDoom Developer
- Posts: 3141
- Joined: Fri Apr 23, 2004 3:51 am
- Location: Spain
- Contact:
Re: negative renderradius disables rendering
The old code added the thing to its own sector and that part was outside the if (thing->renderradius >= 0) :
https://github.com/coelckers/gzdoom/com ... 2aa14L6675
In the new code to restrict it to the sector of the thing i think i'd need an additional parameter for P_CreateSecNodeList in the else :
https://github.com/coelckers/gzdoom/com ... 57327dR464
https://github.com/coelckers/gzdoom/com ... 2aa14L6675
In the new code to restrict it to the sector of the thing i think i'd need an additional parameter for P_CreateSecNodeList in the else :
https://github.com/coelckers/gzdoom/com ... 57327dR464
- drfrag
- Vintage GZDoom Developer
- Posts: 3141
- Joined: Fri Apr 23, 2004 3:51 am
- Location: Spain
- Contact:
Re: negative renderradius disables rendering
I think you're right and the specification changed but the original implementation did not respect it. Seems the wiki it's based on an older logic?
However i don't see how zero renderradius restricts rendering to the source sector. I think that's not the case since in ZDoom 2.4 software it's pretty obvious that "things receive wrong illumination when they are rendered from different sector."
However i don't see how zero renderradius restricts rendering to the source sector. I think that's not the case since in ZDoom 2.4 software it's pretty obvious that "things receive wrong illumination when they are rendered from different sector."
- drfrag
- Vintage GZDoom Developer
- Posts: 3141
- Joined: Fri Apr 23, 2004 3:51 am
- Location: Spain
- Contact:
Re: negative renderradius disables rendering
I think the old version it's fixed (zero case). If you think it's correct and there's interest i could make a PR, after all it's not a big deal.
Code: Select all
diff --git a/src/p_local.h b/src/p_local.h
index 098c9c4ff3..2f0a311148 100644
--- a/src/p_local.h
+++ b/src/p_local.h
@@ -397,7 +397,7 @@ nodetype *P_AddSecnode(linktype *s, AActor *thing, nodetype *nextnode, nodetype
template<class nodetype, class linktype>
nodetype* P_DelSecnode(nodetype *, nodetype *linktype::*head);
-msecnode_t *P_CreateSecNodeList(AActor *thing, double radius, msecnode_t *sector_list, msecnode_t *sector_t::*seclisthead);
+msecnode_t *P_CreateSecNodeList(AActor *thing, double radius, msecnode_t *sector_list, msecnode_t *sector_t::*seclisthead, bool restricted = false);
double P_GetMoveFactor(const AActor *mo, double *frictionp); // phares 3/6/98
double P_GetFriction(const AActor *mo, double *frictionfactor);
diff --git a/src/p_maputl.cpp b/src/p_maputl.cpp
index 053f44c13a..b191902060 100644
--- a/src/p_maputl.cpp
+++ b/src/p_maputl.cpp
@@ -463,7 +463,10 @@ void AActor::LinkToWorld(FLinkContext *ctx, bool spawningmapthing, sector_t *sec
// at sector_t->touching_thinglist) are broken. When a node is
// added, new sector links are created.
touching_sectorlist = P_CreateSecNodeList(this, radius, ctx != nullptr? ctx->sector_list : nullptr, §or_t::touching_thinglist); // Attach to thing
- if (renderradius >= 0) touching_rendersectors = P_CreateSecNodeList(this, MAX(radius, renderradius), ctx != nullptr ? ctx->render_list : nullptr, §or_t::touching_renderthings);
+ if (renderradius == 0)
+ touching_rendersectors = P_CreateSecNodeList(this, radius, ctx != nullptr ? ctx->render_list : nullptr, §or_t::touching_renderthings, true);
+ else if (renderradius > 0)
+ touching_rendersectors = P_CreateSecNodeList(this, MAX(radius, renderradius), ctx != nullptr ? ctx->render_list : nullptr, §or_t::touching_renderthings);
else
{
touching_rendersectors = nullptr;
diff --git a/src/p_secnodes.cpp b/src/p_secnodes.cpp
index b351f0e580..58b1820fc5 100644
--- a/src/p_secnodes.cpp
+++ b/src/p_secnodes.cpp
@@ -219,7 +219,7 @@ void P_DelSeclist(portnode_t *node, portnode_t *FLinePortal::*sechead)
//
//=============================================================================
-msecnode_t *P_CreateSecNodeList(AActor *thing, double radius, msecnode_t *sector_list, msecnode_t *sector_t::*seclisthead)
+msecnode_t *P_CreateSecNodeList(AActor *thing, double radius, msecnode_t *sector_list, msecnode_t *sector_t::*seclisthead, bool restricted)
{
msecnode_t *node;
@@ -239,7 +239,7 @@ msecnode_t *P_CreateSecNodeList(AActor *thing, double radius, msecnode_t *sector
FBlockLinesIterator it(box);
line_t *ld;
- while ((ld = it.Next()))
+ while (!restricted && (ld = it.Next()))
{
if (!box.inRange(ld) || box.BoxOnLineSide(ld) != -1)
continue;
- drfrag
- Vintage GZDoom Developer
- Posts: 3141
- Joined: Fri Apr 23, 2004 3:51 am
- Location: Spain
- Contact:
Re: negative renderradius disables rendering
I've done a PR but i don't know the performance impact of this thing, at first there were slowdowns but that was the STL version.
https://github.com/coelckers/gzdoom/pull/1506
https://github.com/coelckers/gzdoom/pull/1506
- Graf Zahl
- Lead GZDoom+Raze Developer
- Posts: 49056
- Joined: Sat Jul 19, 2003 10:19 am
- Location: Germany
Re: negative renderradius disables rendering
Please leave this thing alone. I won't change how this works.
- drfrag
- Vintage GZDoom Developer
- Posts: 3141
- Joined: Fri Apr 23, 2004 3:51 am
- Location: Spain
- Contact:
Re: negative renderradius disables rendering
That's why i asked, if the performance impact is not big it's not worth changing it. The wiki needs to be updated anyway.
The code is in LZDoom now just in case it enhances performance somehow, seems to work well so far.
The code is in LZDoom now just in case it enhances performance somehow, seems to work well so far.