Well, when you create a Color Correct node in place of Bitmap it doesn't automatically connect the Bitmap to the input of Color correct. Currently it's a manual job Previously there was automatic connection for such cases but probably occasional code commenting has switched this off
Btw, in the R21 nodes such things are not noticed, there is a different life there.

Quote
vblackrender. wrote: When you generate a camera with exactly the same settings as in the image, the "Film Offset" will change sometimes.

what do you mean? Does it mean that some Cinema viewport and render images may be different?
I have just tested the editor view responds as expected to the changes. Will check things and make the feature.

Yes, it's possible of course to handle many of them. Do you want to move that created regions as in Corona across the image? What about redrawing selection as is implemented now?

The refresh rate in PV and Editor is not real-time because at that place Cinema (except of Editor) requrests all AOVs and the main image too. Getting and saving them to Cinema's PV is quite costly (especially for many AOVs). So refresh rate was decreased.
IPR has much cheaper picture delivery (and updates only what it sees).
Also the IPR has Final Geo mode (FIN GEO button) which renders the same scene as PV (Final render) with all tha final subdivs etc. In this mode it doesn't respond to geometry changes but it reacts to material changes which is a cool thing. Then you just send it to PV with the most left button in IPR and continue working there.
When light tags will relocate to materials there will be also possible to change lighting in PV-like mode (as described here)

Bucket mode in IPR can't be switched off. If you mean that that it starts at some left-bottom corner and reaches the desired place of image at some longer time - yes it's a problem. At least the region render can be used to guide the bucket. And maybe later I will make the buckets to restart from the most usable areas.

Some noisy stage before buckets is used to preview quickly and populate the caches silently. But the quality of noise will be improved and the stage can become shorter (to avoid wasting time).

This is an option, but need to figure out if there is any existing project folder when the scene is just created but not yet saved in some location. This can be a tmp location in Cinema directories which can become polluted and unnoticed at all. Redshift for example saves such files to just one known location. Maybe it's a good default option.

Hi vblackrender., I don't know yet how to limit it with a special procedure. Will need to explore.
The goal was to construct a process that saturates a GPU with tasks as much as possible. Less CPU work, more GPU.
But I think the laggy thing may be reduced with some future optimizations especially related to picture delivery to IPR. Also the current JUCE framework that is used for IPR window may be a reason (I am going to change it Cinema native windows).
Also not everyone experiences the laggy behavior, some people notice CentiLeo for being not laggy. I had laggs in the past, then optimized and don't notice now on 1070 (all 2 or 4 GPUs run at the same time and + 2 monitors). What is your PCI Express connection GPU <-> Host? Normal x16 or x8 lanes?

Quote
vblackrender. wrote: But in this case, you can to choose between "0" to "1", wich can be very interesting to use in some situations.

Not only between 0 and 1. But can make it larger than 1.
Actually I don't like the current light tags because changing a value in just single simple tag will force to check the full scene object structure (not necessary objects itself) and in case of some complex procedural geometry with motion blur it may force unwanted delays.
The other problem is that light tags dont inherit values from parent light tags (which can be helpfull for changes to many lights at once).
The plan is to duplicate all light settings to Emissive material (Emissive property in the current Std material). Materials are inherited well and changing only them will not force for scene for extra checks.
What do you think?

I like the lighting! Is it area light in window hole? Btw you can make it invisible for camera: in centileo light tag make zero internsity for Camera setting.

Yes, it's not recognized. Will fix this once will finish the current release workds. It's possible to support native C4D camera settings almost entirelly. 3ds Max has Physical camera with tilt options (and auto tilt) which will also be included there.

I think it's good to move this topic to C4D Discussion forum, just relevant to be there

No, it shouldn't be WinRAR compressor or anything general. It will be some custom algorithm which unites similar texels at vicinity, doing that on GPU and using on GPU with on-the-fly decoding. It should be fast and without overhead (initial compression time will be added, but disc output time reduced because of smaller size).

Hi vblackrender.! Yes, they are needed to save time for continuation uses (reading original files, extracting from compression, converting to internal images). They are unpacked uncompressed bitmaps in a format that is used for out-of-core textures in the chain "Disc -> RAM -> GPU.
The Arnold renderer is doing the same thing with them.
These files are generated in the same place as their original source file. It's safe to remove them searching for "*.cntx" in Windows when the project is not going to run again
I will fix the problem with few solutions:
1) compress cntx files 3x - 4x or even more;
2) make some options to organize them separatelly in some special folder.

Hi vblackrender.,
I am writting the new docs now. At first there will be information about materials, projections and shaders. Just stay tuned, initial things will be out in the coming days.
I recommend to use R21! It's nodes are so cool and we have made our own nodespace for it.

Hi vblackrender., welcome here and thanks for warm words! Yes, you didn't know about CentiLeo because the shape of our features was too fluid and so no any adverticement... Implementation could simply change in any direction.

Currently there is an ongoing work to improve the knowledge about us, such as making an online documentation. This should help to gain more downloads.
Btw CentiLeo should be fast in darker interiors which are not very well lit. And right now there is development for particles/massive instances.

What version of Cinema are you using? The is a lot of attention on the new Cinema nodes starting from R21. Soon we will make them for S22 too.

Your questions are welcome!
The topic such as this is ok for images. Any questions are ok in Discussion forum (for some more general ideas that can be relevant to more people) or here (with questions specialy important to you).

Change Log: cntlc4d 0.591 alpha (2020 April 08) - currently for R21 only
[core] Fixed broken Absorption property
[cntlc4d] Fixed bug for lost frames during animation rendering in PV
[cntlc4d] Fixed bug with wrong geometry translation when IPR doesn’t account for some deformers (such as Surface Deformer and few others)
[cntlc4d] Fixed few bugs which caused some crashes.

I got several crashes while I was developing node editor integration for CentiLeo. Everything was done with Cinema SDK rules. Not too many places to make own bugs. When things were done for 0.58 the crashes during node editing work have ended.

But currently I still get random crashes when modeling (applying boolean operations, deformers, generators, bevels, etc.) while working in IPR with enabled scene auto-reload (IPR button with circle arrows and "auto" label). Will investigate further of course and fix other bugs too.

What operations were you doing before hang appeared? E.g. did you have opened IPR? Did you have enabled "Auto scene reload"?

Still not getting any crashes at this model. However, there are no textures there. Can you send them too pls? Eg. a link to email info@centileo.com

I have similar setup. Please, can you send me this scene and tell what to do to cause the crash? Does it always happen or randomly?

Hi Aimar, this is not a complex node, it's an ordinary one. So under some conditions this node was crashing? I am interested to know some conditions: what nvidia control panel settings, driver version, what GPU, what Cinema 4d build version (115 or 207)? Everything.
However, the bug may happen not on CentiLeo side, but on Cinema node side which is still not yet very stable (without CentiLeo).

which one? can you describe? is that always reproducible?