Hi,
I exported a test alembic mesh from Cinema 4D (made with X-Particles).
The velocity data is stored as an animated vertex colour map just called “Velocity”.
I tried to use this information in the “Velocity Attributes” field of the MeshSequenceCache without success (even though i could use the vertex colour in the material with a gradient to make it visible).
Is there some way to utilise these informations for motion blur?
Here is a sample scene:
https://my.hidrive.com/lnk/iBgBFdwd
Thanks
Vector pass is the proper data input for motion blur. You can render any scene and use Vector Blur Node in compositor. Also importing an alembic file to compositing software can generate vector data, like Nuke with Scanline Render. Yet I did a test and it’s not a very good one, maybe is a problem with the mesh.
Hi Lucas!
Thanks, but that’s not really whatI meant. The goal is to render the motion blur with Cycles with the given vertex velocity information stored in the vertex colour map and not as a post process. In Redshift for example I can use the (monochromatic) “Velocity_X”, “Velocity_X”," Velocity_Z" vertex maps to drive the deformation motion blur of a mesh. As the MeshSequenceCache in Blender only lets me input one attribute i thought the combined colour vertex map (“Velocity”) could be used for that.
So the question probably would be: Can Cycles use colour vertex maps for mesh deformation motion blur somehow?
Cycles won’t consider other softwares velocity information or vertex colour map to anything inside Blender, it will generate data from motion. Velocity parameters is a input for your simulation and will output vector data, if enabled. Motion blur is a result from camera aperture. They’re both related but not the same. Vector data is x,y,z direction for each pixel to create proper motion blur direction. Redshit is just converting it, but also have a vector pass output for compositing.
No. Cycles absolutely can read velocity data from alembic caches.
Same alembic cache. Left has had its velocity scaled in Houdini prior to export. Right has had the velocity attribute disabled.
No. Lens aperture has nothing to do with Motion blur. Shutter speed and framerate determine motion blur.
His file is avaiable. Would you give a try?
Right, used wrong words.
Your scene is instantly crashing the latest master (3.0) but I can import the abc and something is weird / wrong. If I add a Geometry Node modifier to inspect the attributes on the mesh it looks like this
As you can see there are 4 different vertex color layers, each with RGBA channels.
Usually velocity vectors are living on points, not on face corners and they’re a vector3 (XYZ or RGB… not vector4 like RGBA). And then all 3 components of the velocity vectors should be in a single vector3, not in 3 or 4.
Something went wrong. Blender can actually render motion blur coming from a velocity attribute fine, even when there’s no actual movement on the points. Just try this scene here to see what I mean.
motion_vectors.zip (116.1 KB)
This icosphere is blurred although there is no animation or movement on it. Just a velocity attribute.
This is what motion vectors should look like
P.S.: I just noticed that in Blender “points” are called “vertices” and “vertices” are called “face corners”. This is strange because in my world vertices are points that are part of a poly (i.e. face corners), whereas points are just erm… points. A single vertex that is not part of anything “higher” like a poly is a point IMHO. I wonder how the naming will be as soon as particles make their way into GN 
Thanks for your effort. So the culprit seems to be how X-Particles/C4D stores or exports their velocity data. Probably it is not meant to be used outside their own realm 
I wouldn’t think so. My assumption is that you’re trying to export velocity in the wrong way by using vertex colors and there may just be a velocity export checkbox in your export settings. It’s likely that you just need to ensure the velocity data is stored as a vector3, though I’m not familiar with X-Particles so I don’t know how much control you have over attributes.
Houdini will recognize a point vector attribute called ‘v’ on export and assign it to a ‘.velocities’ attribute. I think the exporter itself is able to calculate a velocity attribute as well.
Hi, I am currently developing a new system to handle Alembic attributes, and allow for reading any arbitrary attributes.
I am going to look at your file, but to me the culprit is only the data type (it should be a vector3). Indeed, Blender will read any Color3 (RGB) attribute as a vertex color map, even if the data is on the points (we just replicate the data for each face corner corresponding to the point). Note that we automatically set the alpha values to 1 if we have a RGB attributes, so inspecting it in the spreadsheet may give the idea that it was exported as RGBA.
In my new system, there is going to be a way to remap attributes directly when reading them, so it will be easier to deal with data from external software. (If anyone wishes to try it, there is already a patch for it: https://developer.blender.org/D11591, although I think I am going to make builds from it, so I can get user feedback.)
Sadly that’s the only way X-Particles outputs velocity data, even Cycles 4D has to rely on this.
http://manual.cycles4d.net/html/objecttag.htm
The Alembic export is handled bei C4D and it just passes the data through.
