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.

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 will look into the problem. I usuall click "+" button at the top left corner of node window to choose the node. Maxon developers continue doing changes to node editor API and something could change on their end.

Quote
ssjenforcer wrote: should I get the update too? Was this an issue with 2023 as well or just s26?

You can just re-download the package again to get update with the bugfix

The issue with crash is fixed. Btw it happened when small enough object is used, e.g. a plane or cube. Just need to re-download and re-install the plugin.

Quote
Filip Stamate wrote: Dirt node is still not fixed, correct?

Not yet

Yes, I am working to fix this crash at the moment, it's reproduced already. Hope to fix it asap.

I hope there will be a chance to make Chinese translation for Cinema and nodes interface. At first glance it seems to be not so complex as there are some sources including other engine translations

Hi coooooolin, thank you! Actually the biggest speedup is on more recent GPUs such as RTX 3070 or 3080. For GTX 10xx it's more modest but still is nice as you see.
The CPU power (and dual CPU) is not exploited in CentiLeo rendering part, because we still have room for improvement on GPU.

Hi coooooolin, thank you! Actually the current CentiLeo architecture doesn't use dual CPU at all, we however can use multiple GPUs in the system, there can be a lot of them. But they become so fat, and I can fit only 2xRTX 3080 to my PC.
The CPU is used only to read the files, scene objects at rendering launch, and it's using several threads and multiple GPU too.

I have probably overseated with optimizations, and it would be nicer to make 2 releases of it each with some 2x speedup. But getting a one 5x is great too

Actually the features, materials and nodes were not modified at all. So everything should be as in the old version. Only the engine speed has changed.
I only remember that I have added the real scene units (mm, cm, meters) to the displacement mapping edge length for the world space mode. In 0.64 this value didn't have any units. Just check this part, maybe it may help changing the edge length of world space split (not pixel adaptive split).

CentiLeo 0.65: Multi-GPU Out-of-core Rendering
2 x RTX3080. There are 2 scene variants here: with 245M and 288M triangles.
The scene with 245M triangles is launched within around 12.5 seconds, and the scene with 288M triangles is launched in 15 seconds including ray acceleration builder and scene read from file. All renders have 4 iterations (256 samples per pixel) and 1600x900 resolution. All shots render within very few seconds.