Hi there, I’m having a difficult time exporting vertex colors from Houdini to notch via alembic (I’m working with a mesh that changes topology and vertex color every frame).
I tried various workaround and all possible settings in the import window (by the way what “tangent uv channel” option stands for?).
The same thing happens If I create and export vertex color in cinema4d.
I work with cinema r21/r20, houdini17/18 and notch0.9.23.125
Has anyone succeeded in importing a vertex color animated alembic?
I attach a screenshot of a simple test (left:notch, right: how it should be).
Here it’s the alembic file: https://drive.google.com/file/d/1xAIUhfKsli3GYXuk2Qu2kRBwcF4pejyV/view?usp=sharing
I made some progress about avoiding glitching colours by promoting colour attribute from point to vertex and clamping negative and >1 values before exporting alembic.
Unfortunately there’s no way to have notch updating vertex colour every frame. It kind of reads colour from a single frame and I suppose it passes to the other frame according to vertex number. Unfortunately I need to import a meshed fluid simulation from houdini with changing topology. Can anyone from Notch VFX confirm that there’s no way to achieve something like this right now?
Here it is the updated alembic:
In the meanwhile I’m trying a workaround by baking vertex colour to texture, as it seems to me that notch can read animated uv properly from my alembic.
Unfortunately I can’t figure out how to properly synchronise alembic geometry playback with image-sequence.
I exported from houdini a one hundred frames alembic at 25fps, made of a flat plane (on the left) on which I mapped an image sequence texture and a mesh (on the right) that changes on every frame according to the frame number. As you can see during the playback (after export I slowed down the video to 1fps) the image sequence plays correctly but the geometry/alembic skips some frames.
I tried changing frame-rate, locking frame-rate, re-timing speed but with no luck.
It seems a minor issue loosing some frame every now and then and I would be totally fine if I could manage to have both geometry and image sequence skip the same frames…
If you wanna have a look here you can download the project with assets:
By the way that’s how I worked around the issue so far. The result is less than ideal both on performance and precision but it’s something.
I baked colors to texture in Houdini (one texture for each frame). To give consistency to uv layout even during skipping frames I used a cubic map which by the way creates a lot of artifacts on this complex mesh. To smooth them out I applied a frame feedback effect to the image-sequence texture in Notch (you can see it on the ground plane). Most of the color details are lost but at least it’s something usable waiting for better alembic implementation.
cheers
Thanks for such a detailed post!
We’re investigating this stuff, and will get back to you once we have an idea of whats going on.
My pleasure!
Thank you for investigating 
Ready for any further alembic betatesting
Hi Ryan,
is there any news on the topic of alembic integration of animated vertex colour and/or texture syncing?
Please I don’t want to switch back to touchdesigner… 
Im also having hard time with it. In general there are a lot of problems with current alembic implementation.
1. There is no way to transfer vertex/point color with alembic doesent matter if its particles or geo. Doesent matter if topology is the same or changing each frame. Its or not working at all or working incorrect.
2. Alembic of Notch also dont like empty frames. If u have pre-roll in ur animated alembic scene or objects are disappearing for some time then appearing again, notch will start animation from the moment when object is exist or will stop it on last frame before disappearing and will hold this condition till object will appear again.
3. If you have Alembic cache with emitted or dying particles, at the moment when amount of points will change, Notch will distort everything. I guess because particles Id changed. So its just impossible to bring that kind of particles cache to Notch. Only some fluid sims where you have the same amount of particles in each frame will work.(upd. fixed in rc162)
4. You can load alembic seq from Houdini over Import Resource-Particles-Realflow Data but when you drooping it in to the scene it will make ‘Particle Root Cache’ node which I havent found in doc. Well… It will crash Notch after two sec anyway. But for some reason you cant load at all alembic seq from Realflow with same method. A bit strange isnt it?
5. Its not about alembic but I already started to talk about RealFlow so maybe this is good moment to mention it. Anyway… You can import realflow .bin from Realflow it self but you cant import .bin if you exported it with RF Connection Plugin from Houdini or C4D. Even if you will load this cache(from Houdini or C4d) with Binary Loader in RF and will re-export it directly from RF again, it will crash Notch on importing.
6. And this crazy inverted Z story. Hey developers! Could you at least not to invert normals or I dont know what happening with geo when you flipping it on import.(upd. I guess it fixed in rc162), (upd2. not really)
7. In strange way it can use separated geometry in alembic as groups for materials, but you cant do the same for mesh emitter.
8. There is no any way to colorize alembic particles cache in Notch with reasonable ramp. Only solid or random or projected colors. Because… check paragraph 1 . Notch just dont see any point attributes. So all AGE or VEL or ID or Cd data just a getting lost somewhere in Notch.
I hope all this and other alembic problems(which I been to lazy to mention) will be solved one day.
Here you can find some videos of my experiments with Alembic data:
https://t.me/boringspace/74 (Hi-res alembic geo with AO texture from Substances Painter + Notch cloner and post FX)
https://t.me/boringspace/75 (Flip simulation from Houdini. I tried two ways. As particle cache and as baked instances)
https://t.me/boringspace/76 (Backed mixamo animation with cloners and some full body + ground collision particle emitting in Notch)
1 Like
So here is some screenshots from Houdini and Notch. As you can see new rc162 Z/X/FBX filliping doing nothing with Alembic. I tried different options. In alembic I have geometry. This is not particles on my screens, this is a lot of polygons copied on points in Houdini and exported as alembic.
Houdini viewport
Notch (new flipping doesn’t work)
Point colors are also oblivious working not correctly
Just comparing screens:
I thought maybe Hue is in offset but no… this is not related to Hue
Hi Mark,
thanks for the very detailed walkthrough of your importing alembic experimentations. Importing particles from Houdini would have been my next step but I have to admit that your report is quite discouraging…
As I see from your notes there’s no real major improvement in 162 update, which is sad.
I made some quick 162 tests as well and I can confirm that there’s no change in the vertex color attribute reading from alembic.
As regards my previous workaround I’m seeing a slight - very slight - improvement in syncing alembic with image sequence/video textures. If you lock timeline to alembic framerate, lock alembic to framerate, lock texture to timecode and add -2 frame offset (no idea why) to texture in video loader node, it kind of works even if the first amount of frames still remain messed up.
Unfortunately, if I switch to raytrace or to a more performance challenging setup the syncing gets lost after the very first loop, so the improvement is limited to very specific scenarios.
I’m in learning licencese so I guess I cannot make any kind of claims, still maybe someone from Notch can address if this kind of implementation (correct vertex colour and general vertex attribute as well) is on the list of something we can hopefully see in a near future, cause this would be (for my very specific usual setup) a real reason to stick to this software and consider switching to a pro licence when this stuff will be implemented.
P.S.: By the way, it’s fair to say a lot of stuff in 162 are amazing! 
Same here. Guys doing amazing job and I can understand their road map strategy of preferred improvements . But all my projects are based on heavy alembics and instances. Unfortunately I cant make it work as I want, so I cant use it in full force in Notch yet. If I cant use it I have no reason to switch on Base yet. I hope developers will take in to account one day how important alembic workflow for vfx pipeline and specially for people with postproduction background.
Just checked if this problem with empty frames(paragraph 2 in my previous list) is still exists in new rc162.
FIXED and working now!
Thanks for all the discussion and repro data on this thread. Alembic is not without it’s issues (in terms of documentation and samples, and lack of rigidity in the file format, with each exporter doing things slightly differently) - we’re generally reliant on gathering test data from various packages and checking our implementation against them.
There are some issues in 923 with vertex colour import from alembic.
- Colour channels blue and red are swapped.
- Colour data could sometimes be interpreted as face index varying when it was actually vertex varying.
Both of these have been fixed and will be out in a future maintenance release.
Other issues:
- Vertex colour animation is not currently supported at all, sorry. UVs can be animated and should work properly. We will try to add this for 924.
- Point cache data in the Alembic format doesn’t actually carry colour as standard - it’s considered an arbitrary data field, so it’s up to the export package how it’s handled. We’ve added support for 924.
2 Likes
