AFAIK Jacques is now building the final version in the master branch, and it shouldn’t be too long before we get some particles moving in the daily 2.9 builds. The “functions” branch hasn’t seen much activity lately, as the main focus has been to get the system working in the master branch 
5 Likes
yep that’s a must, unless it can auto downscale point count during playback (if not cached)
Started playing around with the functions branch last night, it’s pretty unintuitive at the moment, I think because the shift a menu is missing a lot of the available nodes, and also the shift +a menu’s aren’t categorized in a way that gives an idea of what the nodes contained within are suited to.
Is there any reasonably up to date information anywhere to help me get a better understanding of workflow and what each node does? Hoping to release a series of videos before the first release.
1 Like
The functions branch is probably not the thing to make videos about if I understand things right. Work has begun on getting things moved into master.
1 Like
thanks, any links to documentation so I can get a good understanding of it prior to it being added?
typically documentation follows after so while I haven’t checked I don’t expect anything near final documentation to exist yet.
2 Likes
Thank you Nizar for your answer. In the meantime, I went a little deeper into the system. I tested the storage of presets in AN by going, as you explained, to Save Startup FIle. However, I’m not sure how practical that is. Because that way the whole scene is saved as well as the UI from the blender. I think it’s much better when you open the program to have a clean empty project If you could only partially save a certain panel in the blender, it would make more sense.
Second, I think node systems in Blenders should be attached to an object or collection. When you copy that object then you would have the whole system copied. Currently, since they are independent of each other, you have to connect objects to the nodes every time you copy the system.
Or objects would have to be created within the nod system. With the possibility to be packaged in a new node, and an easy way to promote the most important parameters. A little better than the groups currently doing in the shader editor.
Check how this is solved with Xpresso C4D or in Houdini, Substance Desinger, Nuke etc. The system must be able to be packed together with all the elements, such as objects in the scene, in order to be functional.
People are attracted to the blender because of the extremely fast workflow, if building a node system is more complicated than in Houdini, if people can’t share projects with each other easily, then the whole purpose of having such a system is pointless.
I haven’t seen it posted anywhere yet, and until I can figure out how to work more with the actual output this is all the info I have:
Particle Nodes AKA Simulations is now in the Daily Build of 2.90 as of last week. To enable it take a couple steps:
-
Enable Developer/Experimental settings:
In user preferences → Interface → Developer Extras
-
In the newly visible Experimental panel, click “Use New Particle System”
-
Shift-A in 3d viewer to add a “Point Cloud” object, and set another window to a “Simulations Editor” window
And then add a “Simulation” modifier to the point cloud and the rest should be relatively similar to the functions branch version. Although I haven’t had much luck with getting all of the functionality that should get people started
4 Likes
There is no functionality yet, it’s just so developers can get to it easier.
2 Likes
Hey @jacqueslucke regarding the particle caching, now that you will be looking into storing particles information in point cache, have you considered using the PRT file format for write/load caches?
It’s open, license compatible with Blender (Apache 2.0) , widely used in the 3d industry in general for particles, highly performant and efficient in storage.
Here is the link to the library:
2 Likes
Right now, we are just trying to fit it into the point cache structure without breaking the other simulation types. However, we plan to make this a bit more generic, so that we could potentially also support the PRT file format. Have a look at the comments in D7979 for some more details.
7 Likes
Great, thanks
No please, use USD or Alembic for storing particle caches. PRT isnt a widely adopted format like USD or Alembic.
They both already support deduplication and all the data types for point information you want.
I beg to disagree.
PRT is a very widely used particle file format, used in many many productions and for interoperability and modification capabilities, main format of Krakatoa and available for many softwares like Houdini, Thinking Particles and others.
Besides USD and Alembic will be supported no doubt at all, I’m speaking about the specific particle cache format with custom channels and interoperability capabilities.
1 Like
Good standards live and die by adoption and community support, PRT has neither.
PRT’s github havent been updated in 5 years, and no DCC have native support for it.
USD and Alembic have a much wider adoption and momentum, thus making it more future proof.
One of the main reasons for USD being the future is to avoid intermediate formats, so temporarily/internally storing particle caches as yet another format would duplicate data and effort.
I would advice you to get familiar with USD and its benefits, which also includes custom channels (or attributes if you will), just like Alembic. And MUCH MUCH more.
Last week i had to export particles in PRT format from Houdini just because max doesn’t handle alembic well, had to install a plug-in to do it, so no, houdini doesn’t have native support for it.
i would say that having the option to do it is important, beside having custom attributs export & import with alembic & USD.
I have not said that it was Houdini native format, I just said that is available for many softwares, Houdini amongst them, plugin or not is widely used.
You used it because Alembic particles are not as widely supported, I’m not even sure if Alembic particles can support as many channels as PRT.
You are right, and that’s one of the beauty parts of PRT file format, is stable in time and widely supported, and filled with required features for particles.
Not being native to any DCC does not mean anything, I’m talking about it’s availability for VFX usage, and it can be used in many apps, and the best thing is that it’s specifically designed for particles and particle handling, USD is great, but in the same way as Alembic, particles are not as widely supported.
With that said, I don’t understand why you want to exclude it, it’s just a library and import/export option more that will give Blender more interoperability capabilities, also it’s much more space efficient, try to export particles to Alembic and PRT and compare the size of the files, you can use STORM for that for example.
Also another thing is that I’m talking about using a specialized particle format, you could store geometry in OpenVDB too, but you prefer to use Alembic (obviously), also particles can be stored in OpenVDB, but once again, the target and capabilities are different, this is one more option for specialized situations, very well production proven, and probably way more efficient than USD/Alembic or OpenVDB for particles.
There are many benefits on supporting PRT, but again, i’m not saying particles should not be supported in Alembic or USD
2 Likes
Particles and point data are first class citizens of USD and Alembic, with arbitrary number of attributes. Look at Houdini for reference implementation. They are in active development and supported by the majority of large pipelines and softwares. Better focus on the future.
PRT not seeing an update during the last 5 years (and the houdini plugin havent been updated in 3) means its a dead end .Sorry to say.
For the Blender developers to focus on these formats is a no brainer as improving ABC/USD workflows will have benefits far beyond artists just doing particle work. Just like OpenVDB will become the volume cache format for blender ABC/USD should be the geometry cache format, at least externally.
Im sure PRT is great, and some users would like import/export functionality which i dont mind, but the larger picture paints fleeting benefits for PRT or any custom format over established and well supported industry standards.
While mentioning OpenVDB as a volume cache standard, did you know that it also natively supports points?
https://www.openvdb.org/documentation/doxygen/points.html
The Mantaflow cache in the latest master already uses this to store the fluid particles.
I am aware of OpenVDB’s point support. But our pipe is based on VDB for volumes and Alembic (and soon USD) for anything geometry based. I wouldn’t mind it as the point cache format for Blender as its in active development and under ASWF’s wing. Its also a future proof format.
However, there’s a massive push towards USD for anything geometry related at the moment across the industry and that should align well with blenders future development.
Blender has a super bright future, especially now since it started to implements existing well supported and adopted standards. (OpenVDB,OpenEXR,OpenColorIO, and talks about OpenTimelineIO)