Time for Maxon to Clean house?


in new versions, they highlight new stuff in yellow. Perhaps using the same concept, they could highlight old crap that you should avoid like the plague, in red? stuff that you have never used, and is destined for the trash. It could also remove menu items to a vast bucket menu of things you never use, until you are left with nothing but a cube,a sphere, checkerboard shader, lensflare light and the render button (which should be bigger,red and flash animated)


The ability to rotate and tilt the HDRI, like in Octane (and not fiddling with elements in the scene) . The ability to alter the exposure, hue, saturation and contrast. Keyshot has the ability to scale the HDR, and edit it within the app, to blur it and adding lights or block hotspots. It may sound minor but once you’ve used the other systems, C4D’s seems positively clumsy and archaic.

Don’t get me wrong, I love C4D. But it just feels like it could do with a spring clean!

(Paul, don’t get snarky. I don’t see how my comment warranted that response).


Your reply got me scratching my head…

I don’t use HDRIs often (just the normal .jpg in the luminance channel + GI gets the same effect)…

But I just opened an .hdr to make sure if these things can be done …


Isn’t this the same thing ? (I have never worked with Octane).
The exposure can be adjusted in the image settings allong with white and black points …


Didn’t say they couldn’t, just that it’s easier/less fiddly in other apps/plugins. I mean, how many clicks is that to set up?

I’m just suggesting an HDRI Object with all that functionality built in and easily accessible. Anyway, this is veering off-topic and I weirdly feel ike I’m incurring the wrath of the Denizens of the Internet for having an opinion. So I’m out.


The cloth might not work well with character animation but is much better at least than 3Ds Max for tearing.


I’m not so sure - as long as there’s decent replacements it makes sense to let people know what’s being removed, and it gives users confidence that old scenes will be valid even if the feature gets updated. Adobe has an ‘obsolete’ folder, and SideFX marks some stuff as deprecated, so it’s not some crazy idea I just came up with :wink:


Creative Destruction. It’s necessary.

If one is adding lots of new features you need to start removing old ones. Otherwise you have a packrat situation And a software package that doesn’t feel modern.

BTW…Demis…so you know…a JPG inherently is not true HDRI. JPGs can only be 8 bit. You want 32 bit color data minimum for using as HDRI environment.

File formats that support high dynamic range are .exr, tif, .hdr, radiance.

With only 8 bit JPGs will max out at 11 stops (if that) and can also engender noise in renders.


I strongly believe Maxon’s radiance materials upgrade a few years ago failed (as far as usability) because it tried too hard to be backwards compatible.

They kept all the old channels and built a whole new system inside one of those channels. (Reflectance)

Overall I really believe Maxon is headed in the right direction w/the new core and the acquisition of Redshift. But w/the arrival of all the new they need to make hard decisions about legacy stuff.

And soon enough they’ll need to decide about keeping ProRender in the program…or relegating it somehow so it doesn’t crowd the interface.

Finally…I for one do motion tracking and even though I have SynthEyes, I welcome on-board scene and object tracking. That module is modern and useful for those needing to track.


Cineman (Renderman to C4D bridge) was removed. So it happens sometime.

Motion tracker, while unexpected, is actually EXCELLENT !


I guess you see the new core in things like Volumes and Multi Instances which are both awesome.

C4D lacks so hard in areas like liquids, fluids, cloth and particles that I hope the new leadership continues with acquiring external tools.


Darth_Mole, I don’t think anyone was mad at you (at all). People just have different opinions.


They should hire Tyson Ibele that is making on his own TyFlow a replacement for 3DsMax Particle Flow: Dynamics, Cloth, Sand etc… in an unified environment. Just see this:



Sometimes i wonder how one person can do so much and a legion of coders in a company can do so little.

He uses PhysX from Nvidia for rigidbodies


B2…some individuals are intellectual juggernauts that accomplish what entire companies can never achieve. It appears that well before he developed TyFlow he was building Max plugins that crushed what AutoDesk’s team were designing.

That guy’s work is obviously stupendous. And what I like is that its all done on the GPU. The speed!

Maxon and Insydium seriously need to get on the GPU bus for simulations.


We’ve got a surprising amount of use out of it, doing mainly post-vis.
While no doubt a specialised solution can go further, the fact that every artist has Cinema installed means they can all do tracking in a pinch & don’t have to learn a new program.
I am a bit concerned about a few things though. Maxon seem to have poured a lot of resources into Pro-Render integration & so far, it’s still far from a real option for most people, I think.
Likewise they’ve made a great node system, that’s still tied to Standard, Physical & Pro-Render, none of which can really do it justice. Hopefully they open it up to 3rd party renderers & I’d like to see it become the basis for XPresso & other node-based stuff. Because when I do still use Standard or Physical, it’s not to make complex node-based materials with PBR. They can’t render that stuff in a timely fashion anyway.


This whole thread is not looking at things the right way.

The issue with ditching anything… is you might NEED to open a project from 2010 like I just have today and it still works.

My question would be does a feature in a menu take up system resources? Or are they only loaded into memory when selected?

The other problem here is we all have stuff in cinema we NEVER touch. For me that is:
Physical Renderer ( have redshift )
Any Character stuff
Virtual Walk-though

But I do use
Cel shaders
Cheen - very fast for microscopic textures - actually all the oddly named volumetric shaders are fast…
And some other older stuff. Sure I’d like some of it to be rewritten and multithreaded - but not if it breaks opening old projects.

The thing is we are all doing different project from ArchVis > Games > film > products and you can’t say that something is not being used daily… you are just not.


Memory space is not a real problem when keeping old functionality, the API is. You can’t modernize the core while keeping features unchanged. Some you can adjust but many have to be rewritten. Those simply can’t be compatible with old scenes anymore. Think of trying to install a 2001 VW Golf Engine into a 2019 model, yes it is a golf, yes it is a gasoline engine, but it is completely differently built and just doesn’t work. So just keeping old features for backwards compatibility is a very limited solution.



Something like Cheen–an updated equivalent-- might be useful but it belongs in the content browser. I built an Octane style material that looked like Cheen just last week. It’s nothing that special. Just a gradient that runs along angle of incidence combined w/roughness mat.

Yes we all use different features but some things are antiquated, and can be achieved through alternate approaches. Usually better approaches.

Creative destruction always breaks some things. That’s way it’s called destruction. Cities don’t modernize without pissing off certain constituents. Bringing in the new requires pushing out some of the old.

My opinion, anyway.


As far as legacy stuff, I think Maxon handles it quite well in general.
They commonly have stuff that’s obsolete only show up when you open an old scene. Some options have ‘legacy’ checkboxes that only show when opening old scenes.
They’ve been doing this for years & years back to the ancient ‘dirt’ shader & I think it’s a reaonable compromise between maintaining backward compatability & avoiding clutter.
The other thing is, there are many awesome workflows that people have hacked out of otherwise crappy features that were never intended for the purpose. It’s sad when one of them is killed & I’d rather it be only when really necessary.
For me, so long as having that old stuff in there (maybe even not appearing in menus & interface but still there in command menu for the few who care) isn’t costing Maxon any significant resources, I say include it.


This is speculative but i wonder why Insidium had to make the Bridge for R20. Is the C4D core still in transition that prevented a full porting by Insidium?


Doubt it. Every so often, the core has a change deep enough that they have to break certain compatabilities. If
I remember, R11 introduction was one such point, where changes to floating point precision & scene scale meant the format was no longer backwards compatable. The removal of coffee was another such break point.
The need to make a bridge for R20 was a symptom of the deep underlying changes in the core. I think That’s all there is to it.