Leaderboard

C4D was the only DCC that was able to do this. And it required such careful planning to ensure that this was the case. And the users never truly appreciated this until it was gone. But this had to happen, IE they couldn't just keep building on the old core and needed to improve everything under the hood, meaning massive API changes. We all had a good run during that time. But since R20 I now ship a separately compiled plugin for every individual release. Updating a plugin for C4D now means I build from R20 to S26 on both mac and pc. That's 14 different versions of every single plugin. This is just the way it has to be now. So also spare a thought for the plugin developers out there. Anytime a new version of C4D comes out everyone still expects these free updates, because before there was zero work involved, ie the plugin just ran. Now they have to build, test and ship a separate version for each one. Sometimes you get lucky and can run a plugin in a new build, but plugin developers can't rely on luck and should just build a separate one anyway. What is absolutely incredible, and people often don't think about this, is that they managed to change out everything in C4D but still managed to make all previous scenes still work. How they were able to swap out the entire underlying core system and still ship C4D to everyone is no easy feat.

In passing, I want to apologise to Might as at least one genuine comment has conveyed something which wasn't intended. I have had a long work week and have been genuinely a bit tired here and there. When I wrote earlier that his post made my brain hurt, it was true but this was not his fault. Any long post on any subject would have likely done the same. Might's post looked interesting but beyond my mental energy that day. This is the reason I could not get more than a few sentences in. My brain said 'not tonight, you need a rest and maybe a good dinner or medicine or something'. And yet I do have the energy to skulk around and post other things here and there, go figure. I enjoy posts investigating or celebrating C4D stuff, and also development discussion like Might offered, but my brain wasn't up to absorbing the info that night. In future I'll phrase things differently so that it can't be misconstrued. By all accounts he offered an interesting post (and the few sentences I read looked interesting before I stopped) but the failure to finish was my fault, not his. Sorry 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.

Useful overview. This guy has probably the best C4D modeling channel on Youtube right now.

This is incredibly short sighted. Implementing ZRemesher as a modifier that can make it part of a procedural stack opens up many workflows. Just a couple of examples: Generating appropriately tessellated procedural text (which is still editable) templates for dynamics sims Creating multi-resolution meshes for cloth sims which can be quickly adjusted to optimize simulation quality and results It can still be used in a non-procedural way if you want. And Zremesher does not work well above poly counts of a million or so, so stacking it with a poly reduction modifier, etc., would be an incredibly flexible workflow to dial in an appropriate mesh without the PIA of the command-undo loop...

Hello, The UV projections occupied my mind for quite a while, I made some tools to unwrap them, to make the edition easily, add features to BP UV Edit... But the problem was still the same, the UV edition is still boring to do and quite often we prefere to use the common automatic projections when it's possible. I was wondering, could we simply make other kind of projections to fit more shapes ? So I came up with a new plugin, the UV Projector ! It works like a deformer object and only edit the UVW property, it have some interesting new UV projections with the advantage to not have to make the object editable ! Here is some new projections : Rhombicuboctahedral : It's like a cubic projection with the 45° edges. Cylinder with deformations : Like the classic cylinder, with deformations to adjust the shapes. Half-cylinder : Some times you want to have only one side round and the other side plane. Y shape : It's maybe still a bit wobbly to setup but it gives a nice start. The last is I think the most interesting, it's a plane shape with editing points : Simply uset he point mode to move the surfaces points and adjust them to your object, you can literraly wrap it around your object ! All the features and download here : https://code.vonc.fr/projecteur-uv The free version is limited to 1000 polygons count with all the features so you can still enjoy it. The plugin is a part of the Vonc Suite that contains others tools. If you have other projections shapes ideas don't hesitate !

Another relevant Dilbert from 20 years ago.

...or hide bones/joints in whole mixamo rig (selecting by "none")

I fear you overestimate the pool of developers outside of Maxon that could fill this role. Of those that left Maxon in recent years (recent enoguh so their experience makes this work) most have switched to different fields and are usually quite busy in their new jobs. Those that continue to develop for Cinema 4D do so because they want to work on their own terms, not as de facto employees. Also the devs are only one part of the whole thing, UX, QA, Documentation, PM, ... are all involved in different stages and the whole process works much better in house than partially externalized. As much as we like to stay in contact and work with ex Maxonians, they are not a drop in replacement for in house people.

Interesting. I never knew the origin. It seldom surprises me when dev branches converge back to the same source. Sorry. I was late to the party and didn't read enough posts backwards. I get it now. This is a "you could already do this with plugins" argument. +1 to don't care. I'd rather good plugins become native. I've been burned by too many developers that abandoned their work. I've been very slow to adopt 3rd party plugin solutions at this point for that very reason. EDIT: I should also mention... the labor involved in supporting a piece of software is a burden I would never wish on a single human being (or even a small team). Its much easier for a large company to bear that weight when it can distribute resources from several departments. I'm not sure everybody can appreciate what it takes to just keep things working year after year.

Hello, Here is a new projection UV added to the plugin, the Radial projection allows to unwrap along an arc like this : Have fun with the UV ! 😉 https://code.vonc.fr/projecteur-uv

Adobe has unveiled Substance 3D Designer 12.1, the latest version of its material-authoring software, introducing support for importing and exporting 3D assets in USD format. The update also adds tools throughout the Substance material graph, including a new toolset for generating 3D textures, and new 2D and 3D noises; plus a draped fabric mesh for 3D previews of cloth materials. https://substance3d.adobe.com/documentation/sddoc/version-12-1-225972219.html

Oh I thought the new standard material was locked to the new node system, thanks for clarifying that it works with the xpresso interface. This pretty much solves all my questions for now 🙂

As said any renderer that supports volumetric caustics and dispersion should be able to do that, no need for spectral renderer 😉 Even biased renderer can produce that effect, this was done many years ago on an old version of Vray using the biased engine and it's pretty accurate, this is the scientific test I've used for reference: https://sciencing.com/happens-light-passes-through-prism-8557530.html

Ice, regarding the live ability of the remesher, keep in mind there are always going to be a million uses for a tool outside of its intended scope, given that a major selling point of c4d is how most tools remain parametric until flattened, it makes no sense to treat remeshing any differently, Otherwise you could say the exact same thing about polygon reduction and other one-off tools where they're mostly used to create a new mesh. Both have the opportunity to slow down c4d, but both can do some cool stuff when settings are animated or used outside the box of normal usage. not a direct example, but using features in unintended ways is what gives rise to interesting visuals like these; a lidar scanner is for grabbing a single scan of a 3d object right?... unless you leave it live and running to make a music video... Video projectors are intended to project on to static flat surfaces right? unless you keep the surface moving and end up with: Or leave a polygon reduction object live...

I feel you. But if you choose the following settings, it is almost as minimal. After that, just right-click and "extract to <folder>"... You'll never have to see the actual app again...

Don't forget good old Filterforge. Another one that was ahead of everybody else but missed the jump into the 3D Texturing world

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...

Just hide the joints in the object manager...

Could not be hidden joints itself?

In my defence I was young and naive believing it would end the nagging advertisements ... The trust i had in companies, it was bliss

I found your description about the coding process and what it involves extremely interesting. Thanks. Keep writing interesting stuff 🙂

Hi Marcio! Thanks for your feedback. We are working on the fixes you mentioned and the Maya integration is coming very soon 🙂

You were pretty much spot on in every aspect.

What I was getting at is that it didn't go the way of Lightwave. They didn't just abandon C4D as it is and start on a new product from scratch with zero features. We all still got to use C4D while the engine was being replaced underneath. The performance that you are wanting to see is probably specific to some use cases, possibly the hundreds of thousands of objects in a scene issue? Which is being addressed by the work on the scene nodes. There have been lots of improvements throughout C4D, but you can't suddenly give everyone their specific speed increase. I guess I sit from the perspective of a developer who knows how hard this stuff is and there is nothing you can do to speed up development. People talk about hiring more developers, but that doesn't get the work done any faster, in fact it slows it down. C4D as I see it is a tool box of so many different workflows. You can't please everyone with every release. And just to second what Fritz just said... if you have a scene that is slow, send it to them. Or even post it up here so we can look at it. Could be something that could be solved with a different approach using a more optimized path. Or it could in fact be something that Maxon needs to know about so they can profile it to see what the culprit is.

Make up your mind. You keep saying they’re not doing things people are asking for, then finish by telling us they just did. You also tell us no-one has asked for any of the features they’ve done recently. Pretty much every feature they’ve brought out - character stuff, animation changes, whatever - has been applauded by someone, even if it’s just random dudes on Twitter surprised how much they like seeing Magic Bullet in there. So I don’t know how some people equals no one. But if you’re not a programmer you can clarify then why you see their comments about core development slowing things is an ‘excuse’, rather than an obvious statement of the truth. It’s either true or it isn’t. I do agree they need to speed up general performance though as you’re not the only one who has mentioned being frustrated with that side of things.

I thought the new core did let them just add a bunch of needed features. If someone thinks all the other remaining long-awaited features would have worked on the old core rather than the new one, they should write up a technical report explaining how and send it to Maxon.

I automatically block out any adverts on web pages 😉 If you would ask me right now, the only one I recall on Core4D is the red tinted advert with the cars and traffic. But I wouldn't have the faintest what it is called, though 🙂

Totally agree with you. I'm very critical of the current Maxon administration but I didn't really understand that complaint. It's AWESOME when the user needs less plugins in Cinema 4D. One of the main problems of C4D right now is that it's a very expensive software that needs tons of plugins to have the same features of other big DCCs suuch as Maya and 3ds Max. So yeah, I think we all wish Maxon would integrate X-particle, RealFlow,, RizomUV, and other plugins into Cinema4D. Getting Zremesher is a good start - and it's also good for Zbrush users. It signals that Maxon will transfer Zbrush technology to C4D without destroying Zbrush.

I also see the mention of plug-in alternatives and kind of go, "Yeah, so...?" There are plug-ins for all sorts of bits and pieces that C4D doesn't have, including the already mentioned fluids, particles, and other stuff. Big shrug. I'd prefer them all native, and suspect that eventually (it'll probably be a while with the fluids) we'll get them. ICM does make a fair point about the plug-ins offering alternatives and that will suit some, all good, but it doesn't suit me. I honestly prefer the neatness of having the one app, the one manual., the one variety of reliable sources for tutorials, you get it, you've got it, you own it. And yeah I do phrase the subscription C4D as being something I 'own'. The food I buy which goes into the fridge is usually digested and down the drain a few weeks later but it's mine and nobody else's. C4D is cheaper than my grocery bill and I spend more time in front of it than I do sitting at the table eating. That noted I'll probably also get Houdini later this year as the Apple Silicon version is in Beta. That will give me two programs to chip away at. This might provide some comical observations as I compare which one is easier to use than the other. Slightly off topic but it will be funny to see what R27 holds in September as Rick or someone mentioned that (a) it's obviously a shorter development cycle, and (b) staff in Germany get a long Summer holiday (some guy on Reddit posted a rant on the C4D page, 'no one gets holidays as long as those guys do'). I'm jealous and would like to move there.

Looks like a really great update. Congrats to the team and everyone involved with this release.

I wonder if it is common practice for big DCC companies to "borough" developers from other smaller firms to develop features. I know this is very common for general IT companies. Take for example Rocket Lasso's team developing Capsules for Maxon. I think it's kinda more of a win-win situation. Maxon hires company with experienced developers for X feature for Y time, pays them for RnD, and compensates with a funding for 2-3 years after the feature has been released (bugs and profits from the feature). Next time Maxon wants to update/expand that feature rehires them. This way more plugins become part of C4D, C4D gets more competitive, more people buy it and C4D keeps the price constant.

I think you're the only guy in the planet that actually paid for WinZip! 😁

This looks really good. The NPR material is particularly useful for my projects. Congratulations with this new version! Is there any fixes for the Motion Blur and transparency issues of the last versions? Also, any news about the Maya version?

Both are developed by the same person. Q seems to do a better job with poles, I've read. *Edit* see his FAQ: https://exoside.com/quadremesher/quadremesher-and-cinema4d/ So Zremesher in C4d is actually QuadRemesher.

Thats the problem with Octane. If youre happy with its render speed, visual style, and how quickly you can work up materials and lighting, then anything else is going to be a bit of a letdown. Arnold is far more stable and has some more complete and production ready features, but the work done with it is dominated by those using cpu-based farms. Redshift gpu in my experience simply isn't faster to render than Octane. It is better at doing quick cheats like simple fog vs octanes mega slow volume mediums, and faint transparent objects struggle less in RS than Octane, but Redshift completely falls apart on any system with more than 3-4 gpus. 12 gpus in octane is 12 times faster. 12 gpus in redshift... a) it doesnt support 12 gpus, b) of the 8 gpus it does support, it will only be 4 times faster So its fine on a workstation, but rendering anything serious with it gets quite annoying because you end up needing multiple weak nodes instead of having a small number of powerful machines.

Action, Adventure, Sci-Fi Storyline: In Moonfall, a mysterious force knocks the Moon from its orbit around Earth and sends it hurtling on a collision course with life as we know it. With mere weeks before impact and the world on the brink of annihilation, NASA executive and former astronaut Jo Fowler is convinced she has the key to saving us all - but only one astronaut from her past, Brian Harper and a conspiracy theorist K.C. Houseman believe her. These unlikely heroes will mount an impossible last-ditch mission into space, leaving behind everyone they love, only to find that they just might have prepared for the wrong mission Personal note: The movie wasn't good bat it did have some chilling moments.

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.