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

Quote
ssjenforcer wrote: Ok, I just remembered I have motion blur enabled in all my scenes now.

not needed to enable it if the scene is static with no motion.

Yes, dynamics for simulations and particle engines should be cached before rendering. This is mostly needed for time offsets and motion blur when we get the scene for certain time sample. This is adviced by particle engine developers as I discussed with them.
Sometimes this can work without caching but there are a lot of conditions to get correct rendering. So it's anyway better to develop the simulation at first and then cache it and the render.

How much I hate the bugs that appear randomly, and not always... So hard to guess wtf with them
The bugs that are localized with a certain algorithm are like a gold. A developer finds them easilly and forget this.
In fact there were a lot of old bugs fixed during 0.65 development, especially that poping artifacts in very low subdivision scenes. The issue was so funny!
Btw, I have already fixes few other bugs (around 3) with emission materials and other things for the next release, that will be released quite soon.

Quote
ssjenforcer wrote: I am just learning how useful the distortion node is with the scratches node.

Yes, the combination of UVW nodes can be used for powerfull texturing for sure, especially with the Noise shaders. And we support 20 UVW channels btw, so it's a GPU king of texturing at the moment.
Scathes shader I think will be modified. I personally miss the colored output from it where you can assign scratches with different grey levels to the Gradient and produce the scratches of different colors. E.g. it's don't nicely with the flakes shader

May you please send me a minimum example of the scene for investigating in 2023 c4d?

It would be interesting to see an example. And I think if you click "reload scene" button in IPR you can make the same trick without re-openning the window.

Quote
coooooolin wrote: Please ask a question, the node editor in version 0.65 of CentiLeoforC4D2023 behaves abnormally, the line pulled out of the left-click property of the node does not show labels such as material or color, only 4 default properties, is this the reason for the C4D setting? This problem is not present in R25, and when 0.64 was tried, it was also present in R26

I have looked more precisely into the issue.
1) the feature is available in R25 and below for both CentiLeo and native standard C4D nodes.
2) the feature is not available in R26 for CentiLeo and also not for native, Maxon have simply changed their menus
3) btw CentLeo 0644 was not available for R26

In fact when in R25 you click on the property and move and left-click and see this menu then you don't see all the nodes that can be connected. But in reality you can connect any node to color properties or single float properties such as roughness.