negative renderradius disables rendering

Wed Nov 10, 2021 6:35 am

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

Re: negative renderradius disables rendering

Wed Nov 10, 2021 6:59 am

It already happened in "- use msecnode_t's for the touching_renderlists instead of std::forward_list."
https://github.com/coelckers/gzdoom/com ... 37e4e6211a

Re: negative renderradius disables rendering

Wed Nov 10, 2021 7:19 am

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

Wed Nov 10, 2021 7:32 am

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.

Re: negative renderradius disables rendering

Wed Nov 10, 2021 7:50 am

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

Wed Nov 10, 2021 8:16 am

The old Doom behavior is to just not provide a RenderRadius.

Re: negative renderradius disables rendering

Wed Nov 10, 2021 8:23 am

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.

Re: negative renderradius disables rendering

Wed Nov 10, 2021 9:01 am

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.

Re: negative renderradius disables rendering

Wed Nov 10, 2021 9:48 am

I can't really say. It's just what I got from a quick look.

Re: negative renderradius disables rendering

Wed Nov 10, 2021 12:01 pm

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

Re: negative renderradius disables rendering

Wed Nov 10, 2021 1:14 pm

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."

Re: negative renderradius disables rendering

Thu Nov 11, 2021 11:42 am

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:
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, &sector_t::touching_thinglist);   // Attach to thing
-      if (renderradius >= 0) touching_rendersectors = P_CreateSecNodeList(this, MAX(radius, renderradius), ctx != nullptr ? ctx->render_list : nullptr, &sector_t::touching_renderthings);
+      if (renderradius == 0)
+         touching_rendersectors = P_CreateSecNodeList(this, radius, ctx != nullptr ? ctx->render_list : nullptr, &sector_t::touching_renderthings, true);
+      else if (renderradius > 0)
+         touching_rendersectors = P_CreateSecNodeList(this, MAX(radius, renderradius), ctx != nullptr ? ctx->render_list : nullptr, &sector_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;

Re: negative renderradius disables rendering

Fri Nov 12, 2021 8:30 am

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

Re: negative renderradius disables rendering

Fri Nov 12, 2021 10:34 am

Please leave this thing alone. I won't change how this works.

Re: negative renderradius disables rendering

Fri Nov 12, 2021 10:52 am

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.