Jump to content

R25 Expectations


Recommended Posts

No, they are not. There are similarities, but the differences are fundamental. Xpresso adjusts the parameters of objects in an existing scene graph, scene nodes define the scene graph itself. Where it is easy to reference the same object multiple times in Xpresso, this just doesn’t work in scene nodes since you do not work with references, but the scene graph elements themself. Scene Nodes are NOT an expression system.

Link to post
  • Replies 137
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Sadly this is the truth now. I also know many developers who have left C4D plugin development. With the cost of subscriptions and the fact that nobody wants to pay to help develop a plugin to its full

+1 on your entire post. Since the release of R21 I seem to have noticed quite a decline in plugin purchases ... that was until I entirely stopped the business due to costs rising way over benefit

Are they really?... Xpresso is a basic, easy, clear piping of position X into position Y that mortals can comprehend.   Scenes nodes is.... decomposing a global matrix, splitting a matrix in

Posted Images

38 minutes ago, imashination said:

 

Are they?... I just gave myself the simple task of making the X movement of a cube control the Y movement of a sphere.

 

I can do this with 'set driver' in 5 seconds.

I can do this manually in xpresso nodes in 20 seconds

So far I've spent far longer than I'd like to admit in scene nodes and haven't yet worked out how to do it.

 

I agree that xpresso is dead and shouldn't be further developed, but please, let's not pretend scene nodes is a clean upgrade from xpresso.

 

Grossly simplified, from a programmer's perspective, all the approaches are roughly the same at the core: data comes into an object and is used for some calculation, and the output from that calculation goes to some out-port again. You can do that with plain objects (a link field provides the connection); with a Python tag (code refers directly to the objects in question); with internal functions (which have a parameter list and a result list); with XPresso (in and out ports are explicitly given); and with Scene Nodes (dito). It's all just data flow in the end.

 

There are three main differences between these methods (and all others that you can devise):

 

Internal structure: how the flow is handled (can the algorithm be parallelized; can it utilize GPU; it is explicit; do we directly pass values or interpret the node structure in some form; what happens to large amounts of data; do we require semaphores; what happens with flow loops...) This will decide how fast the thing can even be. However, the internals are hidden from the end user, so this part of the machinery stays under the hood.

 

Accessibility: how much control does the system expose to the end user? In case of just the OM tree, all the connection between objects are defined by the hierarchy of objects (e.g. assemble a sweep from a cross section and a path under a Sweep object). Links add one more option to connect objects, but from a practical standpoint you cannot make an explicit link from every parameter. XPresso and Scene Nodes do exactly that; they create ports for everything. Same with the Python API to use in tags and generators (etc). As soon as your GUI allows for arbitrary ports, the accessibility is only limited by what the programmers allow you.

 

Ease of use: how easy and fast is it to set up stuff? Ultimately, you can see the GUI as an access to the internal structure. That access may be easy to use, see the sweep example. Or it can be difficult, like "write your scene setup and animation in Python" (don't laugh, that is the principle of POVray!). The big gap lies between the OM tree (easy to understand and to scroll and to open/close branches in) and the node approach (whatever node system you have), where you need to maneuver in two dimensions and need to have the ability to "zoom in" on a structure. I have tried my hand in the past at such GUIs, and it's very very difficult to keep it functional and intuitive.

 

Now, taking 5 seconds to set up a connection between two elements by "Set Driver" is because the GUI offers you a special command that sets up a basic XPresso node system.

Taking 20 seconds to do it manually would be the standard case for all situations where no such special command exists.

Not being able to do it in Scene Nodes is because Scene Nodes are a separate, generative approach that does not mix with the OM objects.

 

Ultimately the ease of use of the Scene Nodes will depend on the ways you can navigate in the node setup. The accessbility is already maximized or can be extended as needed, and the internal structure is hopefully optimized. If you feel that Scene Nodes are not properly replacing XPresso, that is because XPresso is a system building on (and controlling) objects defined within the OM tree, while the Scene Nodes are a generative system that runs in parallel to the OM.

Link to post

I think the absolute end game of the 3D software industry is the combination of parametric modeling with semi automated UV mapping, baking, texturing optimization and export / render, and with geometry nodes and material nodes this could be achieved by adding the few missing links of a good integration of UV mapping into nodes (I almost only use the new auto mapping at this point) and allowing proper baking of curvature, normals etc, thus finally allowing proper texturing and creating complete assets. Cinema has sat too long on the back of people making text and spheres with cubic tiling materials and missed many opportunities to jump into movies and games as a cause, and with real-time becoming more prominent, more arch-viz and others are moving to Unreal 5 and Unity HDRP to do their rendering as well, requiring assets with proper baked texture maps as any software is capable of producing - only in cinema circles this is still unheard of.

 

Cinema made a lot of really good moves with the latest versions, with 24 finally having the possibility to do a full modeling and UV workflow that is bake ready in software, now there is not much missing to bridge the gap between C4D and the others in terms of asset workflows, allowing C4D to shine with its other powers at last.

 

I know I am in the 1% that is asking for these industry standard asset workflows but that is due to C4D not supporting them and all the users in need are clearly using something else. Motion graphic artists will also appreciate stepping up their game and having the possibility towards creating much better assets aside of relying on rendering power of the latest render engine to overshadow that their assets don't have proper texturing and rely overwhelmingly on tiling materials.

 

(Please add at least a curvature mask node so people can do normal texturing workflows like any software allows you to. Without curvature you are essentially dead locked from doing anything parametric or smart outside of manually painting everything. This is the most important aspect of any quality texture and the Edges Mask node is very glitchy, unpredictable and does not work well at all.
I heard there is a redshift curvature effect but this also needs to be exportable. I hope someday there will be a revamped baker and I really hope the nodes team are looking into making geometry nodes viable for complex real world scenarios as people would do with Houdini in a more complex fashion and not just abstract effects)

 

Things also desperately need to be cleaned up. There are still prehistoric "Specular Blinn" reflection materials as default, very strange parity between viewport and rendering and multiple types of material cores at this point. Having a much more feature complete but heavily outdated core that then requires a different render engine on top is a really awkward spot to be in. Unity did a similar thing where they split into 2 (3) render pipelines which was the worst move they ever did. Unreal has one pipeline that just works, now unity will forever have to support 2 or more highly complex non compatible pipelines which has been so far years of disaster and while they are slowly recovering, it is still a mess and always will be.

 

---

 

While I really like the seats backend as a company owner, I expect for the general community a better model for entrance otherwise new users will die out, I also expect the start of a plugin marketplace which is just a win-win business move (unless the share asked is too high, keeping creators on their own sites)

Blender is really thriving due to their plugin economy per example even if they take no share (afaik).

 

 

 

Link to post
2 hours ago, mrittman said:

@hobbyist, so perpetual users no longer get access to the asset/content browser? First Cineversity, now this. And for $3500… 🤦🏼‍♂️

 

The new Asset browser is online and requires assets to be downloaded. Unless the default models are available on release to download and they make future models only available to subscription? Not a good sign for perpetual anyway.

 

I'm very happy with R23 but have some plugins I need to go back to R20/21 from time to time. 

 

Link to post
1 hour ago, Cairyn said:

 

Grossly simplified, from a programmer's perspective, all the approaches are roughly the same at the core: data comes into an object and is used for some calculation, and the output from that calculation goes to some out-port again. You can do that with plain objects (a link field provides the connection); with a Python tag (code refers directly to the objects in question); with internal functions (which have a parameter list and a result list); with XPresso (in and out ports are explicitly given); and with Scene Nodes (dito). It's all just data flow in the end.

 

There are three main differences between these methods (and all others that you can devise):

 

Internal structure: how the flow is handled (can the algorithm be parallelized; can it utilize GPU; it is explicit; do we directly pass values or interpret the node structure in some form; what happens to large amounts of data; do we require semaphores; what happens with flow loops...) This will decide how fast the thing can even be. However, the internals are hidden from the end user, so this part of the machinery stays under the hood.

 

Accessibility: how much control does the system expose to the end user? In case of just the OM tree, all the connection between objects are defined by the hierarchy of objects (e.g. assemble a sweep from a cross section and a path under a Sweep object). Links add one more option to connect objects, but from a practical standpoint you cannot make an explicit link from every parameter. XPresso and Scene Nodes do exactly that; they create ports for everything. Same with the Python API to use in tags and generators (etc). As soon as your GUI allows for arbitrary ports, the accessibility is only limited by what the programmers allow you.

 

Ease of use: how easy and fast is it to set up stuff? Ultimately, you can see the GUI as an access to the internal structure. That access may be easy to use, see the sweep example. Or it can be difficult, like "write your scene setup and animation in Python" (don't laugh, that is the principle of POVray!). The big gap lies between the OM tree (easy to understand and to scroll and to open/close branches in) and the node approach (whatever node system you have), where you need to maneuver in two dimensions and need to have the ability to "zoom in" on a structure. I have tried my hand in the past at such GUIs, and it's very very difficult to keep it functional and intuitive.

 

Now, taking 5 seconds to set up a connection between two elements by "Set Driver" is because the GUI offers you a special command that sets up a basic XPresso node system.

Taking 20 seconds to do it manually would be the standard case for all situations where no such special command exists.

Not being able to do it in Scene Nodes is because Scene Nodes are a separate, generative approach that does not mix with the OM objects.

 

Ultimately the ease of use of the Scene Nodes will depend on the ways you can navigate in the node setup. The accessbility is already maximized or can be extended as needed, and the internal structure is hopefully optimized. If you feel that Scene Nodes are not properly replacing XPresso, that is because XPresso is a system building on (and controlling) objects defined within the OM tree, while the Scene Nodes are a generative system that runs in parallel to the OM.

All fine and dandy, but it doesn’t change the fact that they’re not being used at the moment 🤔

Link to post
1 hour ago, MODODO said:

The method is the same as Xpresso

 

 

Are they really?... Xpresso is a basic, easy, clear piping of position X into position Y that mortals can comprehend.

 

Scenes nodes is.... decomposing a global matrix, splitting a matrix into individual vectors, swapping the x vector into a y vector, combining the xyz values into a vector then recomposing the vectors into a matrix before feeding it into the sphere and finally sending the op output back into the scene.

xp.png

Link to post

Maybe not an R25 request, but as we  are talking about Xpresso vs. Scene nodes, one thing that I have always wondered how to do is set up a set of controls by which you could control and randomize the settings of all the child objects.  I know you can control them with the Hierarch Operator in Xpresso, but what if I want to have slight random changes with each of the child objects....and not just object size or orientation which can be done with a random effector but any of the settings with the lights in a scene.

 

For example, imagine the lights in a freeway tunnel.  What really makes that scene look realistic is when every light has a slightly different level of intensity.  Well, there are hundreds of lights in a freeway tunnel and to do each by hand is tedious.  There is a constant chorus of "add randomness to your models because life is NOT computer perfect" but that philosophy never makes it to lighting.  So is there a way using scene nodes or Xpresso to vary the light intensity on each light at once...you pick a starting intensity (for example 90%) and  then you set a min/max range (for example 10%).   You apply these controls to the parent once and all 100 or 200 lights that are children of that parent will have an intensity that varies between 80% and 100%,   But not just light intensity, but radius or decay, volumetric inner and outer distance....pretty much any of the light controls.  

 

I know this capability already exists for cloner objects...but I have not found it for scene objects like lights that can't always be cloned as they need to be in specific locations.  So can scene nodes do it?

 

Dave

 

 

Sorry...but I simply do not have enough faith to be an atheist.

Link to post
19 minutes ago, imashination said:

 

Are they really?... Xpresso is a basic, easy, clear piping of position X into position Y that mortals can comprehend.

 

Scenes nodes is.... decomposing a global matrix, splitting a matrix into individual vectors, swapping the x vector into a y vector, combining the xyz values into a vector then recomposing the vectors into a matrix before feeding it into the sphere and finally sending the op output back into the scene.

xp.png

 

Actually, the difference is only that XPresso is doing the splitting and reassembling of the matrix already for you by offering sub-elements of the matrix to set as input and output. It looks more complicated in Scene Nodes (and takes longer to set up) but essentially it's the same.

 

(I'm currently more miffed that I seem to be unable to apply any viewport operations to Scene Nodes. Still on R23 so I don't know whether it's not implemented yet or whether I'm just too dumb to find it in the help, but without interactivity, it feels like POVray all over.)

Link to post

How components are accessed is just ui, nothing fundamental that makes a difference on a structural level.

scene nodes controlling lights is currently not possible, except if you use node materiales with luminance for the lights, but even then the control would be per material.

I don’t have Cinema in front of me right now, but if you can iterate through all lights using a Hierarchy or List iterator you can change parameters individually by using the current index as a seed for the randomness.

Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    No registered users viewing this page.

  • LATEST ACTIVITIES

    1. 0

      Picture viewer much brighter than viewport

    2. 4

      Make a hat fall through the air with controlable turbulence, lift and wind???

    3. 3

      Corona Renderer 7

    4. 4

      Make a hat fall through the air with controlable turbulence, lift and wind???

    5. 175

      Houdini Tests and Impressions

×
×
  • Create New...

Copyright Core 4D © 2021 Powered by Invision Community