Rigid Follower Node renders rotated incorrectly
Squishy
Posts: 460
What's up with this [Rigid Follower Node], I set this up and it appears fine even in Iray preview render, but then in full render the attachment gets rotated as shown.
Post edited by Richard Haseltine on
Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
Getting the impression this is a very old bug:
https://www.daz3d.com/forums/discussion/246401/rigid-follow-node-bug-and-workaround
e: yeah this is 100% repeatable, I'm really surprised this has been left broken for so long!
I submitted help request Request #279578 about this issue on August 31, 2018. That request was later closed and marked "Solved" by Daz, even though the last comment from customer service was "I am sending this back to our QA Team to review." The problem was not fixed, nor did they explain why it happens. I did discover on my own that changing the Smoothing from Base Shape Matching to Generic would work wround the rigid follow node movement, in my case, but Generic smoothing was not a good choice for the item I was using at the time. You might try that smoothing change and see if it helps in your case.
Edit to add: Since my help request was closed and not "added to the bug tracker", maybe the developers were never even informed about the problem.
This is such a dumb bug it's hard to believe it's just been left broken for four years, lmao.
I tried changing smoothing to Generic as you suggested but that produced a different bug - overall it's a better workaround for the end user but it still flips the model 180 degrees, although at least it flips it the same in both preview and final render.
Well at least that way you can fix the error before final render. I suggest that you submit a help request with your illustrations of the problem. Maybe it will get farther than my 2018 request.
Yeah I have, and I'm going to add the information about what happens when you change the smoothing mode too, thanks for that info because it never would have occurred to me to try that.
I also reported my smoothing mode discovery in my request. Their response was to update the single product that I used as an example, to change its smoothing, even though Generic smoothing was not really effective for that product. I had pointed out the smoothing only as a clue to the rigid follow node problem. So be on the lookout for that kind of response to your request, and if so, try to redirect the discussion to the real problem.
I think what's going on is internally, D|S is making copies of the bits of geometry you see in preview and rendering those (I know it has to do this for subdivision and smoothing anyway) - at some point there's a -90 or +180 or something incorrectly applied, probably because that bit of code was adapted from code from a plugin for an app with a different coordinate orientation. Sort of like the frustrating orientation quirks associated with OBJ import/export.
I hadn't noticed that the error was always 90 or 180 degrees. I'll keep an eye out for that.
It doesn't show that way numerically because what you see is the end result (which also makes it more annoying to correct) but you can visually see it's getting rotated 90 degrees on something's Y axis (or 180 degrees on your workaround with smoothing set to generic). I don't think it's helpful to know this since you can't easily just reverse that on parameters, as far as I can see anyhow.
if you submit a ticket to Daz, don't tell them you found a workaround they'll just consider the problem fixed and close it!
all around a puzzling experience ¯\_(ツ)_/¯
So, through a lot of experimentation, it turns out that the bug happens when you create the Rigid Follower Node on a model that has a subdivision modifier. If you first set the Resolution Level to Base, and then create your Rigid Follower Node, and then set the Resolution Level back to High Resolution, it seems to work. The red flag to look for is the orientation indicators (XYZ red/yellow/blue lines) - in this pic, the correct one (left) shows oriented square with the world origin, the bad one (right) shows some odd rotation (click for full size)
This problem also shows up in some poses even in preview!
lol it's not super consistent and testing it is making the app crash a lot.
NB: if you get a bad result when trying this with subdivision resolution level set to Base, quit D|S and restart it, and do whatever you're doing with as minimal a load as possible (i.e. don't try to reload any screwed up RFN if you can help it, remake it from scratch).
NB: you can't just manually zero the rotations on the RFN object, I tried that, it just goes more crazy, it seems you must get it created cleanly or retry until you do.
Wow that's maddening, I got it to work that first time that I took pictures of, and now it won't work again!
e: it worked when the follower was not conformed to anything!
e: it also looks like this bug happens when you select polygons that are too small, or possibly just their shape/normal orientation, I'm not sure. I had the problem when making a selection like this:
but it's OK when I make a slightly bigger selection:
this is counter to a lot of the tutorials out there that suggest you make the smallest selection possible, but whatever works I don't really care!
There is still some kind of gimbal lock looking crap going on if you rotate the hip too much:
I didn't even get a chance to try, and already it seems you've debunked the subD theory. Is that right?
I am not sure, but yes it might just be that when the polygon selection is too small this problem occurs. It might be both! Even when it works it still isn't 100% in all situations, but as you had discovered before, when a pose makes the RFN child flip, you can switch Smoothing Type to Generic and it works - on the right is the one set to Base Shape Matching (flipped), left is Generic (correct):
e: part of the problem is that at base resolution it always looks correct and works, even if the polygon selection is too small to work at high resolution
these are identical and set up identically, just one is set to high resolution and the other at base:
seems pretty reproducible