taichi-dev
List of nodes
I decided to write a list of nodes that can be implemented. If you have questions or suggestions, then write your opinion. I decided to write this list now so that it would not come as a surprise to the architecture of the physical engine. It’s better to understand in advance what needs to be realized than to rebuild the architecture in the future.
Converter Nodes
Math
An analogue of the standard Math node. Two numbers can be input
(int/float), and the result is the result of sums, differences,
products ...
Vector Math
An analog of the Math node, but for vectors.
Color Mix
For mixing two colors. Blend Modes: MIX, MULTIPLY, LIGHTEN, ADD...
Boolean Math
Logic math. Has two bool inputs. Modes: and, or, not...
Separate RGB
Decomposition of color into components (red, green, blue).
Separate HSV
Decomposition of color into components (hue, saturation, value).
Combine RGB
Combine the individual components of R, G, and B in color.
Combine HSV
Combine the individual components of H, S, and V in color.
Color Ramp
The standard blender node. Need to change color. To create gradients,
increase contrast, etc.
Texture Nodes
Gradient
Noise
Voronoi
Structure Nodes
Make List
Merge Lists
Time Nodes
Time Info
Has Params: scene start time, end time, current time
Frame Info
Has Params: scene start frame, end frame, current frame
Time Speed Info
Has Params: FPS, Time Factor (Simulation slowdown or acceleration rate)
Simulation Objects Nodes
Emitter
Collider
Outflow
Hub
Simulation
World
params: use_world_scaling, world_size (meters), close_boundary,
boundary_friction
Input Nodes
Integer
Float
Integer Vector
Float Vector
Boolean
Boolean Vector
Color RGB
Color RGBA
Transforms
Has inputs: bpy_object, has outputs: location, rotation, scale, dimensions...
Effects Nodes
Viscosity
Surface Tension
Vorticity
Elasticity
Source Nodes
Mesh Object
Curve Object
Force Nodes
Gravity
Force
Wind
Vortex
Noise
Curve
Generator Nodes
Mesh Generator
Particle System Converter
Output Nodes
Disk Cache
The list in general looks very nice to me. A few quick questions before I come up with more:
-
Do Blender nodes support multiple inputs? something like
-
Do we have to implement the Texture nodes on our own? That sounds a lot of work and maybe we should consider borrowing some nodes from other Blender node graph systems.
-
In my understanding
Emittergenerates particles just once, andSourcecontinuously generates particles, is that correct?
- Do Blender nodes support multiple inputs? something like
The blender does not support many inputs. Only one.
- Do we have to implement the Texture nodes on our own? That sounds a lot of work and maybe we should consider borrowing some nodes from other Blender node graph systems.
I haven't figured it out yet. But I have never seen a standard node in any addon.
- In my understanding
Emittergenerates particles just once, andSourcecontinuously generates particles, is that correct?
I do not know all the intricacies of physical simulators. Not sure how things should be.
I do not know all the intricacies of physical simulators. Not sure how things should be.
I think we can simply use a "source" node, and add an "outflow" option
- Outflow = False means the emitter will create a bunch of particles at a certain time
- Outflow = True means the emitter will continuously generate particles
To be honest I don't have too much knowledge of the UI of physical simulators either - Maybe we can just deliver an experimental version and gather some feedbacks from the users.
- Do we have to implement the Texture nodes on our own? That sounds a lot of work and maybe we should consider borrowing some nodes from other Blender node graph systems.
I searched a bit for information. It seems that you cannot create and duplicate nodes from the standard part of the blender. For example, the ColorRamp node:
https://blender.stackexchange.com/questions/19289/are-ui-color-ramps-possible-through-python
I looked into the three node-systems you posted, and it indeed seems to me that they are all recreating their own nodes over and over again. E.g. https://github.com/hsab/GrowthNodes/tree/master/umog_addon/nodes/integer
I also checked the Blender source code, and it seems to me that the Texture nodes are implemented in C++, e.g. https://github.com/sobotka/blender/blob/master/intern/cycles/render/nodes.cpp#L1008
It seems to me that the Blender components each have an independent node system.
One more possibility to reduce the burden on our side: can we somehow import a texture from another node system? For example, is there a "texturing" node graph system that can generate a procedural texture, and we can simply take the output as a texture map for simulation, e.g. for varying particle stiffness/viscosity?
You can create a texture in bpy.data.textures. Then you can find out the value of the texture using the evaluate function. But I do not know what to do with the ColorRamp node.
I see. That sounds like a good way to offload the 2D/3D textures/volumes. For the ColorRamp node, if that's relatively simple to implement, maybe we can implement it on our own. (Evaluating a color per particle is not too much computation and python/numpy should be able to handle it well, if I understand everything correctly.)
