Leaderboard

The more I see demoed of S 26, the more impressed I am. I’ve got to be honest, the new release of u-render Really made a difference for me. They’re most recent social post showed that Maya and a Mac version of the Cinema 4D plug-in are not far behind. For my day job, I don’t always do graphic work. But this might be another little way into it. The modeling features really do impress me. The capsules are starting to show just how handy everything is. Whoever thought of that is a genius. i’ve been researching blender a lot and while it is impressive, I just love the way Cinema 4D works. That’s worth something. As is the c4d navigation that seems to work with my hand limitations. I’m excited about cinema 4d again. Looking back at old releases, I realize now that I often don’t quite get a new feature and that I need to give it time to marinate. S26 came out swinging with some flashy updated and new features. But those smaller ones really show some thoughtfulness. Some of the really cool tiny features end up being a bigger deal than I thought. That’s what I like about Cinema 4D. Everything just works together so well. Watching polygon pen on YouTube Use some of the new modeling features really drove it home for me. This is a guy who’s great at modeling and is very excited. And now I am too!

Ditto here with fields - took me much longer than I thought it would to fully appreciate those, and still not sure I do fully, in all aspects ! Sub-fields still confuse me 🙂 The new 25 UI led to about a month of uncertainty and looking for stuff which wasn't where it used to be, but I am already beginning to forget that time, and get back to being suitably zippy in the newer versions. And now with all these new modelling tools in 26 I would find it very hard to go backwards now... CBR

There have been tons of updates to the Dope Sheet & many other aspects of animation & character animation over the last 5 releases. It's a pretty good example of the continued development that some people claim Maxon doesn't do (and to be fair, they sometimes don't do)

oh wow it's actually that! thanks so much.

Isn't there a tag new to r25 that deals specifically with this requirement... "Track modifier tag"?

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.

On occassion - but I don't like the computer beating me LOL!

Whole Maxon set of figures has 3331 points in all. I think it´s just maybe a quarter of Jay´s knight 🙂, but sure, Jay´s modeling skills are awesome...

Top job Cerbera. Those models look superb. I really think you ought to get Maxon to replace the current set with yours : ) Open negotiations!

I'm sure Maxon will get to all the areas eventually. It looks like some might take longer than others though. The guy above who did the Redshift wax textures video has just done another nice one on textiles and fabrics. He's really cranking them out.

The „Select Facing“ capsule might do what you need

You can make selections based on Normals, and convert those to tags, but there is no way to do it directly that I know of.

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.

Has been a while since I knocked out a chess set, and, in the same way that it's good to watch Lord of the Rings again every so often, did one over the weekend... Here's the most interesting 3 models.... bishop was retopo job, which produced much nicer topology and lump-free SDS surfacing than merely trying to clear up after a boolean... Still don't like the mane on the little horsey guy, but haven't done any sculpting on this yet, which may yet tie it all together nicely... ...and if we want nice sharp corners on our Rook crennellations and must maintain perfect rounding radially we need many more segments than we'd first think so that we can achieve this with poly density rather than control loops ! I feel I should render them 200 ft tall in some ancient roman coliseum or somthing 🙂 Anyway, great fun to model, as these things always are ! CBR