Everything nodes

The branch is not ready for testing. So while you can provide inspiration/input for the general direction, nothing is defined as working yet.

No, I am not in contact with Jacques, and I haven’t considered joining back any sorts of Blender development (at least not for free, you know, “Kévin has code if you have coins”).

The thing is that I really want to move away from CG (even in my spare time), and do something else with my life. For the past few months, I was working on a completely different project, and I came back to my CG software only because I am in the process of merging all of my software into a single repository (for easier code sharing and such). So I merged all the branches of the software in the master branch, regardless of whether or not they were finished, which also prompted me to quickly wrap up the dependency graph and basic simulation code, which lead me to talk a bit about it here, to share some knowledge. Anyway, I was just wrapping up some work before finally moving away.

However, I am in the process of writing all of my observations and experiments in an article that I will publish perhaps on my (freshly created and rather empty) blog or on the Blender wiki. The notes for the article are rather huge already. It will go over some node-based software designs and abstractions (like Blender’s compositor vs Nuke), pros and cons of various graph “processing” algorithms, maintainability, object model, etc… It may take me quite a while to write though, and will probably be my last “contribution”.

1 Like

Oh great ! :slight_smile: I get the feeling. (I’m trying to shift to working in the forests, get away from computers)
Have a nice change of pace !

Hadrien

Jacques just posted a new particle nodes test and it’s looking really cool!

16 Likes

Has anyone tried building this branch, on linux in particular? I have to do as in this post, and also comment out these lines (105-107) in source/blender/blenlib/BLI_task.hpp:

  for (LocalData data : data.thread_locals.values()) {
    free_thread_local(data);
  }

to silence this error:

Summary
In file included from /home/thomas/blender-func-git/blender/source/blender/simulations/bparticles/simulate.cpp:5:0:
/home/thomas/blender-func-git/blender/source/blender/blenlib/BLI_task.hpp: In instantiation of ‘void BLI::Task::parallel_array_elements(BLI::ArrayRef<T>, ProcessElement, CreateThreadLocal, FreeThreadLocal, bool) [with T = BParticles::ParticlesBlock*; ProcessElement = BParticles::simulate_blocks_for_time_span(BParticles::ParticleAllocators&, BLI::ArrayRef<BParticles::ParticlesBlock*>, BParticles::StepDescription&, BParticles::TimeSpan)::<lambda(BParticles::ParticlesBlock*, BParticles::ThreadLocalData*)>; CreateThreadLocal = BParticles::simulate_blocks_for_time_span(BParticles::ParticleAllocators&, BLI::ArrayRef<BParticles::ParticlesBlock*>, BParticles::StepDescription&, BParticles::TimeSpan)::<lambda()>; FreeThreadLocal = BParticles::simulate_blocks_for_time_span(BParticles::ParticleAllocators&, BLI::ArrayRef<BParticles::ParticlesBlock*>, BParticles::StepDescription&, BParticles::TimeSpan)::<lambda(BParticles::ThreadLocalData*)>]’:
/home/thomas/blender-func-git/blender/source/blender/simulations/bparticles/simulate.cpp:467:20:   required from here
/home/thomas/blender-func-git/blender/source/blender/blenlib/BLI_task.hpp:105:3: error: request for member ‘thread_locals’ in ‘data’, which is of pointer type ‘LocalData {aka BParticles::ThreadLocalData*}’ (maybe you meant to use ‘->’ ?)
   for (LocalData data : data.thread_locals.values()) {
   ^
/home/thomas/blender-func-git/blender/source/blender/blenlib/BLI_task.hpp: In instantiation of ‘void BLI::Task::parallel_array_elements(BLI::ArrayRef<T>, ProcessElement, CreateThreadLocal, FreeThreadLocal, bool) [with T = BParticles::ParticlesBlock*; ProcessElement = BParticles::simulate_blocks_from_birth_to_current_time(BParticles::ParticleAllocators&, BLI::ArrayRef<BParticles::ParticlesBlock*>, BParticles::StepDescription&, float)::<lambda(BParticles::ParticlesBlock*, BParticles::ThreadLocalData*)>; CreateThreadLocal = BParticles::simulate_blocks_from_birth_to_current_time(BParticles::ParticleAllocators&, BLI::ArrayRef<BParticles::ParticlesBlock*>, BParticles::StepDescription&, float)::<lambda()>; FreeThreadLocal = BParticles::simulate_blocks_from_birth_to_current_time(BParticles::ParticleAllocators&, BLI::ArrayRef<BParticles::ParticlesBlock*>, BParticles::StepDescription&, float)::<lambda(BParticles::ThreadLocalData*)>]’:
/home/thomas/blender-func-git/blender/source/blender/simulations/bparticles/simulate.cpp:507:20:   required from here
/home/thomas/blender-func-git/blender/source/blender/blenlib/BLI_task.hpp:105:3: error: request for member ‘thread_locals’ in ‘data’, which is of pointer type ‘LocalData {aka BParticles::ThreadLocalData*}’ (maybe you meant to use ‘->’ ?)

but it builds now so that’s great. Thing is, I can’t find any of these particles-specific nodes:

so have I done something wrong, am I looking in the wrong place, or are they just not there yet (eg. turned off by some setting)?

(I’ve posted this here (rather than, say, on devtalk) because I don’t want to bother the developers over it - after all, it is work in progress. Really, I don’t want anyone to go out of there way to solve this for me, I’m just asking on the off-chance anyone else has run into this and if/how they solved it. Thanks)

1 Like

For the nodes, use the shortcut ctrl+A.

1 Like

At long last, Blender’s particle functionality breaks out of its somewhat basic feature set and now looks to actually have power behind it.

What’s also nice is how we’re now seeing visible fruit from the Everything Nodes project. I hope to see this followed by node-based modifiers (bevel, hair, curve, ect…).

1 Like

This brings back memories from when Softimage XSI finally announced ICE (which was originally just a new particle system code-named “Moondust” in the beginning). Oh boy, it was so much more than just a particle system. :slight_smile:

1 Like

well, I’ll be. Thank you!

1 Like

Everything Nodes UX

it seems there is now a task for UI/UX for the project, to me it looks a good approch as it provides both high & low level for end-users, most Artists want to spend their time on their art not on figuring out programming nodes and node trees, so i’ll leave it to more experienced users since i only saw old Softimage ICE demos a while back, so those who are more familiar with other node based programs can chip-in without hopefully losing the “Artistic side”.

4 Likes

Remember that the procedural textures are all defined as functions in 3D, while image textures are only defined in 2D. So 2D mappings don’t really apply in any natural way to procedural textures.

Until Cycles gets the ability to deform texture coordinates with the geometry as it gets moved by armatures and other techniques (which can be done using spherical harmonics), then being able to easily wrap procedurals onto 2D coordinates like UV’s is very much needed for many cases.

The swimming effect is desired for some forms of animation, but you can’t pose a character and keep its texturing intact if you use procedurals with true 3D coordinates.

Spherical harmonics, did you say?

Incorrect. 90% or more of my own procedural textures and setups are for 2D use (some are even 1D), even if I use the 3D generators in them. I.e. I use voronoi to create seamless radial brush patterns, or a couple of brick textures (they are 2D btw, not 3D) to create some pretty decent 2D floor tiles or wooden board patterns. I also often mix these setup with 2D images, but I’d like to easily (without custom node groups) to manipulate these additional coordinate systems.

Even if I never create characters or things that bend, the resulting mappings could be baked onto UV where their layout is not critical for pattern generation.

Nope. I am correct. Try plugging different coordinates into Blender’s procedural textures, and you will see that they are in fact functions of all 3 dimensions.

Note that the cycles gsoc has implemented 1D, 2D and 4D voronoi. Hopefully this will be in 2.81.

3 Likes

Did you try brick? Still, you’re talking about the generator nodes. Procedural texturing is more than hooking up coordinates (2D or 3D) to a generator and pass it through a color ramp. Sometimes (often) you need to manipulate coordinates prior to using the generators.

Here an example of pyramidial mapping. I’m projecting a texture image, but it could be an animated 2D voronoi for fake caustics or whatever:

I’m sure this could be simplified.

I thaught that everything node will be like Houdini, we have a blank space where to put our object, camera, lights etc and then we jump in an object for example, and that everything we do will reflect in a nodal way.
And shouldn’t material & textures nodes be part of everything nodes ?

For those using the OSL stack for its custom shading though (which is a lot slower for complex scenes than SVM). We need it as a hardcoded feature since performance is everything for a lot of people.

1 Like

Not sure what you mean exactly. Houdini also has separate node tree types for different kinds of data.

Cycles materials are already driven by nodes, and yes, many improvements to the node system will also, directly or indirectly, improve shader nodes.

1 Like