Particle modifier plugin type
-
I've been experimenting with the new particle system in R2024.4. What plugin type are modifiers for the new system? I've tried OBJECT_PARTICLEMODIFIER and OBJECT_MODIFIER but neither seem to work. Is it a new type not exposed in the API yet, or do they use Execute() to perform their function, or receive a specific message type as effectors do?
Steve
-
I think there is no access.
However, if you look at a group, you can see it is a point object. if you do CSTO on a group, you see that oyui get a polygon object with points. That has a bunch of channel vertex maps, and vertex color maps tags on it.
Float vertex maps are then for values, like lifetime.
Color Vertex maps are for anything requiring a vector such as angularvelocity.not sure if these are just constructed when you hit csto, or if they are virtually present on a group(not tested)
the polygon object points, are the positions.
These maps can perhaps be used to interpret particles, but I don't see any way to create or change anything, or create any kind of modifiers specifically for them. it is a blank sheet. Let me know if you find anything useful
best
Paul -
Hi this is correct, new 2024.4 particles being GPU based does not support OBJECT_PARTICLEMODIFIER.
You can read data from the ParticleGroupObject since they are backed in a PointObject but it is not possible to persistently write data back to the particle system. If you want to feed data back into the particle system, you should generate meshes or splines which can be used as emitter geometry for the particle system.If you want to see an example about how to read information, please look at the python example particle_group_object_2024_4.py.
Cheers,
Maxime. -
Thanks guys, that's useful information. However, I don't understand this:
@m_adam said in Particle modifier plugin type:
it is not possible to persistently write data back to the particle system
But for example, isn't the color mapper modifier doing exactly that? It changes the particle colour...so is it correct that it is writing the new colour data into the particles? There are also the functions GetParticleColorsR() for reading colours, and GetParticleColorsW() - which is not explained in the SDK docs but looks like it returns writeable data.
I've seen the Python example about reading particle data and I'm puzzled as to why writing data back in is not possible.
Steve
-
Hey @spedler,
the new particles can run entirely on the GPU. Which is why everything that wants to interact with particle data must be able to also run on the GPU. Which is why the old particle modifier interface does nothing here.
It is true that
ParticleGroupObjecthas methods for writing particle data. But these are a bit misleading, as these write operations are volatile. TheParticleGroupObjectis just a mere echo of the data held on the GPU or in the backend when the sim runs on the CPU. It is overwritten for each simulation step with the "fresh" data, it just represents the current state of the particles for other entities to use. So, you could for example implement a plugin that shifts all particles by (100, 0, 0) units before rendering by using the write methods. But that shift will be lost when the simulation updates then again, and the shift would not have been fed back into the simulation.The primary purpose of
ParticleGroupObjectis for third parties to read out data to be fed into render engines and procedural tools. There are currently no plans to provide true write access to the new particle API. If we decide ever to do that, this would also mean that we have to expose other things first which are either not public or only semi-public as for example MMSL (Maxon Magic Shading Language).In the beta community we already had a discussion about the adjacent subject of if there will be scripting support for particles (current answer: no, for the same reason). If we will add deeper access primarily depends on how much requests we will see in this direction. So, if you are a developer and reading this and need deeper access, do not be shy to voice your opinion here. When there is enough feedback, we will give it an honest spin.
Cheers,
FerdinandPS: The Python example Maxime linked to is not too transferable to C++ (the Python type does a lot of things differently) but you can find some meta information there.
-
Hi @ferdinand,
Thank you for the explanation. That makes it very clear. From what you are saying, the particle data is initially loaded onto the GPU and then the GPU processes the simulation. The particle data is then only changed by the GPU during the sim, or by the modifiers provided, which are changing the data but I assume are using Maxon's proprietary tools to do so.
That's a very different process to X-Particles, for which I wrote the majority of the modifiers. There, the particle data load is very heavy but it's all exposed and writeable. Here, the data load is small but can't be changed. The small amount of particle data is actually an advantage because it keeps to a minimum the data which cannot be changed by the user (if that makes sense).
Cheers,
Steve -
Hey @spedler,
only the simulation team can speak to the exact details here, but my guess for why it is how it is, is the pesky cpu-gpu upload penalty. If you would upload pre sampled data, or even worse sample on the CPU, this would really slow down any GPU advantage you have. I doubt that this is any different for the GPU part of Xparticles.
One could think about plugin access for CPU-sims but most users are likely never going to use that if they can avoid it. The simulation device is set in the simulation scene and by default GPU.
The more realistic thing would be that we provide some compute shader like access. I could go here into the details of the new particles and the challenges of providing such compute shader access to them but that would be the famous "counting chickens before they hatch". Let's first see how many users and which user type (scripting technical artist vs. C++ development professional) wants a deeper API access for particles.
Cheers,
Ferdinand
