SplineBuffered (DX11.Geometry) Bugs

[mediadog]

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!

[everyoneishappy]

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.

[mediadog]

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!