Thanks, I tried to use it but the last update is over 3 years old and for Houdini 16.
I couldn’t get it to work with 18.0 so far…
1 Like
Nice, but it looks like it’s Windows only?
Speaking with @EloiAndaluz we reached another conclusion about OpenVDB, while OpenVDB seems to be efficient, is not compatible with anything except Houdini it seems.
It’s a standard for volumetric caches and it’s supported for that in a wide variety of softwares, but it seems that the point cloud part is not accesible for those same softwares, and that’s because in fx/particles PRT is way more used than OpenVDB, and it’s robust and efficient, so it seems there is no real interest in supporting that part.
With “softwares” I’m referring to C4D, Maya and Max, Houdini seems to be the only that supports it.
I would like to get some confirmation about this, but Max for example is incapable of reading such part, in fact Max is the worst of all them I think because it can read OpenVDB with the Arnold loader, but it does not seems to support OpenVDB natively, at least yet.
But I was surprised to see that Maya and C4D can’t read that either, once again, I may be wrong.
So OpenVDB as interoperability format for point clouds does not seem to be the better choice.
With that said, I’ll repeat myself, I’m not against having a very good and proper OpenVDB, Alembic and USD point cloud caches in place, I’m all in favour of it, but I’m also in favour of supporting one of the most widely and robust file formats used for particles, which is PRT 
Thanks for the tests @SteffenD, it’s very interesting to see how well OpenVDB performs
2 Likes
At the end you need to ask yourself this question: For what will be this format? If its to be used within blender itself. At the end just use whatever feel the best format is, no matter what. But if the end goal is to be used within blender and to connect it with other apps, you should support some of the stablished formats on this other applications. For my experience even VDB particles seams to be a good candidate its not at all stablished anywhere else. In max we will not know even how to load it (not with max, not with any plugin available). PRT can be imported with prtloader (free), thinking particles, tyflow, pflow, fumefx reads data, vrayinstancer supports it, forestpack supports it, we can export prts from fluids, we have tools for scattering, manipulating data… theres an existing ecosistem created around it that makes it useful. With VDBs even could be a better format… we dont have anything of that right now, so difficult to implement it right away in to production.
2 Likes
I can’t speak about C4D because the last time I “used” it was like 15 years ago. But if it comes to Max and especially Maya I spent a lot of time as a (Houdini) freelancer exchanging files with both of them during the last 10 years.
If “Max and Maya support it then it’s an industry standard” is a measure, then we should also stop supporting Alembic because the Alembic support in both is only pretty basic. Polygon based geometry might be OK, but curves are special and if it comes to points Maya is a complete fail because it just doesn’t read them from Alembics. Attributes are also a difficult topic but they’re extremely important in Houdini and they’ll become extremely important if “Everything Nodes” evolves.
Autodesk has the habit of adding support for an industry standard format just to tick the checkbox in the release notes of a new release and after that just stops further development completely (because, hey we “support” Alembic so our job is done!). I had the same experience with MODO a while ago. As I said, I don’t know what C4D is doing.
Blender 2.90 itself is luckily already using OpenVDB points when caching out Mantaflow simulations. So, it already writes and reads a rock solid industry standard that some “big players” sadly still don’t support.
1 Like
I ask myself exactly this question. The format we’re talking about is only for Blender’s internal use as a cache. So it should be super fast, super light weight and should support all features the cache needs. Readability in other apps is not so important (because it can be converted to anything afterwards).
If we on the Blender side could invent a super efficient, super fast and super lightweight format for storing points with an arbitrary amount of attributes that would be awesome. We could always convert this to anything we want afterwards while working as fast and efficient as possible during simulation.
But IMHO we don’t have to reinvent the wheel because other very talented people have already done this, and I think the guys at Dreamworks (and the https://www.aswf.io/ ) know what they’re doing.
It’s already in Blender, everything is there ready for us to use it in an industry compatible way, so why not do it?!
And for the ones needing an output format (which has nothing to do with a caching format) it will be no problem at all to write an exporter that gives you PRT files, OBJ Sequences or whatever you need to make your Max, Maya or C4D happy AFTER the caching is done.
I’m not sure about PRT, never used it. I have used openVDB though, so I can’t really cast my vote. Something I can comment on though is this:
This is sometimes the case with Maya. Autodesk does some things well, but in others they are slacking pretty hard. I’m not entirely sure where things are going with these 2 formats, but I do know that if blender as an opportunity to “get ahead of the game” it should take it, and openVDB does seem like it might be that player. I don’t like to use Maya or Max as “baselines”, not everything they do is gold standard.
2 Likes
NOT AT ALL!!! OMG!!! NOT AT ALL!!!
I will NEVER say that.
But I think we are speaking of different things, you have to think that using something widely used is not just for caching things from inside Blender, or from moving things outside of blender, it’s to move things inside Blender from the outside.
With Houdini you have it solved, but so far is the only one.
Think of doing something with TyFlow, or with Storm, like a proper high quality granuylar simualtion, I can afford Storm (300€ perpetual), I won’t purchase a full Houdini license (5000€ + 2000€ /year).
Interoperability does not work only from Blender to another software, it works from another softwre towards Blender, and studios ask for this lately, because they cannot change the pipeline, and sometimes Blender si not enough (granular simulation is a good example), and yes, we can ask Adesk or any other dev to implement OpenVDB, and I’m already doing it with the Storm developer (not directly yet thought but I’m on it hahaha) but that does not mean that having prt as a particle cache format is bad.
As I said, this format is super simple, can be implemented in no time, why exclude it when it’s so widely used?
I’m not thinking in Autodesk (they don’t support PRT or OpenVDB point clouds) I’m thinking in collaborating with otehr artists or using other tools that won’t kill my pocket (and my studio on its way LOL) but at the same time will deliver a very good result.
So I think we are talking about two different things:
-
Default particle cache format for internal Blender use: I agree, probably OpenVDB is the best option based on your choices, mainly because we could be able to make use of the VDB toolset to modify them in addition, directly inside the nodes in Blender
-
Additional particle cache formats to give choice to the user and allow easy and good quality interoperability: Alembic/USD and PRT
Not exclusive and different objectives 
1 Like
I totally and 100% agree with you. Interoperability with other software and workflows is key.
Of course Blender should support PRT, Alembic, etc. formats for I/O. Even OBJ sequences are fine. I hope that “Everything Nodes” gives us im- and export nodes for as many formats as possible.
But the internal cache format should be as fast and optimized as possible, no matter if other software can understand it.
If some Blender developer has a bright idea and invents the best and most incompatible cache file format in the world, let’s use it. But at the moment OpenVDB looks like the best candidate to avoid reinventing the wheel.
I’ve been talking about the internal cache format all the time. 
1 Like
For that we agree too, if OpenVDB is faster and more efficient, we should use OpenVDB, also it will be able to centralize all the sim results, particles, meshes and volumes, which is very good
I’ve been talking about make interoperability easier and more efficient to get simes that are not possible in blender into blender
1 Like
I have a question regarding Array modifier / node. Currently Array modifier does not allow to work with objects “as instances” or Empty elements (and therefore with collection instances). Will this new node system solve this limitation? I mean, Array objects as instances instead of copies, and then be able to apply other effects on it like Wave or Cast.
Edit:
Well, I’m not sure if I should have asked the question here or in Functions thread. All this about nodes confuses me a bit.
This question may have been asked before, but I’m looking for a way to get the Particle Nodes on the Ma Version 2.90.0 Alpha Version. I have access to the Simulation Nodes, but nothing will ever emit anything. Is it working already, or is this simply for developers to implement further Nodes?
Best David
Probably this for now.
Cinema 4D introduced “Basic” OpenVDB support on R20, right now it is used for volume modeling.
“OpenVDB is fundamentally a way to store 3D pixels. Cinema 4D can load multiple grids from any .vdb file, and load animation via sequenced .vdb files. Release 20 does not yet offer native volume rendering but VDBs created in Cinema 4D can be exported in sequenced .vdb format for use in any application or render engine that supports OpenVDB.”
Here is a 1 minute video introduction:
This is correct.
In the current version in master, you cannot control the particles. However, you can see them already.
Right now, the general workflow is as follows:
- Activate new particle system in user preferences.
- Go to the Simulation Editor, add a new Simulation at the top and create a new Particle Simulation node. Name the particle simulation
My Particlesinside the node. - Add a point cloud object in the 3d viewport.
- Add a Simulation modifier to the point cloud object.
- Inside the modifier, select the previously created simulation and use
My Particlesas Data Path. - Go back to frame one and press play.
In the upcoming days and weeks I want to do the following (besides internal stuff):
- Support forces.
- Provide a basic emitter.
- Make events work.
22 Likes
Awesome, thanks!!! 
I just implemented initial support for forces. It’s very WIP, but at least you do have some control over the particles now.
https://developer.blender.org/rB21b20ae5ec1512b52f6c231863a278ccacb4835c
16 Likes
Great !! Keep going .
my next is connecting the Cross Product. (now, crash Blender with Cross Product )
2 Likes
I only implemented Add, Subtract, Multiply and Divide. Will add the other modes soon enough.
Thanks for testing the system in this basic state.
2 Likes