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

I think it's one of issue that I have fixed, will upload the fix soon. And hopefull it will run well.

It's certainly a bug there. I have fixed a lot of such things already, but think there is still something yet more rare. There should be a new release in coming days or maybe in a week

Quote

ssjenforcer wrote: This is also strange, I don't even have motion blur enabled with this latest shot, but look at the artifacting of the HDRi starfield as the centileo camera focal length changes to zoom out. I have never seen this before, but it occurs randomly at various frames throughout the zoom. The camera isn't even moving for this one. Large portions of the HDRi seem to spontaneously change resolution or something.

Oh, yes I think I have found it on one of my tests. It's a diffrerent bug for out-of-core textures, also with 16K HDRI. Hope I can fix it

Quote
ssjenforcer wrote: For another scene I am having a similar issue. A camera attached to an object moving through space, and the interior is becoming invisible.

I think I have fixed the issue. Will upload the release quite soon. Currently working to add a denoiser.

Another case: moving camera and moving object with the same speed.
The issue will remain in IPR when the camera is updated realtime because during this realtime navigation the scene and the camera is not re-evaluated for each time step. Cinema may provide camera steps information when entire scene is evaluated for each time step and it's expensive for navigation purposes in IPR. So for this reasons only camera current time step position will update during IPR navigation, and this will add some object blur because the scene was read in time steps before, but the camera is updated later with view changes with just one time step.
However, your setup (moving camera + moving object) will work correctly in IPR if you lock the camera changes and reload the scene manually (it will refresh the scene and camera positions with steps). And it will work in Picture Viewer.
But need to upload the fixes into the new release.

As for objects that become partially invisible I think I should see a scene example. Can you send me for example a simple localized sample maybe with one or few scene objects? Maybe the speed of camera and Null object is not the same.
As for HDR with stars not moving you are right because this HDR mapping is directional, it doesn't depend on world space position. You can make a bitmap with a texture for emission material but check off the "importance sampling" however it's off by default