The meeting covers the pipeline & I/O module in a broader sense, including some topics hosted in other modules (e.g. some I/O python add-ons, or overrides and .blend file I/O from the Core module).
Bastien has been doing some fixes related to the interactions between the USD I/O code and Blender core module (crashes due to threading issues, in both building of the export depsgraph, and usage of reporting APIs).
Matt will likely work on the world material conversion (between Blender shader and USD dome light).
I saw the targets about point clouds in 4.1, but I have a question, in the targets the import of arbitrary attributes is something separated, is that the case?
At least I understood it this way, just want to give a heads up about this, a point cloud without attributes is basically a gimmick, we already have that in Alembic and it’s practically useless because we barely can work with it, the workaround that people has been using is baking a second alembic with the attributes baked into the position vector, it at the very least doubles the required space and disk access, it’s non efficient at all.
My current workaround in USD is to copy a vertex per point, but this is also inefficient, it takes much more space in disk and it is way slower in writing/reading the USD file.
So just wanted to confirm that point clouds implementation is tied to arbitrary attributes import implementation
Thanks!
EDIT: An example about the kind of optimization this can be, a USD with poitn cloud with some attributes gets 25Gb, the same USD with the sme attributes, but having to do the vertex workaround gets 50Gb… double the space in disk… imagine with bit simulations of hundreds of Gb…
@JuanGea how you bake vertex attributes like motion blur in position vector? Are you using another software for this? which software?
Same problem here to use foam/mist alembic particles simulations with motion blur in blender.
@wilBr afaik we still have a problem with exporting mantaflow or particle simulations from Blender to ABC or USD, so right now there is not much to do, unless something corrects me here.
In general what we do is to bring in impossible simulations in Blender, like 100 million particles to simulate sand, we use USD to import it, but we have to replace the points in the simulation with vertices, which is… bad to say the least, for performand and disk space.
What you can try for what you want is to do a particle instance modifier over a single vertex, then you can export that as ABC or USD and reimport it, and about he attributes, I’m afraid that there is no way to extract them, but once you have the USD or the ABC exported you can use Geo Nodes to calculate the velocity with the name “velocity”, and that will make Cycles to understand it.
(The trick is to load the cache twice and use the second cache with a frame less, that gives you information enough to calculate the velocity vector and store it.)
Sorry for the bit of off topic, normally I would have redirected this question to a user support forum, but in this case I think it’s a good example of the loopholes we have to take and why point clouds and attributes are so important, and of course being able to export Blender particles and Mantaflow Particles (which are Blender particles too in the end) it’s also very important, but we need full USD support for that
