jonmoore

Splendid, now that's what I call good service. 🙂

Nice, that's what I was hoping to hear. 🙂

When you bring an object from the legacy Object Manager into the Scene Nodes system, are there any performance issues to be aware of?

I was really pleased to see the the technology preview version of Scene Nodes contains a smattering of Noise function nodes. And one of the first Noise nodes I dabbled with was the Noise Selection node, very useful as the base for noise based modelling workflows as it simplifies the node tree significantly. However I do have a feature request. I know this isn't strictly the place for feature requests, but seeing as I'm here. 🙂 C4D's noise functions are peerless amongst DCC's, so it's a pity the animate parameter isn't included in all four of the noise function based nodes included in the current iteration of Scene Nodes (I believe it's only included with the Basic Noise node). The Noise Selection node in particular would benefit from an animation parameter as it provides great procedural power but with simplicity and immediacy too. And whilst I'm on the subject of noise function driven modelling, something else I cant find amongst the available nodes is some kind of smoothing/blurring operator. The example below smooths a weight map driven extrusion but the Laplacian Smooth (the algorithm used by the Blur Vertex Data node) is just as relevant to procedural textures or any kind of 0-1 image data for that matter. This is really useful when you want to remove raw jagged edges from procedural extrusions.

Ref the Ray Collision node, I've been searching for a Ray Casting node. Should have known the MAXON team had renamed the generalised CG naming convention to something new! 🙂 Bad jokes aside. I'm finding the documentation to be a very fast learning resource as it contains over 70 simple examples for 'lynch-pin' nodes. The following is a great example of their usefulness: Most CG procedural/generative systems are based on the manipulation of 'arrays' and Scene Nodes are no different. The tricky part for me when learning a new procedural system is learning the 'node syntax'. By that I mean the way specifics of node tree patterns that drives common workflows. I especially like example scenes like the one above as it's not overly complicated nor is it overly simplistic (it utilises the documented node is a simple real world scenario involving a typical selection of complimentary nodes). Much like Xpresso, most nodal systems use a 'get data' > do interesting stuff > 'set data' workflow and this is one of the areas where Scene Nodes differs. The generalised Get/Set workflow doesn't provide the ability to access the full range of geometry attributes. So Scene Nodes requires pairs such as Geometry Property Get/Set, Line Topology Get/Set, Polygon Topology Get/Set. It's an interesting differentiation from ICE/Fabric Engine/Bifrost et al, but I wonder if this adds an extra layer of unnecessary complexity. Maybe this is just because the standardised GET/SET workflow is baked in my bones, but I do like the simplicity of that approach as the critical knowledge for the artist, is that they query a geometry's attributes with 'Get Data', and then after modulating said attributes they re-set them to their new values with the 'Set Data' node. And as I mentioned above, this workflow follows the Xpresso paradigm, and it seems worthwhile to build upon previously learnt conventions wherever possible. Interestingly in the example above there's no 'Geometry Property Set' node as a pair to it's Geometry Property Get'. The 'Transfer Selection' node is it's closest parallel. As I say, I'm not suggesting that there's a right way to do these things but I thought it was an interesting workflow insight to raise.

As an avid observer of C4D over the years (I'm a consultant these days advising clients in the advertising sector on the ever shifting sands of DCC technologies), I'd say the biggest danger for Scene Nodes right now is that they create unrealistic expectations. One of the earliest entries on the MAXON corporate blog back in 2016 made a big deal regarding the engineering efforts towards a new Core, and if memory serves right, it was around the time of R13/R14 that talk of modernising C4D's Core was first publicly aired. So we're talking approximately 10 years here; on that basis users can be forgiven if their expectations are high with regards to the scope of new Core deliverable's (and their manifestation in Scene Nodes). I thought Rick Barrett struck the right tone the other day on the Rocket Lasso live stream when he acknowledged that the next 18 months or so will be full of growing pains when it comes to Scene Nodes. He made an analogy to a building site where hard hats will be a necessity for the foreseeable future. I like Rick's understated approach as he's managing expectations as well as whetting appetites. The public launches of Scene Nodes and Softimage ICE could not be more different. The Softimage team choose to launch ICE as a toolset with a laser focus on particle effects and deformations. My Softimage workstation still has licenses going back to v7.5 which was the first release under Autodesk ownership (basically the same as v7 but with Autodesk licensing). I've just done a quick count of the Compounds included in that early release of ICE and it's close to 200. ICE Compounds are very similar to Scene Node 'Assets' - they're simply a grouping of granular atomic function nodes that deliver a specific piece of functionality. They're main purpose in terms of the ICE launch strategy was that they functioned as an artist friendly introduction to nodal programming, but the artist needn't have a technical background to use them. Hopefully the artist would be curious enough to explore the Compound innards, but this wasn't compulsory and the artist could still get a huge amount of value from ICE without ever having to learn about the atomic level nodes. The launch of Scene Nodes only contains a handful of compound 'Asset' nodes (mainly found in the Generator category). As a result all artists are thrown into the deep end without any arm bands or rubber ring to keep them afloat! I must admit, I'm not certain this was the wisest decision. As things stand I can see many C4D artists having a poke around Scene Nodes for a day or two never to return again. Unless you have a background in programming or in nodal systems such as ICE, the learning curve is a steep one. At least with a healthy quantity of compound 'Asset' nodes, the artist can access beneficial functionality even if their curiosity doesn't instantly propel them forward to learn how the atomic nodes fit together to create said beneficial functionality. Any criticisms here are intended constructively as Scene Nodes are a great window into C4D's future.

I had no doubt. A discussion point came up in the Rocket Lasso live stream with Rick Barrett the other day that I agreed with 100%. The crux of that discussion point was that C4D's success as an artist friendly toolset could be defined by playfulness. The beauty of C4D is that in rewards play and experimentation, as it's very hard to box yourself into a corner (unlike something like Houdini, where you need to have clearly defined goals from the outset of any project). It's that sense of playfulness that needs to come to Scene Nodes, and I think it should be a priority. At the moment Scene Nodes are very much a TD's tool, but if it's too catch fire within the mass of the C4D artist community, it needs that sense of playfulness. And as a quick win please, please link the documentation to the nodes (CTRL, F1). It becomes something of a drag to constantly have search the documentation manually as you explore the nodes toolset. To relate it back to Softimage ICE one more time (apologies for that), PSYOP's Jonah Friedman said during ICE's first year that what makes ICE great is that it makes hero's of generalist artists. What he meant by that was that ICE introduced technical artistry to artists that never defined themselves by their technical prowess. And that feels very much like a MAXON goal. Fields (much like Mograph before it) facilitates technical artistry without expecting a technical background. And for me, Scene Nodes need to be the next iteration of facilitating technical artistry through intuitive play.

ICE from the get-go was deeply integrated with the existing geometry core in Softimage; and that integration was symbiotic with its Operator Stack (similar in concept to the modifier stacks in 3ds Max and Modo). The Operator Stack was introduced to Softimage when it was released with a brand new core as XSI back in the early 00's (XSI was the most modern DCC architecture at the time, that's one of the reasons that ICE was so thread friendly for particle and deformation effects). A screen grab is probably the easiest way for me to describe what makes ICE so different to the tech preview of Scene Nodes (you'll need to view it at full resolution to make sense of the description that follows. The explorer view over on the right side of the interface has a few Objects un-twirled to expose their Operator Stacks. The first thing you'll notice is that there are clear delineations between Modelling, Shape Modelling (generally rig related), Animation, Simulation, Post Simulation and finally Secondary Shape Modelling. ICE trees can exist in any of the Operator Stack regions but in general they are most often utilised in the modelling and simulation regions. In this specific example, the ICE tree's in the Modelling regions are used for set-up of custom attributes and the core of the shot is in the Simulation region of the pointcloud_particles_and_strands object; and this is the ICE tree you'll see in the graph region. The long node on the left hand side of the ICE tree shows one of the key differences between Fabric Engine and ICE. With ICE it's pure simplicity to bring any object into the graph and then hone into the specific attribute of interest so as to introduce the values of said attribute into another calculation context. What this means in artist friendly terms is that it's easy to take a cloth simulation object, explode the polygons to separate polygon islands and use the centres of those polygon islands as seeds for a particle strand simulation that's then converted to polygons (strands are usually rendered as curves in the GL viewport and the offline render usually uses simplistic primitives as an extrusion source). The import take out here isn't the effect itself but the easy with which multiple scene contexts can be queried and co-exist harmoniously in each others contexts. The following is a screen grab for Fabric Engine in Maya 2017 (Fabric Engine was EOL'd in 2017 - just as it was beginning to be useful! It's rumoured to now be the IP of one of the major productions shops). On paper Fabric Engine was a wonderful idea. It's elevator pitch was that it would become a DCC neutral platform that was powered by a very ICE like scene graph. The reality didn't quite live up to the ideal as the UX varied greatly depending on the DCC in question (Maya was the only DCC integration that could be considered production capable). There was even an alpha build for C4D knocking around but that never materialised outside of a very small closed alpha testing group. The biggest problem with working with Fabric Engine was that it always felt like a plugin tacked on top of it's DCC host. Artist friendly integration was sadly lacking. It's major area of strength (when compared to ICE) was that it was capable of very sophisticated procedural modelling. ICE throughout it's history never cracked procedural modelling, it was always a clumsy and frustrating workflow. It's these qualities that were at the core of my comparison between C4D Scene Nodes and Fabric Engine. Neither feel particularly integrated but both provide a great set of tools for procedural geometry asset creation. Apologies for this little digression but I wanted to provide @MikeA with enough information to clarify the differences I'd previously mentioned without writing an essay. 🙂

Good to know. I have been attempting to get useful data fed to the console but I'm probably doing it wrong. I thought there might be some drag/drop shenanigans like there is with the Python console but no worries, I'm just exploring right now.

Ok, so I've had less than 24 hrs with the R23 demo but I can categorically say that Scene Nodes in r23 is nothing like Softimage ICE (and I say that as someone who still uses ICE on a regular basis today, many years after XSI's EOL). Scene Nodes actually feels closer to Fabric Engine than any of the other nodes based systems I've used over the years (I've used virtually all of them at some point in time!). Less than 24 hrs is nowhere near enough time with Scene Nodes to make any kind of judgement call on it's capabilities but I will say that things feel closer to an alpha build than a 'technology preview' public beta build. And that's no bad thing in and of itself, as I think that MAXON need to expose Scene Nodes to the widest spread of C4D artists to help them make sense of where to go next with the system. Once I got over the shock of Scene Nodes not having a representation in the Object Manager or any of the other legacy UX elements for that matter, I've found exploring the system to be relatively straight forward once you get a handle on MAXON's tendency to rename generalised CG nomenclature to 'C4D speak'. A lot has been made of the fact the Scene Nodes are the future of C4D as they don't use any of the legacy code base, and it really impresses when shifting large numbers of clones around the GL viewport; but I think it's fair to say, that in real world terms, Scene Nodes in their current state, are nearly as far removed from daily C4D use case scenarios as Bifrost Graph is to daily Maya workflows (SOuP is a far better example of an integrated Maya procedural nodes system). One thing that I'm finding hard to adjust to, is the apparent lack of visual debug tools. Most procedural systems allow the artist to visualise geometry/point cloud attributes in the GL viewport. At it's most basic, this facilitates the display of component attributes such as point/polygon/curve attributes, but with the vast scope of possible value modulations in a procedural setup, the artist also values the ability to query values at any point of the graph. In the example below, I'm querying the values of particles after a re-scale operation. The large properties box labelled Show Values is the interface the artist uses to set up the 'attribute display' (this is achieved by right clicking on the data stream at point of need - in this example, you'll notice a green V between the Rescale and Gradient nodes. On a more positive note, I was glad to see that the Nodes UI has a far clearer visual UX, compared to previous iterations. It's the only nodal interface that compares to ICE in terms of clarity and efficiency (Bifrost is horrendously wasteful of interface real-estate). But one small trick has been missed (this is a minor UX example, but it seemed apt to raise it here). You'll notice that there's a Scalar (float) node feeding into the Turbulence node in the screen shot below. Where this differ's in terms of UI/UX to R23's nodal interface, is that the value of the floating point value is displayed on the node itself. This means that the artist can see the value simply by scanning the graph (there's no need to open Turbulence property editor to see the value). This can be really effective in communicating key values in a graph for those occasions when an artist will be be returning to a scene setup after an extended period of time. Anyway, I'll stop here as I'm keen to carry on playing with R23. I have a feeling I'll be shifting a lot of my daily workload till after the weekend as there's a huge amount to grok, but I'm enjoying the journey so far. 🙂

That's correct in the case of Bifrost, but the beauty of ICE was that it was deeply integrated into the core of XSI. It's true that in the beginning it was fundamentally built as a system for particles and deformations (anything that involved the manipulation of vectors - all with multi-threaded performance that continues to impress, even by modern day standards ). But by the time of Soft's EOL annoucement, ICE covered many other core areas of functionality such as kinematics, modelling and crowds. But a trip to Si-Community (where the rray database of XSI addons currently resides) shows how the community of technically minded XSI artists used ICE for far more than that confined range of specialisms I've outlined. None of that is to take away from the new node graph in R23. C4D increasingly feels like a better permanent home for ex Softimage artists. And that's because Softimage was always far more than it's technical capabilities, it's primary selling point was it's artist focused user experience. A goal the MAXON team has always looked to deliver for its customers. The problem with the C4D of old was that it's technical capabilities didn't always reach the heights of the UX. Over the last few years (now that the long term investment to upgrade and modernise the core has come to fruition), C4D is delivering on both UX and artist friendly technical capabilities. And this mix is a very attractive proposition for artists from the Softimage community. For all of Houdini and Maya's strengths, their workflow is still a bone of contention for many Softimage artists. But back to my main point. Whilst Bifrost and Fabric Engine (RIP) were/are separate applications that lack deep integration to their host DCC, working with ICE was no different to working with the Softimage JSscript/Python/C++ SDK; the one critical difference being that threading came along 'for free' (much like Houdini's VEX/VOPs in that regard). I can see R23 converting a raft of new customers from outside of motion design. And that can only be a good thing in terms of maintaining a rich diversity of DCC options in an increasingly monopolistic marketplace.

This isn't a complaint as such but I am aware that my clients will be upset if Houdini Engine support is still stuck at 16.0.633. This spring update usually updates the Houdini Engine support to the a newer version and 16.5 has been out a very long time. It wouldn't be so bad but Maya, Max, Unity and UE are updated every single day with Houdini's daily builds. Now I understand that because MAXON update the Houdini Engine support themselves rather than it being something provided by SideFX but MAXON shouldn't make such a big deal about Houdini Engine support if they can't at least provide support for the latest Houdini Engine production builds, never mind the daily builds.