MighT

@Digital Dave I tried to reproduce this here as well. Unfortunately I was not able to. I'd agree to suspect the GPU driver. Maybe even After Effects in background is needed to run into the issue? I don't have it, so I can't do the test. Which layout did you use? Was it a standard or a custom one? Or does it happen with all? What were your render settings? Was Redshift active and maybe rendering material previews in background? I know, given the consequences, it is tedious to test. But I'd say, the more details you can find out, the better the chances anybody can help you. Did you already report this to Maxon? They will know best about driver incompatibilities and in the end probably the only ones able to help with this.

Buckle up for the complexity of the Resource Editor 🙂 There as well, you have so many more options. But fear not, after a brief moment of shock and after having used it a few times, you will see, the stuff you did in the User Data editor is just as easy in the Resource Editor.

Oh, I mentioned Xpresso's simple data types. And for Scene Nodes I spoke about "arrays of arrays of vertices". That's by far not the end of the line. In Scene Nodes you can build arbitrarily complex data types, almost like developers are used to in C++ (compound data types, e.g. a type which contains a color, some position data, a list of connected entities, speed value and temperature. You see some use case for it, well, in Scene Nodes nobody holds you back). The problem Maxon will face in the coming years, how to boil all these options and overwhelming complexity down to something, the arbitrary user can make use of and so it is fun to use actually (currently Scene Nodes are probably more fun for people like me... lets call them nerds). Capsules, I think, are a first step in that direction (even though born from a completely different reason). And I'm pretty sure we need to imagine the future along these lines.

@JThreeDInstead of the Xpresso result node, you now have the "Port Inspector" (basically small result flags you can enable per output port) and the Data Inspector (a kind of data browser) (as Björn said, both to find for example in the context menu of ports). The problem in Scene Nodes is, the setups are rarely as simple as the average Xpresso setup. Simplified in Xpresso you have a bunch of input values and generate a bunch of output values. Values had relatively simple data types (with a Matrix already one of the more complex ones) and if you wanted to really demonstrate your coolness, you three a few iterators into the mix to impress your friends. Not saying, Xpresso wasn't capable of more, but I think, most setups out there never grew past this point. Scene Nodes is a completely different beast. It uses a data flow paradigm to start with. In the end this means, you almost always work on streams of data (arrays of vertices, matrices, whatever... or even arrays thereof...). While this means great power (you can do things with only a few nodes, you only dreamt of in Xpresso), it also means, there is rarely a single value (i.E. just one single number), which could be displayed so easily as with the result node. And there comes the Data Inspector into play...

Well, they didn't leave it out. At least as I understand it. But yep, it's not ideal. The perceived distance from ideal, I didn't want to judge. And I tried to phrase it as careful as possible, so I do not end up in one of "these" discussions again. As I said, I doubt, Maxon wants to have it this way. Nor will they want to leave it this way any longer than they must. I know, now, I will get replies "but it's n years since they bought Redshift!!!". But I do not want to discuss the development speed either. I have a rough idea, how complex this is and ending up with a release with a broken (I mean broken broken, like in "I dropped my aquarium two meters to a stone floor") material system is certainly nothing anybody would want.

@MJV No need to copy. Unfortunately we were writing in parallel. You can still create such materials in S26.

I think (but I'm far from being a Redshift expert), you need to create a Redshift C4D Shader material (Material Manager -> Menu Create -> Redshift -> Materials -> C4D Shader). Then, when you open the Node Editor via that material, you will make a short time travel to previous C4D versions and will see the old Xpresso base Redshift Node Material editor. This is probably already discussed elsewhere (Redshift forums?). It's not ideal currently. I hope, I'll not talk complete bs. Somebody knowing, maybe from Maxon, may correct me: Cinema 4D shaders live in the old world (outside of the new core), if I'm not mistaken. Thus, they seem not easily accessible from the new Node Editor or the new Redshift Node Material. In order to not break old projects or block access to some beloved features, there is this workaround. In my mind, this is evidence of how complex the transition to new core is in this area. I doubt, this is supposed to stay.

I can actually understand all those fears and feelings. But Fritz is the wrong guy to focus the pent-up aggression onto.

I didn't ask anybody to stop criticizing. And I will not lead this discussion about Maxon abandoned every feature, after it got released in an unfinished state (it is simply not true, even if you feel like so or can name a few examples). And maybe somebody can explain to me, when a feature is done? When is it allowed to be released to this dearing community? After how many updates is a company allowed to move on and work on another feature? Or in order to go full circle, how long should Maxon take to polish a feature before its released? I could understand all this if it wasn't this release. And I do not think you will find a word along these lines from me on S24 or R25. But now it is: "Uh, this was available as a plugin before, that doesn't count as an addition!" "Meh, they only bought someone else and copy/pasted the code in, that doesn't count!" "Bah, who would need that as a parametric generator. I do not want non-destructive workflows, that's a downer!" or now: "Man, the new feature has an issue. The developer only said, it's not optimal. It will stay like this forever." And some consensus seems to be, just because one bought a product (which one can evaluate either for free or for a few bucks, at least in this regard I see some positive in subscription), does not work as one expects it to work, justifies to ignore all rules of civil communication. Even more stupid, one seems to think, that such behavior will actually leave an positive effect on the other side and make them work harder on one's issues... I don't get it.

@thanuleeI'm not sure this helps improving the communication between Maxon and this community. To be fair, Fritz's profile says "Maxon". This doesn't necessarily imply, he's a developer, but could still be interpreted as not completely unknowing about the matter he's talking about. Maybe there's more beef going on over at Twitter, but I just re-checked the entire thread and I did not find Fritz justifying anything. He actually admitted, it is currently not optimal. My expectation would be, we are seeing a first iteration of a new simulation system. Turbulence is currently not a part thereof, if I'm not mistaken. Instead of just providing the new simulation in an isolated way (which would most likely mean it to be more limited) Maxon has decided to try to translate between these systems. Is the result optimal? Probably not. Was it to be expected to be optimal? I don't think so. But should we expect this to be the final state? I don't think so either. I think, it was Rick Barrett in the stream with Chris Schmidt, who already said between the lines, that we can probably expect more to come in this area. And to me it would only make sense to continue the started unification of simulation systems. But we should also be fair, taking into account that he is a developer, his main task is to develop and not do user support. His time invested in user support, could well mean, less new simulation stuff in the next version. He even offered to look into examples, if you'd provide him with any. Instead you expect him, to deliver examples for vaguely described setups. I do not think this is fair. And I am rather grateful, somebody like Fritz is contributing here. And I'd prefer to not see him scared away (even though I know, Fritz is not that easily scared). I think, he deserves a friendly and civilized tone (which, I admit, your second post shows much better). In my experience shouting rarely leads to progress.

Maybe just for future readers finding themselves in similar situation, would you like to tell us, what the issue was?

Pretty sure, Maxon is aware of this as well. My current workaround is to use the node parameters in Attribute Manager. On those you have the "Help..." in context menu and for most nodes it gets you where you want or at least close to it. Also not perfect, yet (and no doubt, some on this forum will find harsher words), but I have no reason to believe, Maxon won't get there.

Probably not the best idea to post the same question twice in different threads. Hell, I was confused. I had just answered the question. Then looked at this thread and my answer was gone!!! Don't do that to me! I'm getting older. Do you know, how it feels, to think you have only imagined, what you did five minutes ago? It's already hard to forget things from a year ago or a bunch of month ago. But one gets used to it. But five minutes??? That's close to brain flatline! Anyway, I answered over there:

Hm, I agree, the docs on these topics are not on the level we are used to (certain nodes missing, other things not correct and certainly a lot of context and glue missing, also more examples would be great). But to say, there's no documentation isn't correct, either. Nodes descriptions: https://help.maxon.net/c4d/en-us/#html/60629.html?TocPath=Node%20Editor%7CIndividual%20Assets%7C_____0 Capsules: https://help.maxon.net/c4d/en-us/#html/Capsules.html?TocPath=Node%20Editor%7C_____7 In order to defend Maxon a bit, Scene Nodes mean a paradigm change. Before the documentation department had to understand C4D just like every user does, in order to document it. Now, they need a certain amount of developer/programming knowledge, in order to get the job done. Please note, I'm not saying such knowledge will be needed to use Scene Nodes (though in its current state it certainly helps), but it's needed to come up with a sensible, useful documentation and also examples. Such knowledge needs time to to build up. Whoever had to build up knowledge on a job in parallel to coping with the usual workload and delivering the usual output, maybe knows how hard and slow that can be. But I think, Maxon is aware of these problems. And from the open positions on their site, I'd guess, by now they have also hired somebody to help in this regard. Some time ago I saw an open position in this realm, which by now is no longer offered. So, I'd expect the situation to improve.

This morning, I reported to Maxon, that the screenshots in English documentation have the wrong language. And by now, it's fixed 🙂 Thanks, Maxon!

Sure. Check the buttons on the top right of the Attribute Manager: So, the rightmost pops up a new one. The freshly opened one will be locked to the current element. So you will want to unlock the lock. Then switch to Nodes mode via the menu and lock the mode. Done. Dock it where ever you like and save the layout. Here's Maxon's documentation on the Attribute Manager. Unfortunately they currently seem to have an issue, as it's showing German screenshots for the English version. But you can switch the docs to the R25 version, there it's still showing the English screenshots. Pretty sure, Maxon will fix this rather sooner than later for S26.

Not sure, if this falls into the "how it's done today" or the "3D software" category, cause for most of us it's probably out of reach... but Weta's Manuka with its spectral rendering should be well capable of such effects: https://www.wetafx.co.nz/research-and-tech/technology/manuka/ https://www.fxguide.com/fxfeatured/manuka-weta-digitals-new-renderer/ The linked article also mentions Maxwell to be capable of some sort of spectral rendering. A name I haven't heard for a long time... though that article is also quite old by now.

I wouldn't be surprised at all, if some Maxon historian would find out, those ten years would match the start of the development of a new core. I wouldn't even be surprised if it started even before, without anybody noticing any slowdowns at the beginning. And I wouldn't consider it slow or long (not sure, it's worth searching, in some other thread some time ago, I laid out my reasoning). For me it is virtually a law of nature, that development gets slower and slower, the larger and more complex a project gets. It is almost inevitable in a real world. Of course there are professors at university, who never developed or managed a project themselves, who can teach about ideal approaches and perfect execution, which in theory can provide a constant development speed. Yet, I need to see some proof such really exists for projects older than thirty years (which C4D I think is by now). Adding on top the absolute gigantic task to introduce a new core within a living and breathing environment without breaking too much compatibility (see for example how much shit got poured over them for only breaking relatively minor things), it is enormous beyond believe. And sure, the real world has more candy in its bag for projects like this. Management changes, company mergers, the general need to grow, none of this improves productivity. At least not for a considerable amount of years. Do not get me wrong, I am not judging Maxon's new management here, these again are more or less universal rules you can witness in almost every company going through similar processes.

Actually I will not discuss Blender, as I simply know too little about it or its development cycle. And I regard it as a feature, if people who do not know, simply keep their mouth shut. So I will do so, instead of talking rubbish about Blender. I am not here to defend Maxon's development speed. I do only try to explain some of the complexities involved, which seem to be mainly overlooked. Neither do I even want to be drawn into this dreaded my d#*k is bigger than yours Kindergarten discussion. I simply do not care, if anybody likes C4D or Blender better. The grass is always greener on the other side in my experience. And to be honest, I also do not get the point. It's almost as if we are back in the middle ages. "You do not believe in my god, well, fine, but sorry, then I will need to chop your head off!". What's the point in trying to convince anybody, that it's better on the other side? Aren't we all grown ups? Can't we determine our needs ourselves? And based on these needs, can't we then decide for ourselves which product to use? Do you work better in Blender, if I used Blender as well? I doubt it. I do like product comparisons, but frankly I do skip all these Blender does this, Blender does that posts, popping up in virtually every thread by now. I am certainly not denying some awesome features in Blender. Really nice. Awesome stuff. Enjoy. But why do I need to enjoy and praise it as well? Back to development speed. I know for example a bit more about the Linux development. Equally an open source development, obviously. By now probably fifteen or twenty years ago I had a small discussion at HMI (Hannover Industry Fair) with Greg Kroah-Hartman (one of Linux kernel maintainers, back then more responsible for their USB stack). He boasted about a million lines of code changed per month (roughly, the exact figures are not that important) in the Linux Kernel. Being asked, how they keep up with testing such things, he openly replied, they don't and they do not care. They simply use their large user base as test bed and then iterate to a working version (my words and a lot has changed inside the Linux community since then, we do not need to discuss the details). Unfortunately for me, working for a small company which produced hardware in small series (maybe hundred or a few hundred devices), this approach was absolutely no option. Actually it is no option for anybody working in security relevant areas. Even if modern hipsters seem to have forgotten this fact (driving Tesla, anyone?). The bottom line is, you can speed up development in a lot of different ways. Maxon wouldn't be known to provide one of the most stable for many, many years most backward compatible DCC, if they hadn't used theirs. Are there faster ways to develop? Sure, tons of different ones. But each and every one of these comes with downsides in other areas. In a way Maxon is paying heavily for their chosen way by taking a beating from their community for things nowadays, the community actually praised for many years. And before this escalates: I am not trying to defend Maxon here, either. Only stating, what I see as facts.

In regards to engineering scenarios Dilbert is almost always right. Good source, to get an idea of real life in software development. And there remains also the point I mentioned at the end of the Simple Features paragraph of my monster post, the problem of time slots and when you need the externals again. I know, you wanted to address this by temporarily disabling such features. But a) I'm not sure, the community would be very tolerant in this regard. And b) this problem would get worse and worse. The more of such plugins you have, the more needed to be updated for the next release. And the externals are usually pretty busy themselves during this time, getting all their own projects in shape and keeping their other customers happy. Uh oh, I feel, this post again gets longer... There's another notion to the problem here. Not unsolvable, but still. Nowadays, a company will usually have some automated build process, which usually also includes automated test procedures. And usually one wants to get stuff popping up in such tests to be solved rather quickly, so new problems do not get lost in a plethora of other error reports. Maybe there are even established rules, that only builds which have passed all tests, can be passed to beta testers. As I said, all this could surely be solved, by adapting your build procedures or the possibility to filter certain module from the results. But then you may run into new problems, because you can rest assured, such filter would quickly be used for other things as well and rather sooner than later you realize at your release date, that some important module was ignored by all safety measures for quite some time and now it's not working in your release candidate... It's all just not that simpel. And I think the better way, and I know, Maxon did so in the past, it is better to hire developers of relevant external components. So they can build up the knowledge needed to make the former plugin a true component (and yes, even for good plugins, there's still a difference and some work to do) and from then on also can provide the needed work. Good thing in this scenario is, the developer will not be 100% busy with the maintenance work on the former plugin and you gain some extra development resource for other stuff. And yes, sorry for not quoting or addressing you, HappyPolygon. Would have been a good idea. To my excuse, when I started writing my post, your question was the last post in the thread. When I finished writing, it was unfortunately no longer the case...

I agree. I also find Maxon's UI decision here a bit questionable. But isn't this something, easily fixed by a custom layout? Is there anything else needed, than popping up another Attribute Manager, docking it next to the Node Editor and locking its mode to Nodes? Of course this wouldn't solve any of the other valid points mentioned.

I apologize for having written too many words. I'm sorry, I even seem to have put your brain integrity at risk. I was actually answering a question somebody asked. Also trying to correct some of the profound misunderstandings of development processes existing in this forum (explicitly not addressing you HappyPolygon, you asked). Next time I will of course invest another hour to work on the presentation. Or wait, maybe, I will instead rather not post at all. You will not have to bear such post again.

I have some doubts this can be a general strategy. Even worse, I'd say, it's probably a good way to get you into deep trouble. My main argument would be code tending to rot. My second argument would be the time needed to get developers up to speed. But lets sort it a bit and split it in maybe three parts. The simple case, Capsules and Assets Capsules are isolated entities and they are not even code. They are Scene Nodes setups. Lets say more generally they are assets, just like maybe object or material assets. But in this special case they are assets built upon a system which is still in flux. Take the examples Maxon released with their first release of Scene Nodes. Multiple of them stopped working in the next major release of C4D, simply due to partly minimal changes in Scene Nodes. To stay on top of such things can take a significant amount of manpower. Actually in two or three ways. You need people test all the assets. You need people to adapt and fix assets. And on the other side one also would want the Scene Nodes development to pay attention to changes and reduce the amount of havoc caused in the first place. Staying compatible is a major undertaking. It's one of the reasons, I think, C4D's development slowed down so much over the years. And it's probably also the reason, Maxon still calls Scene Nodes a tech demo. Because despite all planning in the world, in projects complex like this, there will eventually come the point, where you realize, compatibility is not an option, if one does not want to sacrifice too much potential. But ok, so, that's still the easy part. Yet, my prediction is Rocket Lasso will most likely need to come back to those capsules in order to adapt to things happening in Scene Nodes in future releases. Features delivered by code Now, lets look at actual coding. And here I'd like to split into isolated features (which in most cases also means rather small features) and more complex deeply integrated features. In first category lets say we have a simple Cube generator object. In the latter we have something like a particle system. More important for my point, in the first case (Cube) we have rather little and probably also easy to understand code. In the second case already the amount of code will have risen, as well as the complexity thereof. Either can obviously be done as plugin (as both such plugins exist), so you may expect them to be isolated enough to be done by outsiders. Simple Features Well, I'd say, in the first case (cube) maybe. But keep in mind, Maxon is working on a new core. Stuff does not only need to be touched, if you want to extend it. It also needs to be touched, if the surrounding ecosystem changes. I have read so many times on this very forum "Now Maxon has released the new core, why is stuff still slow?", "Now there is the new code, from now on all development is a piece of cake and will be much faster" (rephrased and over simplified). But that's not how software or its development works. Stuff needs to make use of the new core and this does not happen just like so or by soothingly talking to a feature, trying to convince it to simply expose the power now available the new core. In fact all stuff needs to be adapted. And this is hard work. In many cases, stuff is probably easier to rewrite from scratch, than trying to massage an existing code base into a new environment. But rewriting from scratch also means risking compatibility. For some unknown reason (probably it will need multiple generations of software development scientists to figure out the secret behind this), users tend to like those features best, which were never planned or developed to work like so. It was rather a happy accident, the feature developed turned out to work also in a rather peculiar way or context. And users are really good in finding such peculiar ways and stick to them (and why shouldn't they? If it works, nice). But when rewriting a feature you can not only take some original specification and simply set it as a goal. No, you need to find out about all those shortcuts and peculiarities, users came to love, and the sum of all that is now your new specification... And similar to Scene Nodes, such a "new core" is also a living thing and moving target (or rather moving foundation). Listen to plugin developers. How happy they are, they need to touch their plugins with almost every release, currently. Back to my Cube example and relatively little and simple code, where you can probably assign an arbitrary developer to the task to adapt it to changes. But still, the developer will need extra time to understand first. You need testers and QA to make sure, everything's still working as expected. For a Cube probably still manageable. But the amount of time and effort needed is already more than would be needed, if the original developer could do it her- or himself. But it also needs to be done in a certain time slot within the development process and release cycle. The original developer may not even be available during that time. Externals do not sit around and wait for you to come with an emergency request, because eight weeks before release somebody in QA or QC realizes some of the changes done elsewhere unfortunately also broke the Cube... Oh boy, sorry folks, this gets way longer than I had planned... Complex Features Last category is the particle system example. Of course all of the above applies to this as well, multiple times worse of course. But it is even worse worse. Worser worse, I'd say. Already the development of such a feature is a completely different beast. Not only because more code needs to be written. Not only because this code will also be more complex. But the number of "contact points", of stuff to interact with, rises a lot. You do not only want your particles to interact with other particles. You want them to interact with objects. With splines. With hair. Maybe with volumes. Maybe with Fields. Certainly with animated systems. Materials should probably be able to pick up information from particles. And so on and on and on andonandon... So, here you do not need some arbitrary programming guy to implement it, but you need somebody with some deeper understanding of the entire application (from user's perspective as well as from a development/code point of view) in order to pull off the feature in a neat way in first place. Developers from the street usually do not have such. And it really takes time to build up such experience. Not only time for this single developer, but the developer will ask questions to the developers sitting around... And if such knowledge got built up, I'd already say, it's highly questionable, if you want to see someone like this leave after a single project. Because getting the developer up to speed was such a high investment. And then chances for such feature to break by external changes (external to the feature, I mean) is A LOT higher. The number of possible implications to understand is dimensions larger. And chances to break the tail by fixing the nose rise immensely. The time need for any adaptions/fixes is also higher. Reducing chances to meet a suitable time slot with some external you'd like to re-hire, even further. But still not done... I promise, I'll come to an end, regardless of how much I forgot to mention, while writing this. Would probably be good to plan such posts beforehand. I apologize! Beethoven vs. Cheetah Finally, code is not like code. In my point of view, you can very well compare it to human languages or music and maybe crafted art like symphonies, poems or paintings (eh, by no means anybody should compare any code I have ever written to a beautiful symphony. That's not what I wanted to imply. Cacophony would probably match my code better). Code always contains patterns of the brain, which created it. I think, this is also one reason, why so many developers shy away from showing code to others or get mad, if somebody touches their own creations. In a way you reveal your way of thinking. And for most of us developers (except any developer reading these lines, of course, or except those few geniuses, who somehow were gifted by their genes) this also means showing to the world how utterly stupid we are. But for the point I'm trying to drive home here, this also means, it is not always easy to get into another ones thinking. And applying changes to such an building of thoughts, is very often like some ape trying to beautify the Mona Lisa. Nothing against apes. I really like you tree hugging, banana eating monsters. The ape can hold a brush, but chances that the majority of spectators will find the result any more pleasing, are rather low [Edit, what I actually wanted to say: You could let Bach, Brahms or Vivaldi finish a Beethoven symphony, chances that the result will still sound like Beethoven are minimal]. Same with code. And the building of thoughts gets more complex with every iteration, because the new dev didn't know about or see that nice shortcutting backdoor, which would have made the change rather simple. Instead he bought a bunch of wood and dangled a new staircase and an entire level of own thoughts on top of the building... and this is another reason, why code rots. Again, I apologize for being carried away. I certainly lost three or five points, I wanted to additionally mention, why it is in most cases a bad idea to just buy a piece of code or temporarily hire some externals. Yet, I hope you at least got an idea, why it is maybe not the best idea. And maybe not as productive as one might think. Edit: Oh my, briefly read over this post. Half of it are not even sentences... 😞 Maybe I'll proof read and correct tomorrow. Sorry! Edit 2: Fixed a bunch of typos and corrected some sentences, added headings. Deliberately did not change the "wall of text". a) For lack of time reasons and b) because maybe this topic should only be read by people willing to invest a thought.

Oh, looks nice. I will definitely put it on my list. So, thanks in return.

I am with the one sub at a time faction. Maybe more into the more niche stuff, but as I haven't seen some of my personal highlights mentioned (which doesn't mean I want to discredit any of the mentioned ones, nice choices so far), I thought I'd throw some into the discussion: For those who can bear (or, as me, indulge) the peculiarities of South Korean productions, I'd say "Hellbound" is worth a look (though the CG is maybe not the best). I recently discussed with a friend and he rated it above Squid Game (which should also be a warning to the faint hearted). For those who are not rejected by David Lynch (Eraserhead, anyone?), "Brand New Cherry Flavor" has some similar vibes (though it would probably be blasphemy to compare it directly to the master). For the nerds: "Truth Seekers" and "Dead Pixels" can be fun. Productions from Scandinavia rarely let me down: "Magnus" or "Beforeigners" (the latter in Germany still for free in ARD Mediathek). Some nice spy stuff: "Counterpart" (I mean, come on, is there a way to not like J.K. Simmons? And here there's two of him...) or "Patriot". As you were in Apple+: I liked the first season of "For All Mankind" a lot. While I am mostly too old for coming of age stuff, I found "I Am Not Okay With This" had a nice approach to the super hero genre. And for those who understand German (or rather Austrian) I definitely recommend all the works from David Schalko: "Altes Geld" or "M - Eine Stadt sucht einen Mörder" are good starting points, I'd say. For the younger peeps, dare something: "The Avengers", started 1961 and it never gets old, even after watching it so many times. The Emma Peel seasons really aged well. Sorry, I couldn't resist. And the older I get, the more I need to tell me, that older doesn't mean worse necessarily... And speaking of old (well, not that old), my all time most funny comedy: British series "Coupling" by Steven "Dr. Who" Moffat. Yes, it's a sitcom. Yes, it has a laughter track. And yes, it is all about sex and relationships. But it just hilarious in so many ways. Oh, right, I am not too much into historic themes. I need to run, when my wife starts with "Downton Abbey", but "The Great" was exceptional for me. Ok, I shut up now. Seeing this list, I probably watch too much crap...