Leaderboard

@pfistar To update, try turning off Material Preview

Damn politics ...

Agree 100% The main use for volume builder I've ever found is in modeling for 3d printing or other fabrication where uv's and edge loops arent required.

HappyPolygon An exceptional and well-written post that takes us from the historical evolution scene nodes through the future development of capsules. For those who work for Maxon that still visit Core4D, please chime in. We would love to get your take on this post. Agree? Disagree? Don't be shy. The philosophical issues still being debated are interesting as you would think that they would have been part of the "concept commit" phase of development. What do you want to achieve in the end? I do agree with your summary as it does indicate that not a lot of thought was put into where Maxon wanted to go with non-destructive node based, procedural modeling. Most new product development initiatives start with a solid, well defined, end-state specifications and those specifications help form agreement around the "concept commit" phase of a project --- a simple alignment from all stakeholders within the company (sales, development, marketing, finance, etc) whether or not to proceed forward. Do they all "buy-in" to the end-state vision of this initiative? I don't think this was done because remember that scene nodes were originally touted as a "technical" demo with a few examples that show how scene nodes replicate existing functionality but enable massive viewport performance gains. Was viewport performance the target benefit to be achieved or the only benefit that could be shown from having to adopt a more complex modeling paradigm to what is currently available? Not sure. Now, capsules is a much better system to be sure but the philosophical questions that are still open indicates that it was not the originally intended end-state. For example: Why is Turing -compete (or even Turing Equivalent) still an open issue? You would think something as fundamental as how the software processes data would be part of the original specifications. Why are simple things like icons and pallets still being discussed? C4D's secret sauce is OM and the UI. The best software tools are those where the first thing people think about is how the user is going to want to use the software. So, the fact that icons and pallets is still an open issue is rather alarming given Maxon's track record of exceptional UI development. How can you develop a procedural modeling system without considering how to manage selection sets? Overall, it feels like the project's development decided on approaching it using an Agile scrum team philosophy: don't think it through to 100% completion before starting, just get something out there and then iterate fast to improve it. Unfortunately, fast iterations are not possible when what you are development touches every part of a massive and constantly growing (thank you!) and evolving program. My sympathies to the development team. The fact that you were able to get to capsules is amazing. Unfortunately, I fear you may have lost the user in the process. Dave

Since R23 there was a discussion about how Scene Nodes were supposed to actually help things out. The discussion was mainly philosophical because from the existential point of view (why are Scene Nodes even needed in the first place) there wasn't much backing up of the idea. It seemed that the main reason Scene Nodes were developed was the constant expressed opinion of the public wanting a node-based modeling system like Houdini, just because Houdini is king in CG production (Blender is also known for it's own system but Geometry Nodes were released some months after Scene Nodes so I don't think Blender was a factor). The new (Neutron) project had pitfalls for the following reasons, making the result look like a failure : The public demanding a node-based system had a false perception of what that would look like and how it would work. Mainly because most of them didn't even know how Houdini works, they just knew it was "better". Also many of them (users) weren't familiar with XPresso or Material nodes. So when the system was finally delivered the learning curve seemed overwhelming. Considering the poor documentation made things worse. Many users already knew that a node-based modeling/animation system's biggest advantages are the procedural and parametric characteristics. What they failed to acknowledge was that C4D already had the capability of procedural and parametric setups due to the powerful Object Manager, something that other DCCs are trying to replicate. Considering the above MAXON added the Capsule system. A bridge between the Object Manager and Scene Nodes. Now we know why Scene Nodes are needed and these are the following: Not all C4D operations are procedural or parametric. These operations are positioned mainly in Tools, Mesh and Spline menus. These are operations that are not stackable in the Object Manager. Best examples are the Inset, Extrude, Bevel and Bridge operations. Scene Nodes provide a better space (2D) than the Object Manager (linear) to accommodate for complex groups of operations AND procedural/parametric operations that are not available in the OM. Scene Nodes offer capabilities that XPresso couldn't like UV/color management during modeling and some attribute manipulation mostly with instances that was impossible before. A better graph structure. XPresso had a less restrictive brunching structure which made it prone to logic conflicts when same attributes were manipulated simultaneously by many operations. Scene nodes are less prone to these kind of conflicts due to their "one-way" structure. Personally I have seen very few occurrences of cyclic structures (infinite loop) in Scene Nodes and when that happens it immediately gets detected. The ability to construct new parametric primitives. The ability to construct new tools without diving deep in the C4D Python API. Procedural modelling. Points that are yet to be resolved: Visual aid on selections. Boolean Operations. A better category system to provide better housing for the expanding number of nodes. (sub-categories for example or a tier-based metadata tag filter to better serve users with different experience or type of work (newbies want to see only capsules, techies want the low-level structure nodes) Access to specific Capsules from any custom pallet (I think it has been solved but not sure) More high-level nodes for complex operations (the "bad" thing is that MAXON tries to construct high-level nodes from low-level nodes and not just hard-code new nodes, this is time consuming because it leads to technical difficulties) Nodes are harder to update. I'm talking about high-level nodes like Dual-mesh. It's not the same thing as adding new features to an existing coded feature. Although nodes are scalable, adding new features/mechanics in an existing structure can be much trickier compared to coding. Faster loading times when the node pool is summoned. Make scene nodes a high-level workspace for procedural and generative modeling by adding mechanics to accommodate specific needs. For example Adaptive Grid Space for asset placement - used to create procedural cities, buildings etc. Terrain modeling tools - diffusion, erosion, terrace and many more modifiers are easier to work with in a 2D node space rather in OM. Agent system - for crowd animation, traffic animation or simulating flocks of birds, schools of fish etc. Some philosophical issues still remain open: If Capsules are used like deformers in the OM, why still use them as such and not hard-code them later as regular Deformers adding more functionality to them like having Dual Mesh affect certain regions of geometry using Fields ? Should all features be mirrored as nodes in the node pool ? For example instead of dropping a Cloner in the Scene Node space from the Object Manager, just drop it from the node pool, because you don't want to have the cloner or any other hierarchy chain of native C4D elements in the OM, you just want the result to manifest from the Scene Nodes. Should Selection Strings be adopted to the rest of the app or evolve into a better system with all the benefits from Selection Strings and the usual Selection form ? Should custom icons be made for most nodes in the Geometry Modifiers category ? (what's the point of having the same icon if the icon is not used for identification) Should there be a ready-made Palette with deformer-like capsules and primitive-like capsules for users to select from without having to open Scene-Nodes ? (helps new users to know all available geometry manipulation options making features look system-agnostic (I call systems all node systems and the python interfaces)) Is Scene Nodes Turing-complete ? This levels Neutron with programming. If the system is Turing-complete that means that anything that can be programmed can also be translated to nodes. This is very important because it can save you from chasing your own tail. If I know that something is possible with Python and that Scene Nodes is Turing-complete then I can make the attempt to implement it using Scene-Nodes. This tread has forked more than any other thread 🤣

1. Create your gradient in C4D Shader and then plug it into RS Texture in the Remap tab with the parameters you need 2. You can use the UV Projection node

Some cracking : ) 26_Floor_crack(MG).c4d