Everything nodes

Progress on collision task give the Div some love

2 Likes

The particle nodes in master are starting to deliver real results.
https://developer.blender.org/rBf359672c3589c5c474abe1de78fcf39dd59e3532
https://developer.blender.org/rB74fcb4d4c2f3c72747119a672c7e322f6f910478
https://developer.blender.org/rB0ae2a1d12affc382d9fef8aff0703bea891fa0fb

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.

13 Likes

Quick Particles operator

https://developer.blender.org/rB1e999c7bdb63576fd66815c1770d096d165b8281

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.

9 Likes

Initial events support

https://developer.blender.org/rB38e65331a8345054874e81668772dc8c66ad1a1e

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.

11 Likes
5 Likes

Time node support

https://developer.blender.org/rB3b9e16a4f7b8deca23ba8d2a02ef9182eb9d6bb4

As I mentioned last week, the possibilities are starting to multiply. You can now make the particles do some interesting effects now.

6 Likes

A couple tests with the new particle nodes. Still very limited, but a lot of fun already :slight_smile:

For those interested, I also made a video explaining the basic steps for getting some particles moving:

22 Likes

More event types are coming, the groundwork…
https://developer.blender.org/rB7cd2c1fd2e7a4c82dd5569cf0ee0155c3cca9101

This will soon mean age-based events among other things, nothing visible to the user in this commit.

7 Likes

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.

1 Like

New node types; Age Reached (event type), Kill particle, Random float.
https://developer.blender.org/rB396d0b5cd0bcd9dd3dfa8d9006ee9f6f91c7196d

Jaques gives us an example by showing an aerosol can (another thing which can’t be done easily with the old system)

9 Likes

You can now instance objects on those nice looking node-based particle effects (like the one that writes the word ‘Blender’ in cursive).
https://developer.blender.org/rBf130cd116904a130e5ca9ae5dc86039a738016ab

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.

6 Likes

You can actually render it, seems to work fine in Cycles and EEVEE

1 Like

I’ve find this extremely concerning. But let’s hope for the best.

1 Like

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.

2 Likes

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.

1 Like

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.

1 Like

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.

3 Likes

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:

3 Likes

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… :smiley:

3 Likes