Btw, it's possible to run CentiLeo and Octane at the same time. Just launch 2 Interactive Previews and they should work. I have tested this around a year ago and it was going without crashes.
As for Redshift there were problems on their side. RS didn't like when one other renderer is working at the same time in the same Cinema 4D launch, either Octane or CentiLeo. But this was true in the past and I don't know if anything changes until now.

Hi Raphael and welcome to our forum!

It's a coinsidence I was watching just yesterday on your FB page the charts about Octane speed evolution for different versions starting from 3.08 and up until now. Thanks for this valuable information that makes me more calm

In fact I become curious about what's going on with the subject question. In the past I was working for this not to happen when the renderer itself is not doing anything. Even if you don't launch it but tune CentiLeo materials with their preview performing some activity then it would take around 100Mb.

One explanation is that modern GPU driver may take some resources on the first call to get the list of available GPUs and then reserve this for some reason.
I will check this. In my case the the RTX 3080 reports only around 7.5GB when I just launch Cinema 4D without CentiLeo. I thought it is some OS memory reduction.

Btw, I am currently filling the manual page for C4D plugin and you may see it here
https://centileo.com/docs/index.php?COURSE_ID=3&CHAPTER_ID=069&LESSON_PATH=17.69

Kirill

If you want to create the gradient from bottom to top of the object without using texture UVW mapping then the receipe would be the following:
1) create the uvwProjection node with XYZ projection method
2) create Pattern node with linearY pattern type and connect uvwProjection to Pattern.inputUVW. This way you will get greyscale gradient.
3) create Ramp node as you did and connect the former node output to it's input map.

As for glass material you may attach the resulting node to Transmission Color or Absorption Color. Also you may variate the absorption distance with a texture

It shouldn't! In a couple of my tests the latest release was around few percent faster. But your example would be welcome (with a scene) to see what's going on there

Thanks for sharing!

Hi, its probably not enough number of ray bounces. Or something to do with nested dielectrics where you may control it using "Is Liquid" checkbox in the Transmission channel of material.

I recommend yo download new CentiLeo 0.66 which now supports Chinese Interface for node materials
https://centileo.com/news/162/centileo-for-cinema-3dsmax-0660/

Yes, certainly we can accelerate even more using the code optimizations, some algorithm & sampling improvements and also using image adaptive sampling as you mention. As for image adaptive sampling I hope to make it in 0.68 release which should be released somewhere in the summer. This will be very cool further speedup.

Yes, the forum was unfairly ignored by people, but in fact we didn't push promotion because needed to develop & bugfix more precisely. Anyway there are good conversatiions in the messengers.
FP will be supported for sure, and I think we will see it in the middle of this year.

The next version of CentiLeo plugin for 3ds Max will get very important update: a denoiser and material converter from main 3ds Max shaders (from General category), Corona and Fstorm. And this will be released in the coming days.

Hi sel, welcome to CentiLeo! And thanks a lot for attempt to make a converter!
Good news is that I am working on this at the moment and it will be a C++ converter, that means that it will be able not only to convert into CentiLeo shader nodes, but also to use existing nodes directly in CentiLeo. We will try to support as much as possible from Cinema native nodes and Octane, and maybe more. And there will be iterations to refine the precision of shader conversion.
For example the similar job is made for our 3ds Max plugin and it will be released soon. And now started to do it for C4D, hope it goes rapidly.

Hi Fabiano and welcome to our forum! As for animated bitmaps/textures - they are not supported, but the alpha channel of CentiLeo material is the slot to attach any alpha/opacity maps.

Certainly 32 iterations (2048 samples per pixel) are not always needed. That's why some experiment on user side is needed. With denoiser that can be modified in IPR in post effects settings this is even simpler (to be released in 0.66). But further we want to make an automatic render stop for regions that are already resolved, we will do this in some near future.

A good practice to send a scene somewhere else is to save with assets option. It will save the scene to the specified folder and will send all the referenced textures there too and will change the links in the bitmaps. Also it's good to transfer the scene without "*.cntx" files and you do so.

Quote
ssjenforcer wrote: It seemed like it was fully rendered in just a few iterations, and even though I let it go all the way to 32--which took like 10 minutes--it did not seem to get any clearer.

Sometimes 32 iteratios are not needed, sometimes the lighting is very simple and some low amount of iterations make it ready in fact. But "not getting clearer"... how do you compare?
New version will get Nvidia OptiX denoiser that can be changed in post production settings for PV and IPR, very usefull thing.

Hi, I have investigated into the issue. So the first problem

Quote
it gets to 0.5 iterations very fast (I set it to 1 iterations to test how it looks at first) and then it struggles to get to 1 iteration on the first frame.

It looks to be fixed, I don't detect it in the new upcoming version.

As for the other one with glitching I understand now what's going on and it needs to be fixed. So in fact we have a scene glitching.c4d and an object GangutStation.
This object has several selection tags with different referenced materials tags. Some materials have displacement mapping applied, some are not! But because something is with displacement then the whole object is getting tesselated and displaced but selection areas without displacement material get zero displacement value. The issue here is that tesseleated and displaced object surface triangulation and normals are changed compared to original and I think there is some wrong assignment of normals to not really displaced selections. This should be fixed by me. And I think that internally not displaced polygon selections should remain purely original.

Also the other issue here is that when we have several selections for the object then the tesselation settings (edge size, subdivisions, but not the displacement map itself) are taken from displacement settings of the base material tag. Base material tag is the one that has no selection tag refrence and it would be applied to all polygons if selections were not present. It's wrong from my side, because I think we have to get these settings per selecion correctly.
But in this scene case there is no created base material tag and a default one is used with too rough tesselation settings (Edge Size = 2, etc.). And these settings are propagated to all other material tags that reference correct existing selections. Certainly I have to fix this other issue.
Something can be done even now on user side if you create a material tag on the left side of the object tag list without assigning this material tag to any selection. Also add material to this tag with zero constant displacement map, fix the tesselation settings to edge size = 1 or 0.5 and then artifacts poping normals will get reduced a lot.
See this screenshot as an example of settings

Quote
ssjenforcer wrote: If I render 200 frames then usually only the last 10 or so will still look normal until they change like the first 190 frames have already done. It has happened multipe times for different scenes, so it might just be for large number of frames.

I think it's not gamma but some memory corruption bug. I hope it's fixed with the other bugfix changes. During last couple of few hundred frame renders I haven't noticed that, so let's hope the issue will dissapear even in you renders when it' released.

Quote
ssjenforcer wrote: Have you encountered this issue at all in your renders?

Not yet, still finishing the previous task and next will proceed with this one

Quote
ssjenforcer wrote: Let me know if you would like that scene with the glitching floor geometry, because I tried everything I could and no matter what I set the material channels it would still do it.

yes, that would be good to get this glitching scene too, I want to fix it

Thanks for shares! I will look into files and get back to you.
I see the Alien on one screen, one of my favourite characters!

It seems to be a CentiLeo bug.
0.5 iterations is progressive stage that shortly shows the whole picture. Then it works as buckets until 1.0 iterations and all the others are also buckets.
Does this issue always reproduce? Can you send me a minimum test example for fixing?
I have fixed a lot of things already since last release and maybe this issue is also fixed but I am not sure.
The new version is coming soon.

Quote
cristofer wrote: I have managed to render the scene in cinema 4d, I just had to be aware of deleting the disk cache, the global cache, everything in the image viewer and I realized that in the cinema 4d task manager a counter appears that does not stop even when the rendering is already finished, the task is called pv cache cleanup I'm sorry I had the automatic language translator on

Sounds good. As soon as you had to remove the PV cache, what's your RAM size and how many render frames did you have?

Quote
cristofer wrote: He logrado renderizar la escena en cinema 4d, solo tenia que estar pendiente de borrar el disk cache, el global cache, todo en el visor de imagenes y me di cuenta que en el administrador de tareas de cinema 4d me aparece un contador que no para incluso cuando el renderizado ya ha terminado, la tarea se llama limpieza de caché de PV

Pls auto-translate it in Google translator. There is a search engine on the forum that helps finding messages and replies and it's better to keep the same language that was chosen