Leaderboard

On the scene nodes/capsules topic, the biggest problem I see is that they are being abused in the sense that people create these completely uninterpretable monstrosities out of them, not because there is a flaw in scene nodes themselves or because they are a very low level toolset, but rather, just as with the deficiency found in most programs written by professional programmers, people just don't understand the following simple concept: As something gets more complex, you need to add meaningful names, create levels of abstraction, componentize (with further meaningful naming of entire assemblies of sub-components), layer (to allow for viewing of a subset in isolation), and in the end present multiple "vantage points," containing various levels of details and subsets of objects, from which the entirety of a scene can be viewed. This is not an issue that was introduced with scene nodes, it existed with xpresso and modeling in general. But, as items that are more complex, dynamic, and low-level get added, the problem becomes greatly exacerbated. To use an illustrative analogy, no auto-mechanic open a car service manual to find a single diagram containing every nut, bolt, part, and assembly that makes up the car. They wouldn't be able to find a thing or even comprehend the image as a whole - it is just too complex to be taken in by a human being. Furthermore, illustrations that are present don't show every screw, regardless of length, diameter, type, or use, as just: screw, screw.1, screw.2, screw.3, screw.N, making any similarities and differences between their various characteristics completely undecipherable. Instead, illustrations of various systems of the automobile are divided by subsystem, and even then, there are various levels of detail shown to make the diagrams both comprehensible and cohesive (i.e., limited to the function/component being depicted). Even at the highest level of detail, perhaps showing individual screws, said screws are labeled with meaningful identifiers or group labels and perhaps even given a context in order to help convey the role they play as part of a greater whole. This is the very thing that most modelers who create large scene node graphs seem to completely lack. I see very few (if any at all!) counter-examples to this. It's hard enough to find scene files where people actually label objects properly and use layers, often skimping on these barest of necessities, and leaving things named as they were originally by Cinema 4D when their testing/hacking ultimately evolved into a final scene. Even with all of the "smarts" in its engine, Cinema 4D could not possibly know the semantic meaning and role of every particular piece of geometry or group of geometries and come up with a meaningful label to (re)name it. We wind up with scenes containing sheer stupidity like Cube, Cube.1, Cube.2, Cylinder, Cylinder.1, and when grouping at the very least is attempted, we have Null, Null.1, Null.2, etc. I am not referring to test scenes made by someone who just started to learn Cinema 4D and perhaps polygonal modeling in general. These are scenes made by professionals and educators, across the board. How in the world can one make sense of such a scene, even if referring to the very person that created the scene, some six months down the road? Is it that difficult to label things when they are created, or if uncertain due to experimentation, to go back once things settle and (re)label them with meaningful names more descriptive of their final roles? Is it that hard to assign layers to parts of a scene to allow it to easily be viewed in meaningful cross-sections, representing subsets of the whole, rather than having to view every little thing with every last detail, all of the time? I am not only addressing this at modelers, but, even more so, at training presenters/professionals on Maxon's own YouTube channels, the very people who should be imparting these concepts on the more novice viewers, but instead are making the very same mistakes mentioned above and teaching "all the wrong things," as perhaps an unintended side-effect, indirectly affirming or conveying that this is standard practice for modelers. Here is an example from the Maxon Training channel of the very thing I am talking about, at least with regard to the naming portion, screen captured from Quick Tip #48 (with a small amount of sharpening, because it was a bit blurry having originated from a YouTube video screenshot): Take a look at the Object Manager in the right third of the scene, above. How can one possibly hope to make heads or tails out of those names with regard to the function they serve or the role they play? There are at least three critical flaws here that I would like to describe in greater detail: 1. The names are generic and completely non-descriptive of the semantics of each operation. Even worse for the case of this particular scene is that names are repeated, even though said names are highly ordering dependent (with respect to operations above and below them) and therefore, the operations they perform be completely different, depending on where they appear in the list (i.e., ordering). 2. The list is flat (i.e., linear) and not hierarchical, which combined with the naming makes it completely impossible to ascertain which items, when combined as a logical group, perform a particular higher level task. 3. There was no attempt to modularize and/or componentize, to present the above in the Object Manager using higher level functionality that the user could then drill down into, piece-meal, in order to see how a particular task was accomplished in terms of its underlying lower level node operations, in isolation (think of soloing a small group, rather than viewing the entire scene as a whole). Naming is important, levels of detail are important, organization is important, modularization/componentization is important, layering subsets is important, reuse (of the same object via instances/cloner/etc.) is important, and many more similar topics should really be stressed, taught, and engrained on junior modelers from the get-go, and this advice is even more applicable to presentations made by professionals for purposes of education. Just my two cents...

Thank again CBR, excellent advice as always. I will experiment with your options. All the very best. Jacobite

I wouldn't worry about them too much - they don't have the numbers or the organisation any more 🙂 But I do agree it doesn't make much sense for continuity if the lighting suddenly shifts from shot to shot, though it might not be that noticeable if it only shifts slightly. Fake daylight is a 2 part system - Sunlight itself, which is a directional / point light and an ambient light 'dome' which is representing sky and light bounce - nothing else. Some people would use the Ambient light button in a standard light to do the latter, but we could also fall back to the old way of faking this to get more tweakable results by actually cloning omni lights to a massive hemisphere that entirely surrounds the scene. There is a 3rd option as well - keep the physical sky where it should be, but add a subtle area light up front / behind camera, to additionally illuminate the parts that you don't want in shadow. You can either imply that is offscreen natural light coming from generally behind the camera (and keep it low-level and not bright enough to usurp the sun, wherever that is ! ) or you can do this more blatantly if you try simulating ground-up feature-lighting like some of these things have at night. In that case presumably you would be adding a number of additional spotlights or small area lights but could keep the physical sky where it was. CBR

I did not miss his point, i only quoted and answered the part that wasn’t a personal opinion but an incorrect assumption. I can’t and won’t address any personal issues with the licensing offered by Maxon, so please do not expect me to go there.

You've missed his point and highlighted his reference to a bigger, side topic also being discussed in the post he referenced. His comment regarding C4D was: I am one of the disappointed customers that were hoping to see perpetual licenses still on sale, mainly because I wanted S26 features. As a hobbyist, with two children, I sometimes can't do anything in C4D for months, so the subscription model does not match my needs.

Cinema 4D and Maxon doesn’t offer any kind of cloud services though. Apart from initial installation and optional assets it is only the licensing that really needs an internet connection. The licensing only needs very small bandwidth and only occasionally.

I am one of the disappointed customers that were hoping to see perpetual licenses still on sale, mainly because I wanted S26 features. As a hobbyist, with two children, I sometimes can't do anything in C4D for months, so the subscription model does not match my needs. And I think it is right to expect SaaS to expand to more softwares, maybe even OS, there is no limit to human greed. But I don't believe that the cloud will be a long term solution, because everything going to the cloud would raise a lot of internet bandwidth issues in many places in the world. That would also require so much power to run more servers everywhere that the impact on climate change would be worse. And it is not a minor problem.

What about radial symmetry helpers. This is something that is needed so often! Rectangular (cubic?) symmetry is well and good, but many things that are modeled are cylindrical in nature and tooling for radial symmetry would be greatly appreciated. I am talking helpers well beyond just sticking things into a MoGraph Cloner or using a bunch of rotated MoGraph instances to help with this task.

I think scene nodes were a mistake. They should have focused on improving Xpresso (better UI, better UI Scaling, multi-thread, etc...) and bringing the scene nodes abilities to Xpresso. I'm very high skilled in Xpresso and I use nodes in other software constantly (Maya, Unreal, etc...) and I never bothered even checking the Scene Nodes. Why should I? If they can abandon Xpresso, why should I learn another node based scripting language from Maxon? Just so they can abandon it again some years down the road? Anyway, I'm really happy with C4D 2023 (sans the horrible colors). I think it's the best version since R20. But maybe this omission of Scene nodes means they are reconsidering their strategy. Maybe they will see the light and focus on improving Xpresso.

Don't think anyone has posted this here yet, so here is C4D Uber-meister Chris Schmidt showing us round the new goodies in rewardingly exhaustive detail as usual... CBR

I think this type of motion is relatively easy with XPresso.

As you already understood, displacement has been supported by C4D for a long time. You can find this funny turtle scene in the library browser. The vector displacement map is baked from the sculpt's high poly mesh. Cinema has all the tools to do this both in the sculpting tools and in the regular Bake Material tag. In my opinion, the names of some points clearly say that these are vectors. Honestly, vector displacement is not some kind of super breakthrough technology in and of itself. Combination with adaptive mesh subdivision technology is important. Then you will get a mesh with the maximum number of polygons near the camera where it is necessary for drawing details and the minimum where the surface has no details and is located farther from the camera - example Redshift, Cycles. The algorithm of the standard renderer subdivides the mesh even where there is no information about the details and does not take into account the distance from the camera, therefore it takes a very long time and takes up a huge amount of memory.

I'm a bit confused about what this topic is actually about. If we're comparing what each app is capable of outputting, then that is not necessarily dependent on whether it uses nodes or not. In fact, nodes are not even a requirement for an app to be procedural. Nodes just carry data, and serve some specific purpose. For me, the main advantage of using nodes is scene-readability. I used to create procedural stuff in Cinema 4D, and when I'd open the same scene two weeks later, it'd take me ages to decipher what it was that I had actually done. C4D, prior to Scene Nodes, offered no visualisation of how your data was flowing. In Houdini, regardless of how complex a structure I have made, all I need to do is go through the nodes, top-to-bottom, and in 5 minutes I know exactly what it was that I did. There are other things to be said about node-based workflows, and if we're going to compare nodes between apps, I think we need to compare the implementation of these nodes and how easy the workflow is. XPresso was hands down the worst node UX for me. It was shockingly bad in how it required you to interact with it. Houdini, on the other hand, has by far the best workflow for nodes I've ever used. The UX for it is sublime, just packed to the gills with endless little helpful usability features that make things easier for the user. I haven't tried Blender, but I'd be surprised if it wasn't much closer to Houdini than Xpresso in usability. I've read some not-so-good things about C4D's SN workflow though, so that isn't inspiring too much confidence right now.

As I've already mentioned here : Most of these can also be made natively in C4D without the use of a node system, for reasons I already analyzed. Having said that I will compare some Blender and Houdini scenes with C4D for C4D users that may not be too familiar with C4D or don't know how to reverse engineer a final image in terms of C4D tools. And I'm doing that only to debunk the "almighty Blender node system" for new C4D users. Of course some scenes are impossible with classic C4D tools and I'm going to note that, I'm not trying to glorify C4D, I just find that this thread might not do justice to the capabilities of some DCCs and get misunderstood by some readers leading them to overestimate the use of nodes. In my opinion anything related to Houdini is just going to be superior in terms of Nodes just because nodes is what Houdini is made of. It's like comparing a fish with a duck on how fast they can move only by their swimming capability. I hope Maxon doesn't interpret the node enthusiasm of users in the wrong way (as the preferred way of working and not considering practicality) and make everything node-dependent. OK here we go: 1) Cloner, Random Effector, Step Effector, Fields 2) Scattering Effect using Cloner, Fields using Vertex Maps, Push Apart Effector 3) XPresso for the springs (I guess this counts as nodes), Fields and Plain Effector for deforming the rail. XPresso could be omitted if a Pain Effector with a Field can scale the springs towards -Y when passing above them. 4) Cloner with animated instances and Delay/Time Effector, maybe some FFD Deformer to avoid physics simulation (requires a special setup), a Vertex Map can be used instead of the Delay Effector. I think this can also be done using Hairs instead of Cloner. 5) Looks like hair clamping available under the Hair Material. Can also be done using some attractive forces to guide hair to a single point. I don't think the final image cannot be done in C4D. But the tool being used to grow hair like this is not present in C4D (yet) 6) Field with Vetex Map and Grow effect. It's possible in C4D but a bit expensive to replicate due to the great number of polygons. It could be faked with a Sub-polygon Displacement texture but that should be done in an other app. Doing it as a static image is totally possible using Splines on Fields. But making the Splines have multiple Outlines spreading outwards parametrically is not possible yet (as far as I know). I have a hunch a Spline Outline tool is underway on the next release. 7) Hair, just because a non-experienced C4D user might think hairs can only be very thin non polygonal lines. 😎 oops, meant to type 8 ) This is exactly the reason why we needed nodes in C4D in the first place. Modeling this in C4D, totally doable, very easy. Making the "Wafer" effect is even easier with the current state of nodes in C4D. But making this whole setup with real-time drawing the boundaries of the structure and have the rest of the area grow foliage ... I have a strong feeling that this is not possible (yet). These kind of demonstrations make me wonder though... Why make such an elaborate node structure for one model ? Doesn't the client know the area of the construct yet ? Don't get me wrong, generative/evolutionary Architecture is a thing but C4D, Blender and Houdini are not CAD apps. A variety of similarly looking structures could be a time saver for game assets but I think that a tool like that is more suited to be natively used in the game engine itself. But making a movie with similarly looking buildings to populate a large area, yes, totally worth it. I just think this particular example does not sell the importance of nodes well, it's just the WOW factor. 9) I would say, hair with cloners, or splines and cloners BUT, I don't know how to make an instance spline or particular hair strand grow to a particular state using Fields or Effectors. MoSpline can grow splines the way depicted here but I don't think they work with Fields like this. Happy to discuss how some node scenes could be done in C4D with alternate methods because in this early stage of SceneNodes I find the comparison a bit trivial.