I’m interested in getting a headstart on some of the development challenges Blender faces in relation to particles and v2.8.
What exactly does the development look like right now? I haven’t really been able to find any proposals or any useful information about the planned development for 2.8 particles.
There are some relatively simple ideas that I’ve discussed with some other people that shouldn’t take a lot of headache to implement. I’d love to see Particle Nodes and such, just wondering if it’s already possible to start developing them given the current state of particle code, or if it needs a complete rewrite.
i think Lukas Toenne is the one who works on particles and physics for blender
try to reach him at irc, his name is @lukas_t
this was his proposal, including particles
I think you have to get into the mailing list, most roadmaps are now 1 year old. but as far as I know it’s well on its way. I remember reading the code for nodes has been rewritten or at least upgraded but is waiting for the 2.8 release.
So get on the mailing list to get latest updates, I think Lukas is involved with particles and nodes! so keep track of his progress.
code.blender.org is pretty slow on updates but really in-depth and explanatory.
but it sounds amazing, more node based, cached, particle physics! I think I read somewhere way back that it would be possible to spawn particles that can use bullet physics which would greatly improve current basic collision models for particles.
I’ve been dabbling with blueprints in unreal and in my experience it’s the best node based system I’ve tried so far. Nodes are named relevant to the code based, if you know coding you will be very familiar.
it feels like you can program almost anything with the node system, create bools, int, floats, your own functions. listeners/callbacks it’s pretty much how I would like blenders node logic system to evolve into.
A new particle system in the long run is ready, but if you remove the old system right now, the hair system will also be deleted. At the moment, Toenne tries to create a new hair system, separated from the particles.
For a while at least, the concept of hair and particles being separate has been the goal.
This is one major reason why Jahka (the particles developer some years back) stopped all work on the particle code (the amount of work required would be more or less the same as simply rewriting everything).
Now we have Lukas working on the hair system via what is now the Strand Nodes branch (which the initial goal is simply the higher quality display of hair).
A 2.8 branch was created some time ago, but it is basically master without point cache, and without particles. As far as I know, no one is really working on some (big) 2.8 target except maybe the viewport developers (including me, though I haven’t done viewport stuff in a while), let alone working on a brand new particle system.
The node system that Lukas is currently working on isn’t accepted yet, it’s just him having fun so to speak. He has quite a few different branches where he tries new things, including the strand_nodes noted above by Ace Dragon, but nothing concrete yet. I did do a bit of work in the object_nodes branch, but again it was some time ago and things have changed. Lukas and I also briefly exchanged back then some ideas on how node-based simulations might work (I was working on my own fluid solver). Anyway, although I can see the potential for this node system, it might never make it in master, you never know, so let’s avoid speculating or getting excited too quickly :).
Concerning OP, I wouldn’t bother with the current particles code and I would start from scratch, possibly with a different paradigm. However simple your ideas might be, with the current particles code, it might become a nightmare fairly quickly (especially when it comes to multi-threading).
Personally, I would like to see particles (or points in general), strands and volumes as object types, at the same level as meshes and curves, separate from any simulator. Then, for example, you would have some particle system modifier (or nodes) that will take the points object and do the simulation on that object directly, instead of having the particles as secondary data created by the simulator itself from another object (the current paradigm). The workflow would be similar as creating cloths (model then simulate). Obviously you would need tools to generate the points (the simulator can still generate them, as well as secondary points). I have a branch where I tried implementing a volume object (OpenVDB to the rescue), but I haven’t tried implementing this point object, or anything like that in Blender yet (though I’m trying in my own software (shameful advertisement ;))).
Amazing soft @KWD! OpenVDB is something I cannot live without.
I agree about particles being same level as meshes. In houdini you’re dealing with simple points with some extra attributes(age, velocity etc). It’s also nice as you can import data from other software and further manipulate it.
I understand that building a feature rich nodal particle system is very time consuming. However with strong foundation such as creating a SCRIPTING node (like extremely fast VEX in Houdini) you’d enable community to exploit it and probably collectively come up with one of the most diverse solution on the market just as they have with all the python tools. In short, it does not have to be elaborate huge system that never gets completed - empower users and focus on foundation.
Nice prog KWD It looks really like a good node based program. I also like the idea to have importers as nodes. Do you plan to release this program some day (open or closed?)or to implement it on Blender?
I don’t want to hijack this thread too much, but to briefly answer this (then we can move to PMs or so if need be):
it’s my personal software for research and development purposes, though some ideas or code may be implemented in Blender (the current viewport volume rendering code in Blender actually comes from that software)
the code is already open source (GPL) and available on my github page
it’s a bit of a pain to compile at the moment (no CMake support, it’s Linux only, using C++14, Qt, a plugin architecture, and some personal libraries also available through my github page, the Linux only parts can be ported to other platforms of course, but I don’t have those platforms :P)
the OpenVDB object and nodes that you see in the video are available through plugins (which need to be compiled separately of course)
I shall keep developing this software until I don’t feel like it anymore. Right now I’m rewriting the UI code, and then I’ll probably move on to start writing an event based physics system (been thinking about it for a while now).
In my opinion, the particle code doesn’t need much work. It’s already there. It works just fine, albeit the learning curve is extremely high. I would like to simplify that learning curve by creating a system that extends the current particle code without much modification, and does so via it’s own Node Tree (Particle Nodes).
Particles need a few basic changes.
New Primitive Object: Point Cloud
The point cloud is an object that has single point, just an origin. From there, users assign a “primitive shell” to contain the particles. This shell can be any of the current primitives/empties that are currently implemented. User chooses to emit from face, vertex, volume, and then can choose random/jittered, etc.
Emission calculation changes:
Users can control particle emission in one of two ways. “Standard”, which is start, end, count, and lifetime settings; or “Simple” which is Particle Count, Rate (of emission) and Lifetime.
Particles can receive actions
Particles should be able to receive an action. If I animate a piece of popcorn with a shape key so that it pops from a kernel, a particle should be able to “inherit” this action via instantiation but only “UPON BIRTH”. When the popcorn particle is born, the action starts.
These three changes would completely change the paradigm of particles within Blender. It would make it easier for users to understand what particles are, how they are emitted, and let users instantiate objects with various actions into a particle system. These are things that every particle system has, but Blender does not. They need immediate attention and implementation, or else we might as well just rewrite particles all together.
I’m probably completely wrong. However, I opened up Blender’s code and took a look around it looks like all the base code for this to work is all there.
Jacques Lucke was able to at least access Particle Data in Animation Nodes and allow the User to use that data and modify it slightly. Is it possible to take this further?
This is exactly what I was talking about. I honestly feel that the code we currently have, while broken in many places, can be manipulated and extended with Python to do what we want. I keep hearing X feature isn’t possible, etc. But I can’t believe that. Anything and everything is essentially achievable, especially since we already have working code to extend.
The only issue is that the codebase for the particles is pretty nasty for developers to work with (ie. tons of spaghetti which is prone to introducing bugs). That is why the goal is to completely replace it rather than try to extend it (in a way that ideally makes it node-based).
Lukas Tönne was working on just that for a long time, and from what I could gather the code was too much of a mess that it would be saner to just rewrite the whole particle system from scratch. Lukas even refused to work on particle code for a while because of this (still?)
Let´s hope that a 2.8 fundraiser allows Lukas to work on this full time, if he even wants to that is…
If 2.8 will have OpenGL 3.3/Vulcan, will Cycles render particles real-time in viewport shading mode ?
Is OpenGL 3.3/Vulcan sufficient to make this happen?
but really in-depth and explanatory.
It looks really like a good node based program. I also like the idea to have importers as nodes. Do you plan to release this program some day (open or closed?)or to implement it on Blender?