Bug: Alembic Import changing face count geometry issues.

[lennart.oberscheidt]

Hey everyone,

currently importing speedtree trees into maya and we have noticed serious issues with alembic import. There is a known problem with grow animation (geometry before the first frame of animation of the leaves is"stuck", and the full tree is visible before the first frame of leaf grow, essentially the full tree is visible on all frames where there actually is no geometry for the tree leaves, i.e. on all frames where there are actually 0 polygons in the shape). AFAIK Autodesk is aware of that. This issue does not happen in any other applications (Houdini, Cinema4D). So thats one problem with alembic import in maya which honestly absolutely needs to be fixed asap in my opinion as we're dealing with changing geometry counts (and zero faces) regularly. The only workaround is manually keyframing the visibiliy off/on before the frames the leaf geometry starts to appear (which absolutely requires a seperate shape for the leaves). 

However, our problem is a different one, possibly related, hence to long wall of text. I can supply demo scenes if needed. I'll send in a bug report, although I'll just link to this thread since I honestly have to get the shots working and find a work around to this issue, and after days of troubleshooting a different maya issue I don't feel like playing beta-tester (again and again). It's frustrating lately, really. We've done extensive testing and yes, this is specific a Maya problem. 

With grow and wind animation in the alembic caches, leaves are flickering when rendering with arnold. As always, we first assumed sampling problems, wind animation moving the leaves quite a large amount on the frame etc. However, that's not it. Locking sampling pattern does not help, sampling excessively with 20/4/4 doesn't help, it's not the shader of the leaves (simple lambert flickers as well), The geometry is corrupt in cyclic patterns of about 4-5 frames. The leaves seem to appear and disappear or flip normals. Post unlocking normals and soften/harden on the caches doesn't help. At first, we thought the problem was only apparent in rendering with arnold and might be translation-related and a normals issue, but that's also not it.

Mayas Viewport actually reveals the problem. The geometry is corrupt (in Maya, not in the cache, not any any other application): 

Here are three frames from a playblast. This is with double-sided lighting on (so it's not a backface problem), so the leaves appear correct on the first frame, and corrupt on the last (dark backside). The middle frame actually reveals the triangles (weirdly) flipping (the whole mesh is triangulated from the start), as you can see the tips of the leaves suddenly shows a triangular hole.

Is this a known issue? Workarounds? Since the alembic cache works perfectly fine in Houdini (also no "stuck" geometry before first frame of action) it not the cache itself. We're currently searching for a workaround, but I'm honestly pretty close to just moving the whole shot over to Houdini. Sorry, we tried Maya. 

Hope someone from Autodesk can chime in on the issue.

Maya 2018.6, Arnold 3.3.0, current Speedtree version, Windows 10 & macOS 10.13.X on different machines. 

[lennart.oberscheidt]

As a follow up: We've found a work-around. Which doesn't mean the issue is less annyoing. Wrangling all the alembics through houdini and exporting alembics from houdini again, the new caches come into maya intact. However we still have to unlock normals and soften/harden on those caches which obviously slows working with them down to a stand-still to not have the leaves flickering. We're going to export to .ass Standins from there as I really don't want to switch software mid-shot and the rest of the shot is heavily leaning on Maya assets but yeah… effective way to triple the time it takes getting the trees into maya and rendering 😉 

I double checked and the geometry from the original alembics comes in corrupted in maya, reads fine and exports fine in Houdini. Now, there's certainly the topic to discuss whether its Speedtree fault or Mayas fault. Since Houdini seems to have no trouble reading the caches whatsoever (and is, of course, 5x faster doing so anyway) I'm still very much convinced it's a maya specific bug or limitation that I hope Autodesk and Speedtree stick their head together figuring out why. All in all I'd assume Speedtree is doing something perfectly ok with their caches per Alembic spec and Maya is just not handling that case well…or er, at all.  Of course, we still have the "stuck" geometry problem in Maya since it doesn't like shapes with zero faces, but I guess I'll figure out how to cleanly handle the first frame of action in Houdini and getting working caches into maya to not have to animate shape visibility in maya on top of everything else. 

All in all: This shouldn't happen. Still would like to hear from someone having experienced the same issue or from Autodesk on what's going on here and whether this is on their bug-tracking radar.

I'd gladly supply the erroring cache(s), working cache(s), all of the render outputs, a neat Nuke Script with all our Testrenderings detailing the issue and playblasts and whatever else you'd want.

Thanks

Lennart