Animation support for 'visibility'

[calrk]

I've been working with some models that use the visibility flag in their animations to show/hide meshes within the object. These models have been made in Maya, exported as fbx and tested in Unity with the flag working. This can be set as shown below from Maya:

I read the specification for the animation and it says The path may be "translation", "rotation" or "scale"...

I was wondering if it also supported the visibility property or if there were any plans to support it in future?

[donmccurdy]

Currently visibility animation cannot be stored in glTF, although you could hack it with discrete/step animations of position or scale. Proper visibility animation would seem like a reasonable addition through #1301, but that will likely take some time.

[calrk]

Yeah I've suggested using the position or scale, so will enforce that the models follow that.

Thanks.

[ctedin]

Visibility parameter control would be great. Scaling works pretty well though, in a pinch.

[spiraloid]

I have a modular asset with lots of parts that need to be toggled on or off. showing them all at once, even scaled to 0.001 would overflow the polycount of the scene. is there a workable alternative?

[emackey]

There's no formal extension proposal for visibility yet (EDIT: Well there is #1790 but I can't tell if it has any momentum).

One option is to have the renderer check for scale being non-zero before rendering each node, and skip rendering of any nodes (and their children) when zero scale is encountered. Child nodes cannot produce any meaningful result at any scale when a parent is zero scale, so may also be skipped.

It seems likely that any future visibility extension would incur the almost same performance cost, adding a test per node at render time. Perhaps a Boolean test would be marginally faster than three scale axes floating-point tests, but would come at the expense of new code and mechanisms built for the purpose of animating a Boolean value over time. It seems difficult to justify a whole new category of animation import and export here, when one could get the same information by checking the scale of each node before rendering.

(Also note, glTF animations require the target node to avoid using a full transform matrix, and instead animate only the individual translate, rotate, and scale vectors as appropriate. This means that any animated scale will not be hidden inside a TRS matrix, and instead will be called out as a 3-component vector of scale by the animation. So it is safe to just look for those animations when implementing this optimization).

[donmccurdy]

I've been thinking of this under a general bucket of material animation, so far. It could plausibly be handled by #1790 (defines variant "states", not timed keyframes), #1301 (arbitrary property animation), or #1889 (procedural graph-based material inputs).

[andybak]

Can this issue be reopened? Or can it be closed with a proper reason (i.e. covered by another ticket, wontfix)?

Currently you need to read the entire conversation to understand what decisions have been made (and it's still not clear)

Personally I find the lack of visibility keyframes to be a strange omission and the workarounds are fairly unappealing.

[donmccurdy]

FWIW I am now setting scale 0 <-> 1 with 'step' interpolation successfully in these cases.

For me (speaking personally) this lands in a category that should probably be included in some future glTF version, but which isn't independently important enough — since simple workarounds exist — to create a separate extension for it.

[andybak]

FWIW I am now setting scale 0 <-> 1 with 'step' interpolation successfully in these cases.

How would that handle one obvious usecase that springs to mind - a sequence of meshes that are too heavy to be displayed all at once but are sequenced to play one after another?

I imagine the question is somewhat implementation dependent but generally speaking do 0 scale meshes get optimized away for would some part of the processing cost still apply?

[donmccurdy]

I'd expect nearly all engines to implement frustum culling in some form. Certain implementations may not optimize away scale=0 perfectly, but in my tools that has been the case. Sequences of meshes are the main use case I'm aware of for this, as you mention.

[spiraloid]

I implemented moving the objects -100000 and it works fine. Thanks for the tips!

[mrBoogaloo]

I'll have to try the translation trick, scaling with stepped interpolation worked for glTF but broke when converting to USDZ. Fingers crossed!