利用者・トーク:Lucarood/Modifier Nodes/Proposal

Kiki's Notes and Questions

Language

• Can this be the first part of the system that uses a bit more C++11 / 14?
  • It would be nice to use things like standard containers, reinterpret_cast, const_expr, shared_ptr, maybe std::function, etc.
    • A lot of issues that come from pointer trickery in the Blender codebase would become compile-time errors, which would speed up additions the system significantly in my opinion.
  • Doesn't mean we have to change the current methods in Blender for doing things like polymorphism (currently a lot of recasting, provided the initial definition places the base struct in the starting memory location), but would simplify so much code for so many other things.
  • Would be great to use std::map<uint32_t, ModifierNode> to store the structs holding Modifier Node functionality so that new nodes can be added at runtime and so that the current system of having everything be hardcoded can once and for all be done away with.
    • Nodes would be added through a register() function, possibly of a class that wraps access to the std::map.
      • I know we could also use the BLI_ghash stuff, but using C++ for this would be cleaner and easier to understand for new developers.
    • If using C++11/14, we should be able to write register() functions for nodes of different base classes without having to worry that incorrect function signatures are being registered and causing segfaults at runtime.
    • I propose that node definitions also have readfile() and writefile() function pointers so that the main Blender file writing doesn't need to be touched after the initial addition.
    • Also important: We'd need to be able to register RNA for new node classes at runtime. (I know there's a system for this, but I don't know how that works currently.)
  • One thing about using the Blender-style structs with function pointers over classes is that it would make it much easier in the long term to work in LLVM support for trees and sub-trees, as functions and their data would already be separated.

Mesh ID sockets

• How do you intend to implement this? The hashing seems interesting, but what about a simpler method of adding per-prim group information, a la Houdini? If MVert / MEdge / MPolygon had a simple uint_32t group index or pointer and those groups were named like vertex weight groups, then you could set an initial mesh ID (possibly a UUID based on datapath) that flows through if necessary as well as create new ones using nodes within the graph.
  • For example, it would simplify extrusions over every second face, or a push deformer along every third vertex's normal. The Group node could be set to faces, and you could provide an expression or even a node-based input test based on face index.

No object modification

• Don't see why not-- object-level graphs could just be limited to only modifying transform data by limiting outputs. Graphs attached to data structures (Mesh, Curve, Lattice, etc.) could provide additional available nodes. A lot of the same nodes could be used across all types by providing a poll() function not unlike what Operators do in Python (and perhaps this is how some of the Compositing stuff works; I haven't looked too closely).
• That being said, I like the minimum viable product test of making it work only for Meshes or Particles initially.
• Graph return type could be linked to what the graph is plugged into-- Mesh graphs have to return Mesh or Points; Object graphs have to return Objects.
  • With Meshes, if Points only are returned and the point count is the same you can infer deformation only, not generation.
• Types that make sense to share would be shared, like you specified
  • Particle Modifiers would be able to share Mesh modifier nodes that work with grouping, setting, sampling, etc.
  • Cloth Sim nodes would be a superset of the Particle Modifier and Mesh nodes. I'd personally like to see the Particle Nodes become advanced / encompassing enough to perform the same calculations as the current cloth sim, but then be something the user can dive into to modify at a low level or to more easily mix multiple simulation caches.

Modifier Tree can be referenced by many objects

• Need to make sure that at reference time and at plug set times, input objects don't cause cycles and that the error messages indicate that "object X cannot be used because it is the input of user X of this tree"
• Can Modifier Trees reference other Modifier Trees? This would allow for sub-programs, where the sub-tree has a node that exposes only inputs and outputs like current Group nodes, but also allows for a lot more customizability as you wouldn't be limited to specific outputs for the sub-programs.

Mesh Wrapper

• Is the intent to come up with something like DerivedMesh, since that's on the way out now in 2.8? Would you want to base work on BMesh, or support BMesh as needed through nodes like AnimationNodes does?
  • Personally I find BMesh a lot slower than DerivedMesh for simple tasks so I'd like the option.

Node Tree References

Mesh Nodes

• 3ds Max 2016 Max Creation Graph (MCG) [1]
• 3DS Max 2016 MCG Introduction Tutorials [2]

Particle Nodes

Cinema 4D Thinking Particles

• How to use Thinking Particles in Cinema 4D in Six Parts [3]
• Particle Generation using Thinking Particles [4]
• Thinking Particles Tutorial 01 - The Basics [5]

Insydium XParticles for Cinema 4D - [6]

• Soft Bodies with X Particles [7]
• Growing Trees with X Particles [8]
• X-Particles Avoidance in Cinema 4D [9]
• X-particles Cinema 4D Tutorial - Dynamics, Attractors, And Color Changing Particles [10]