Leaderboard

They will notice when they want to UV the result and none of the loops are conducive to that. Even with ZRM there is no guarantee material breaks will be anything close to what you need, and then you have to deal with what might be described as a 'hurricane of piss' trying to transfer usable UVs to that mesh, which is possible but only with time and wizardry. People are quick to dismiss SDS and doing it properly when it's all about the client speed, but don't forget that what the client sees is only half the battle. A lot of them are going to want subdividable meshes, usable UVs, helpful selection tags, and edge flows that make sense, whether they know it or not, because it'll be you they come back to when they want changes. And when they do, you'll end up having to redo all the textures and edge flow stuff even if the VB underneath it all is fully parametric. And let's not forget that the more often you do SDS modelling, and get used to solving, patching, tweaking and expanding such that it becomes second nature, then we start to achieve speeds that really aren't that far behind bodging it with a voxels or splines. For your own benefit you would also be practicing skills that not many people have any more, which makes you valuable for the people who still need it, which is more than you think ! 😉 CBR

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 🤣

Ok, so the broad strokes... 1. I would start with the front flat part, and start with a few low poly discs to get round the corners nice and evenly... 2. Next step would be to join those, remove the bits we don't want, get a gloriously even perimeter, and patch the inside, thusly... Of course this shape could be described with less polygons than that, but we need to think about the density needed elsewhere, and the subsequent connection of these so far disparate patches, so I have gone a little higher than is strictly necessary out of context. 3. Next we can leave that patch, and start the handle, which needs slightly more polygon density on the right hand side, like so, or thereabouts... as this is isolated topology there is no need to match segmentation left and right sides, but left side should match the patch to the left, and right side should be a line down the centre of every 'hole'. We do not need more than that now because we will be using staged subdivision on all patches when we need it, later, to put the holes in. 4. Last in the patching department would be to make the neck, which we will do with auto-projection and poly pen in order to give us the edge flow we want whilst still maintaining a perfectly cylindrical front half that the neck demands. Eventually this will become symmetrized, so we are still only building 1 half initially. Your reprojection form can be just a cylinder (no caps), under SDS with the base mesh tweaked to follow the subtle curvature there. Here is mine before I start laying down the loops we'll actually use... ..and here is the patch I need, created over the top of that with poly pen... that needs quite a specific edge flow, which is probably the below, or something quite like it... That patch has used projection, so will be rounded correctly, but most importantly, whilst still having all the right edge flow and segmentation to join to the adjacent patches it will later connect to. 5. Now we can start moving those patches around in 3D space to get the depths right before we begin expanding, and joining them, and adding depth and detail to handle and neck etc. Hopefully that is enough to push you off in the right direction, and I have other work to do today, but will pop back later / tomorrow to add more if you need it... CBR

ScreenRecorderProject124.mp4

Try changing the coordinate system