Having two problems with this:
- If there is ever Nil data on the input, the node will not work at all after that even if good data is present:
SplineBuffered (DX11.Geometry) Nil Kill.v4p (25.0 KB)
I can at least work around this by putting a Count/>/Switch sequence on the input of the DynamicBuffer that switches to a dummy 3D point if no data present.
- With dynamic input, there are occasional gaps in the geometry:
What seems odd is they stay in the same 3d spot, not moving along keeping the same ordinal spot.
SplineBuffered (DX11.Geometry) Gap Bug.v4p (25.1 KB)
Any/all help appreciated!
I think most geometry shaders will be pretty unhappy if you send nil to them. I don’t really know of a way to check the input buffer size from the patch.
For your gaps, it’s quite a well known issue. It’s basically due to using a single up-vector. In most cases it’s enough to tweak it a little, but there will always be a ‘blind spot’ (or rather angle). One solution (not impmented in the noodle node) is to use a buffer for this lookup value as well. In effect you are then needing to send a 2nd spline to act as a rail for your actual one.
About the gaps, yes I see now. Bummer. Could using a quaternion fix that? I thought those helped avoid axis-lock.
But the Nil behavior seems pretty broken, as that node is unusable from that point on, basically requiring restarting vvvv in a production setting. So internal state is being really screwed up somehow. Seems there should be some way of detecting it, fail gracefully, etc. - but I am no geometry shaderist. Imagine if in C# if you did a divide by zero once and then all divides stop working from then on! Yeow!
Again I am no shaderist, but I know the DX11 pack had some similar problems that got worked out. But at least for now this workaround avoids it. Thanks!
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.