MJV

The thing is that r21 was effectively the last version of Cinema that was developed under the old ownership structure. Every version since is simply licensing r21 with different numbers attached. Materially there is nearly zero difference between r21 and any subsequent version, except r21 had a better interface and supported custom layouts, had more and better available scrips and plugins that keep working as long as you don't update to something later, and of course is a more familiar and comfortable working environment for us old timers. Anyway this sort of thing is not uncommon in the software world. After Effects is virtually unchanged since version r7, except back then you could own the licence. The old Maxom ownership was very forward looking and nodes were probably their vision for the future and not the current ownerships, which simply maintains it as a cash cow to license. That is a testimony to how great the old ownership was.

It was supposed to be... er, something! It was definitely supposed to be something. Maxon used to talk about deprecating xpresso but have more recently said that Scene Nodes are not meant as a replacement for and will never be a replacement for xpresso.

For more about Octane I just noticed recently that the Cinema 4D Octane support articles on the OTOY site are really comprehensive and well written. This article on displacement for example in Octane for Cinema 4D: https://help.otoy.com/hc/en-us/articles/5384832960539-Displacement-in-Octane-for-Cinema-4D-Part-2-Model-and-Texture-Considerations

You could write company press releases and promotional material because that sure sounded like it but I thought this was a discussion about Octane vs Redshift in 2024, which really boils down to a discussion of biased vs unbiased rendering, as things currently stand today. The thing I want others to know about Octane, if you are comparing it to Redshift or any other biased renderer is that, mostly because of the nature of what it is and how it works (and limitations of today's computers rendering power) an unbiased path tracer, it has a very high noise floor compared to what can be achieved with biased rendering tools. Octane's big innovation is having a great denoiser. Without the denoiser it would be pretty hard to impossible to do almost anything in Octane. And yet anyone who uses Octane knows very well it can be a tricky balancing act between preserving necessary detail vs reducing noise. This can be especially tricky if the detail in question is itself noise (as with a noised based bump map), or noise-like (small craters on the backside of a moon, metal flakes in car paint). And it's a destructive process, that is, once you denoise it, you can't go back to the un-denoised state that contains the original information unless you deliberately save a copy of that as well. Biased renderers have a bunch of different scene sampling methods and options that let the user dial in where and what and how rays are directed and how things are sampled (monte carlo, semi monte carlo, directed, targeted, etc.). The downside to this is, 1) it sometimes feels like too many choices and 2) a possible lack of photographic realism resulting from the different user settings and scene evaluations methods composited together into the final result. If you look at Maxon's old Physical renderer for example, different settings here and there can lead to vastly different results, but the final result may be best for product advertising or architecture or whatever because it looks good and clean and not because it is shaded photorealistically perfect. A biased renderer should probably also offer additional compositing options, since the render itself is a composite. I personally prefer using Octane because it looks most real to me compared to anything else I have used, and I simultaneously dislike the layered or composited look of biased renderers. That said, I wanted to acknowledge the weakness as well as the strengths of both.

This is the same scene converted to Physical render which renders in 31 seconds. I don't use RS much but I expect it could do even better. OctaneWeaknessvsPhysicalMV1.c4d

This is a simple scene to show a simple concept. You know, or should know very well that AI is not a be all end all solution to noise artifacts. If the spheres were moons for example the denoiser would completely erase the craters along with the noise. The other options you mention don't do anything to make things better, but are ironically biased rendering techniques. So your solution is to cover up the artifacts with AI, throw more render power at it, or use biased rendering techniques to prove that an unbiased renderer doesn't have certain weaknesses compared to biased renderers.

How could it possibly not be?

I added the file to the post.

I personally love the look of Octane's unbiased path tracer. It's the closest thing to shooting with a real camera as you can get, but as with even the most expensive real world cameras, its big weakness is noise. Scenes that use motion blur and camera dof will look beautiful and dreamily real, but scenes that should depict a fixed, razer sharp camera image cannot be rendered completely noiseless, even with prohibitively high sampling settings. The scene below used 16,000 samples and 3.5 minutes to render. More samples make no difference after a certain point, and so pixel peeping such a scene rendered in Octane is unlikely to be very satisfying. In such cases biased renderers such as Physical and Redshift will render much cleaner. OctaneWeaknessMV2.c4d

I really don't know where to begin. I appreciate your having looked at the file MusicBoxMV39, but you (understandably) drew the wrong conclusion about my use of the -3000cm Gravity setting. Notice the file is number 39 in the process. In my cave that means there are 38 files that came before, starting with a whole slew of ones (that I didn't post) that used default settings that didn't get the job done. You know, after awhile of nothing working as one would expect, one starts to try unusual and unexpected values and settings out of simple desperation that something, anything, will work. That's just how it goes, but I can understand your puzzlement on seeing that 3000 value and not knowing how or why it came to that. Anyhow, the fact that, besides desperately trying a gravity setting three times the default, the fact that another one of those vain attempts to improve things, increasing sub sampling, was actually a trap that makes the whole simulation fail in the most absurd and confounding way imaginable, in this case making it look like gravity strength is changing over time or distance from start. (Silly me for not reading the manual better! 😄) The upshot is somewhere around MusicBoxMV43 I finally gave up on Simulation altogether just to make sure I hadn't lost my mind and went back to Bullet Engine where, shazam!, everything just worked as expected, with all the settings actually doing what their name suggest instead of literally none of them doing that.

If you really want to get into it, study these threads, study the files, do the challenges yourself, and get back to me. https://www.core4d.com/ipb/forums/topic/118521-why-density-and-mass-values-in-dynamics-instead-of-weight/#comments https://www.core4d.com/ipb/forums/topic/118537-discussion-about-how-musical-mographs-could-work/#comments

Where would I start? I don't have all week.

I too am at my wits end with the time I've wasted with R2024 now, all for a little hoped for overall speed improvement which I never could take advantage of because of all the extra time wasted with crashes and freezes on top of the disappointing new simulation solver. Going back to a previous version already feels like a huge relief after just a few minutes. Hopefully Maxon can work the kinks out but right now it's a disaster.

Hard to know what the issue might be exactly without seeing a file, but with Octane's Path Tracer I think it is best to place and model physical lights just as you would in the real world (of course without needing expensive light stands or booms). I use only material based blackbody or texture emissions or hdri lighting in my Octane scenes. If I needed a spotlight I would model it. I am not familiar with the Octane lights because I never use them, but I think they would be subject to the same restrictions that material based lights in Octane would be subject to. For example, subject to the same placement positions and directions that would be possible in the physical world, in order to get useful or predictable results.

It's kind of like how you can go on Amazon and buy a bag of chips for $50, if you look hard enough. It's just there hoping someone makes a mistake or someone's kid unknowingly orders it while playing with daddy's phone.

Just completely absurd.

I love the qualifier here, "in Solaris". So when does someone set up a camera "in Solaris", and why? I found it difficult to figure out. I think I finally settled on doing it in Object level and ported the result through to Solaris which I had to use because of Karma. (I edited this post to be more concrete and intelligible)

I was searching for something online, anything that might suggest R20 is worth a look and came across this: Possibly the greatest example of why one should not use Houdini ever made. What a train wreck. Poor guy. 🤣 And here is the only other review I found of R20 yet online: https://youtu.be/eyTVegGsEZE?si=RdSWUif_AbguseWY

I grew up with the Beatles but my dance teachers tend to dictate the soundtrack of my life for many years now, ranging from pop to hip hop, but I also really like listening to kpop as well. Wife is in a community orchestra so I get to listen to her rehearse often. Cello is a beautiful instrument.

I agree! This view makes it clear that the mesh isn't as dense as I thought, and has achieved the desired shape with modest geometry. The five point star at the upper lip corners looks problematic for rendering and that would probably need to be fixed before or on top of just adding extra edge loops for rigging and animation.

So back to the original post, I took a brief stab at it and came up with this. I started with a cube but soon realized it made more sense to start with a cylinder. Whatever you start with, it's still box modeling. In this case particularly the top and bottom may need to be left open, depending on what that reference was supposed to be, so having them already pre defined by the top and bottom of the already round cylinder makes sense. If I were going to finish this I would turn on symmetry or, if using my R20. cut it in half and place under a Symmetry object, and then flesh out the curvature. Also would place the reference as a backplate in Front view to make sure the outline proportions were correct. Image and file attached below. VaseModelMV1.c4d

The trick here is to try to not hurt the feelings of the 11 year old who did this or more importantly her parent who is maybe your client. 😂 Like the client I had once who was irate that I fixed something she had done (and was proud of) herself. 😅

So true. I think this is one of those cases where you have to ask the client what the hell that is supposed to even be and how they can even consider it reference material.

This is not something for which you should use a lathe object, because it isn't round anywhere, top, middle or bottom. On the contrary the top and bottom are completely pinched flat, as are mostly the sides as well. This is a job for sds modeling. We used to call it "box" modeling but I'm not sure people call it that anymore. Anyway, make a cube, make it editable, shape it into a rectangle, drop it under an SDS object and start adding cuts and pulling vertices until you get the shape you need. I'm sure there are better sds (box) modeling tutorials online but that should get you started.