Progress on collision task give the Div some love
The particle nodes in master are starting to deliver real results.
You can already play with this in current buildbot builds, but since it is experimental (ie. you need to enable it specifically in the preferences), there is no documentation on how to get things set up so you get visuals. Apparently there is a Point Cloud object you need to add and a modifier you need to add as well, but actually getting something remains elusive to me.
Quick Particles operator
There was also an apparent issue that prevented the particles from drawing in the last buildbot build, tonight’s build should work better.
EDIT: The node particles work in the current build, the hilarious part is that even though the current functionality is very bare bones (with most nodes being mockups and thereby non-functional), it can already do a few things that the old particles simply could not do without Python and/or animation drivers.
For starters, it follows the modern design of using an emission rate rather than emitting a finite number of particles over a set number of frames. With the nodes already, you can do things like control the emission rate with the coordinates of another object, or make the particles fly toward another object automatically (at least initially). The fact you couldn’t do either of those easily with the old particles tells a lot about the lacks we had to deal with if you only needed the basics.
Initial events support
Nodes that use the
events socket in the output node are starting to work (particle birth event, time step event, and a couple of other nodes). The video shows you can do things like modify the velocity of all particles mid-flight.
Time node support
As I mentioned last week, the possibilities are starting to multiply. You can now make the particles do some interesting effects now.
A couple tests with the new particle nodes. Still very limited, but a lot of fun already
For those interested, I also made a video explaining the basic steps for getting some particles moving:
More event types are coming, the groundwork…
This will soon mean age-based events among other things, nothing visible to the user in this commit.
The ‘Which questions we still need to answer’ section seems like questions you’d ask if you hadn’t been paying attention to the work Jacques Lucke had been doing for the last year and all of his copious writings on the subject.
I hope Everything Nodes won’t suffer from the too many chefs syndrome or the project become limited because of expediency.
New node types; Age Reached (event type), Kill particle, Random float.
Jaques gives us an example by showing an aerosol can (another thing which can’t be done easily with the old system)
You can now instance objects on those nice looking node-based particle effects (like the one that writes the word ‘Blender’ in cursive).
I’m not entirely sure if this means you can use Cycles to create visual results yet, but at the least it is a big step to doing so.
You can actually render it, seems to work fine in Cycles and EEVEE
I’ve find this extremely concerning. But let’s hope for the best.
For programmers, those sort of questions are quite naturale. When you are working on a project, you start to dive in deep and quite often, you aren’t seeing whether you are still on track and whether what you are doing makes sense to reach the target.
That’s why it is important to take a step back from time to time and to reevaluate whether the current path is the best one. This includes several factors, like making sure it is consistent with other similar parts of the software. It is also central to have certain use cases in mind and to constantly making sure those can be achieved in a reasonable manner.
When you are working in a team, it can be very useful to take more people on board who are up to date with what you are doing. This allows you do discuss decisions or options with them, but they may also help you to figure out when you might to off on a tangent.
From my point of view, there is nothing concerning, but mostly open communication.
I hope you’re right. I found the level of those questions a bit off given everything that has been written about Everything Nodes on the development site.
I assumed a design document would exist especially for something as core as Everything Nodes where everyone knows what’s being worked towards.
I would’ve expected these questions to have been answered before a line of code had been written and not after a year and more of development.
This is how I feel as well. But so far, the system looks pretty solid for me. Can’t wait for particles rigid body though.
I can see why you find those questions off, but in practise it is in my opinion critical to reevaluate them on a regular basis.
I don’t know exactly how they approached it. To me, it looks similar to situations I have seen quite often, where someone implements a prototype and afterwards it is discussed in a larger group. In my experience, it is often useful to allow the person who creates the prototype to just do what s/he thinks is the way to go. This gives a proper discussion basis. Even further along the development, it is not unusual to ask those basic questions again.
The development is never straight forward and even if there is a design document, it has to be continuously adjusted. On the way you are learning a lot of new things you didn’t think of before, be it on the technical side or regarding the user experience. Those have to be consider on the way.
Edit: Just to make it very clear again, I was not involved in the process and don’t know how they approached it. This is a description of a common scenario how I am encountering them on a regular basis.
This is also how I feel. In reality, many questions and concept ideas just reveal themselves when you start to implement a prototype. Just starting on a blanc paper and coming up with a concept will often not lead to anything productive. Iterating many times through programming and design is the most productive approach imo.
it’s basically Waterfall vs Agile software production - Agile being the more modern and proven approach:
Let’s not forget Jacques coded a python based particle system as a prototype, also coded up the Functions Branch which was effectively a second prototype and now this is the 3rd system which is being worked up for release.
I understand there should be way points for checking all developers are singing from the same hymn sheet but the future questions looked a little on the late side to be of much use. To ask if there still needs to be the product is so trivial it need not be asked. It concerned me because this is the sort of question that gets asked when the bean counters want to push something out the door for expediency rather than wait for the full vision to be realised.
I’m confident that Jacques knows where the project is going and so too Brecht but not necessarily everyone at Blender HQ.
Presumably they used the Agile development philosophy to create that Graphic?
It was deployed without verification so here’s some feedback, Desing should be Design…