Open PavelBlend opened 4 years ago
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.
Emitter
generates particles just once, and Source
continuously 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
Emitter
generates particles just once, andSource
continuously 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
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.)
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.