Jump to content

R25 Expectations


Guest Igor

Recommended Posts

Thanks Srek for the explanation,

 

But I think the discussion is about something different. It looks like there are two groups that just are not able to really understand each other, as most of the arguments where exchanged multible times in this thread.

 

- One Group tries to enplane, what scene nodes are, and that they are superior to xpresso and therefor xpresso will get obsolete.

 

- and the other group states that it likes xpresso for ist easy usability and because it is a tool that makes skripting accessible to non coders. And that a more powerfull tool might be of absolutely no use for them if is to complex for them to learn.

 

What I read out of the discussion is, that every one now has accepted, that scene nodes is technically something different then xpresso, that it is much more powerfull and that it can reproduce everything that xpresso can do.

 

But what I don't really can read from this discussion is a real concept to make these complex scene nodes as accessible as xpresso or even better accessible. I read That it all is just a UI thing (It will not be as easy as that) or that node groups can be produced as new asset (which is really cool, but doesn't help when you have to find it between ten thousand other nodes, that form every function of a already quite complex program).

 

I from my standpoint I think that it is highly advisable for the technical side to try to understand the fears of some of the users here and use this understanding to form something better but at least as easy to use as xpresso. I assume that there are already some thoughts about that, but I think, that the most powerfull tool is of no use if you can not utilize it and as sceene nodes is as complicated as the whole of C4D, as we know it,  Maxon needs to put as much brain into the usability as they did with the whole UI that we have right now. Otherwise it is not much more then a API.

 

best regards,

Jops

 

 

 

 

Link to comment

Simply study the scene node, and you will find that it is actually easier to use and logically better than XPRESSO.
If there are multiple cases where the scene node is more complicated than XPRESSO in the actual exercise, please post them so that everyone can judge what happened.

Link to comment
18 minutes ago, Jops said:

Thanks Srek for the explanation,

 

But I think the discussion is about something different. It looks like there are two groups that just are not able to really understand each other, as most of the arguments where exchanged multible times in this thread.

 

- One Group tries to enplane, what scene nodes are, and that they are superior to xpresso and therefor xpresso will get obsolete.

 

- and the other group states that it likes xpresso for ist easy usability and because it is a tool that makes skripting accessible to non coders. And that a more powerfull tool might be of absolutely no use for them if is to complex for them to learn.

 

What I read out of the discussion is, that every one now has accepted, that scene nodes is technically something different then xpresso, that it is much more powerfull and that it can reproduce everything that xpresso can do.

 

But what I don't really can read from this discussion is a real concept to make these complex scene nodes as accessible as xpresso or even better accessible. I read That it all is just a UI thing (It will not be as easy as that) or that node groups can be produced as new asset (which is really cool, but doesn't help when you have to find it between ten thousand other nodes, that form every function of a already quite complex program).

 

I from my standpoint I think that it is highly advisable for the technical side to try to understand the fears of some of the users here and use this understanding to form something better but at least as easy to use as xpresso. I assume that there are already some thoughts about that, but I think, that the most powerfull tool is of no use if you can not utilize it and as sceene nodes is as complicated as the whole of C4D, as we know it,  Maxon needs to put as much brain into the usability as they did with the whole UI that we have right now. Otherwise it is not much more then a API.

 

best regards,

Jops

 

 

 

 

If you split it like that then i have to say that neither group has it right. Xpresso and Scene Nodes are two different tools with different purposes, one can't replace the other.

Xpresso is easier to use (UI/UX issues aside) since its scope is smaller and it avoids most of the complexity involved since that part is left to the object manager and the (old) scene graph it creates.

Scene Nodes are way more complex than Xpresso because they replace what the Object Manager does, they create the (new) scene graph. At this point in development the Scene Manager is just starting to try to enable users to work with the new scene graph on a level that is similar to the Object Manager. The Scene Nodes represent something the users never had direct acces to before, only serious plugin developers faced similar complexity when creating own objects. It is no surprise that not every user is comfortable with this and it is really important to understand that noone expects that every, or even a majority, of users will ever be comfortable working based on Scene Nodes.

The current situation is just an artifact of the need to build up a new system from the bottom up and the decission to make this available to users early (Tech Demo). The alternative would have been for Maxon to keep this development under wraps for several more versions until the Scene Manager is in a state to replace the OM, but that would also mean that we at Maxon would not get very valuable feedback from users, something that is of high importance given the nature of these changes.

So please everyone, give us feedback, but keep in mind that Scene Nodes are not the final main interface for everyday use by most users.

As for the future of Xpresso, i see the need for something very much like Xpresso, but based on Scene Nodes, once the Scene Manager reaches a certain degree of maturity. We might as well call it XPresso 2.0, but it would have to be something completely new that mainly has the purpose in common with old Xpresso. A lot depends on the experience we gain from current development and the feedback we get on it.

Link to comment
1 hour ago, srek said:

If you split it like that then i have to say that neither group has it right. Xpresso and Scene Nodes are two different tools with different purposes, one can't replace the other.

Xpresso is easier to use (UI/UX issues aside) since its scope is smaller and it avoids most of the complexity involved since that part is left to the object manager and the (old) scene graph it creates.

Scene Nodes are way more complex than Xpresso because they replace what the Object Manager does, they create the (new) scene graph. At this point in development the Scene Manager is just starting to try to enable users to work with the new scene graph on a level that is similar to the Object Manager. The Scene Nodes represent something the users never had direct acces to before, only serious plugin developers faced similar complexity when creating own objects. It is no surprise that not every user is comfortable with this and it is really important to understand that noone expects that every, or even a majority, of users will ever be comfortable working based on Scene Nodes.

The current situation is just an artifact of the need to build up a new system from the bottom up and the decission to make this available to users early (Tech Demo). The alternative would have been for Maxon to keep this development under wraps for several more versions until the Scene Manager is in a state to replace the OM, but that would also mean that we at Maxon would not get very valuable feedback from users, something that is of high importance given the nature of these changes.

So please everyone, give us feedback, but keep in mind that Scene Nodes are not the final main interface for everyday use by most users.

As for the future of Xpresso, i see the need for something very much like Xpresso, but based on Scene Nodes, once the Scene Manager reaches a certain degree of maturity. We might as well call it XPresso 2.0, but it would have to be something completely new that mainly has the purpose in common with old Xpresso. A lot depends on the experience we gain from current development and the feedback we get on it.

Thanks Srek again 🙂

 

you sum up pretty much my assumption of the situation.

I very much like that maxon makes the scene nodes available early, but the purpose of scene nodes and the future outcome (which UX will differ quite a lot from now) seems to have the potential to be communicated better (even though you as a person in this forum obviously are doing you best 🙂)

This discussion here is a nice example of the feedback you are hoping to get :). Maybe not the kind you expected but never the less useful.

 

Link to comment

Underneath all the discussion of scene nodes vs. Xpresso, three very important points are being completely missed:

  1. C4D's legacy for ease-of-use.    Sorry, but the Maxon team has a 35 year history of making the difficult very simple with such tools as MoGraph, Xpresso, and the Object Manager. 
  2. Scene nodes being rolled out as a "tech-demo" immediately sends the connotation of complexity -- just by its name alone.  Add to that examples of complex nodal trees to do things that are easy to replicate in MoGraph and you have a hard sell to a user base that has grown comfortable with easy to understand drag and drop functionality. 
  3. Adding insult to injury is the hard line tone coming from Maxon:  "Scene-nodes is the FUTURE.  GET ON BOARD OR BE LEFT BEHIND".    Really?  Very interesting marketing strategy there Maxon.  "Telling the user" rather than "listening to the user" is never good for a company.  Some people have even stated that there is a bit of shaming going on relative to Scene Node adoption (Are you smart enough for Scene nodes?).  Well that has to stop and the arrogant pugs who behave that way need to be taken to task.

When you combine these three points together, I do believe that what the average user is internalizing is this message from Maxon: "We are throwing out everything that you have grown to love about C4D in favor this new architecture ".    That is not good.

 

My recommendations is to continue the development of Scene nodes as it is smarter way to proceed but it should always be marketed/communicated/demoed as  what it is being developed to be - and that is an "under the hood" capability.  Maxon needs to reinforce the message that you can live quite comfortably with C4D and all the benefits of the new architecture without ever having to look at a scene node.   Making statements that Xpresso is going away in favor of scene nodes does not help.  The last couple of posts were very informative in explaining how Xpresso and Scene Nodes address two completely differently workflows so my assumption is that the functionality of Xpresso is still required but a future version of it will exist under the Scene node umbrella.  If true, that is the message that should be communicated and every effort should be made to make the new scene-node equivalent of Xpresso look and act like Xpresso does today.  Sorry...I know it is more work but 35 years of training brought us to where we are today so you proceed at your own peril if you don't respect that.  

 

In summary, Maxon needs to reset on how scene nodes is being marketed.  You do have a hard sell on your hands and these forum discussions are not helping and thus my recommendation to reinforce that it is an under-the-hood application.  One way to quickly get that point across is to develop new and more highly requested tools (such as proper symmetry) as complete scene-node constructs.  "Hey, we know you all love all the power of this new tool, but did you realize that its 100% built on scene nodes?"  If you do that a few times, or replicate some of the cool modeling modifiers that were coming out of Maxon Labs (like extrudifier or coons mesh, etc) as 100% scene nodes and people will quickly catch on.  Add to that the ability for all those dis-enfranchised plugin developers to switch to creating scene-node developed tools in a way that protects their IP and removes some of the headaches for licensing, marketing, etc via a Maxon developed portal (hey...how about the ultimate greeble tool in scene nodes?) and now you start flipping the script on how Scene nodes is being perceived by the user.

 

Just a thought.

 

Dave

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

Link to comment

Thank you Srek, that sums it up really well.

I think opening up development for feedback is really smart. 

Personally, I hope C4Ds revamp will bring me (in broad strokes):

 

Performance

The more artistic decisions per hour, the better. 

 

Ease of use

With more performance under the hood, please consider presets

that mimick real-world-behaviour for ... everything 🙂

A lot of times, I just want to pick a preset and be done. 

Apart from presets: You guys are UX masters, so just keep going.

 

Complexity as needed

Then again, the new UI and "realistic presets" should allow us to 

drill as deep as we like, whenever we need a really custom solution. 

 

A marketplace for pre-packaged Stuff

It would be really cool if the new scene nodes would allow devs to

easily build complex stuff that more artistically  oriented people like

me could buy from a central place. Preferably, a curated Store,

or maybe even directly from the asset browser. 

 

Thanks 🙂

 

Link to comment
  • 2 weeks later...

2 things: 1. A smarter Texture Manager.  2. Forced moving of texture files when copy-pasting from another scene. Could already been implemented in newer versions, since I am using r18 or 19 currently. But we will eventually upgrade.

 

1.

So, when I need to transfer a file, I save with assets. Even though all of the entries in the Texture Manager indicate green check marks, I often still get warnings during the "save with assets" phase about "can't find filepath/texture" and I then manually tell it where to look.

 

If I tell it to find a texture in 'networkpath/texturelib/metal', for example, it only looks for that one texture. If there is another texture it can't find in the same place, it will spit up the warning and I have to point to the same dir.

 

Would be nice if it would find all missing textures within a single specific location instead of asking for the same location multiple times.

 

 

2.

When I copy and paste an object with textures from one file to another, C4D should ask if I want to put copies of the textures to the local tex folder. This would save so much wasted time. We do ArchVis, so quite often we copy objects and materials between files. This is not a problem when working with centralized texture library because the texture path is absolute. However, in my current hybrid workflow, I use Mac at work and PC at home. This requires that I keep my files on a portable drive, utilizing the 'tex' folder for each project so I can open the scene at work or at home without relinking textures.  Maybe my situation is highly specific, but I still think being able to copy-paste objects between files and move the linked textures at the same time just makes sense with how C4D works in general.

Link to comment

Since the pandemic, your situation might be the standard now 😉 Having the same problem, we put the library in the cloud and made virtual drives (subst...). This way, the centralized texture library workflow was kept all the way, even as everyone one was/is in the home office.

 

But I totally agree with you. Cinemas way of handling textures cost me already lots of hours. And the new project assets inspector (which replaced the texture manager later) has some new quirks. Sometimes it doens't even show missing textures.

Link to comment

I am C4D fanboy so no criticism should be taken personally, it's because I love the software and don't want to learn all the blender shortcuts anytime soon is why I am talking 'passionately'.

There are two sections I expect every year but probably will be neglected for awhile:

1. Character workflows including -  Xref update that actually work how you expect without going through entire myth of buttons and checkboxes to make it just stable enough that it wont corrupt your animators work when he accidentally does something. Just copy maya at this point. Also animation layers that work without being absolutely destructive like Motion systems is.
And then some rigging stuff would help, for example IK chain templates could be cool, where you don't have to make your own systems and all the most popular IK chain setups would lay inside the one tag. Mechanical IK, Normal IK, Spine IK. Wings, quadruped, etc etc.

2. PBR Shader that would work as an default shader and would display in the viewport how it suppose to look. Entire world moved to the PBR and the Reflectance system is just not being used anywhere else outside of C4D and their own render engine, even Redshift doesn't display standard shaders properly...

Link to comment

Since this topic is about expectations, for better or for worse this is my guess:

 

As Redshift has moved to subscription and is owned by Maxon, R25 will reflect this company-wide decision and be proposed as a benefit: "Get Your Render Engine of Choice and Favorite DCC, Better Integrated than Ever, for One Low (but higher than you'd like) Price." Maybe one or two more last calls for upgrades, but more officially stated that its generally ending if not over. Better integration with redshift will be sold as a major new feature for sure, so it will be treated like a native renderer now with better workflows integrated so that it doesn't feel 3rd party at all.

 

THEN... a whizbang feature or two that you never knew you even wanted and certainly don't remember asking for. And then some usual "wasn't this a $25 plugin???" crap thrown in that will make everyone sweat as to whether or not they have had enough this year and just give up already... that's my guess.

 

Link to comment
17 hours ago, Vizn said:

2 things: 1. A smarter Texture Manager.  2. Forced moving of texture files when copy-pasting from another scene. Could already been implemented in newer versions, since I am using r18 or 19 currently. But we will eventually upgrade.

 

1.

So, when I need to transfer a file, I save with assets. Even though all of the entries in the Texture Manager indicate green check marks, I often still get warnings during the "save with assets" phase about "can't find filepath/texture" and I then manually tell it where to look.

 

If I tell it to find a texture in 'networkpath/texturelib/metal', for example, it only looks for that one texture. If there is another texture it can't find in the same place, it will spit up the warning and I have to point to the same dir.

 

Would be nice if it would find all missing textures within a single specific location instead of asking for the same location multiple times.

 

 

2.

When I copy and paste an object with textures from one file to another, C4D should ask if I want to put copies of the textures to the local tex folder. This would save so much wasted time. We do ArchVis, so quite often we copy objects and materials between files. This is not a problem when working with centralized texture library because the texture path is absolute. However, in my current hybrid workflow, I use Mac at work and PC at home. This requires that I keep my files on a portable drive, utilizing the 'tex' folder for each project so I can open the scene at work or at home without relinking textures.  Maybe my situation is highly specific, but I still think being able to copy-paste objects between files and move the linked textures at the same time just makes sense with how C4D works in general.

Good to hear it’s not just me finding the copy/paste process user unfriendly. Better texture handling would save me hours of work. 

Link to comment
On 7/10/2021 at 1:10 PM, jackTheStorm said:

You can easy make hybrid system between Scene Nodes and Xpresso with drivers

 

I'm seeing that S.Rath is ignoring Scene Nodes and we still have not Python node

Hi since R24 you can create and manage Scene Node and Node Material with Python.
Implementation of a Python node is of course technically possible in the future but most likely will never happen as long as Python is only 1 thread as it will basically kill all the Node performance.

 

Link to comment
×
×
  • Create New...

Copyright Core 4D © 2023 Powered by Invision Community