OTOY Forums

From Octane 4 to Octane 2020, the lens shift abilities took a nosedive in accurate output. Scene file attached.

The problem is that the camera lens shift in the live view window is no longer correct. The "Cinema 4D lens shift" camera in the scene uses c4d's native "film offset Y" parameter to offset the view, this is preferable because it shows an accurate identical view in the live view and opengl c4d view. If you render the image to the live viewer and resize the live view window to match the render aspect ratio, you will see that the stick figures toes just touch the bottom of the frame as they do in the opengl view. However the problem happens if you resize the live view; any aspect ratio other than a perfect 16:9 will cause the framing to be incorrect.

It seems octane is locking the bottom of the render frame to the bottom edge of the live view window instead of to the bottom of the render frame within the live view.

In short, I have to endlessly resize the c4d octane window for every different camera size I use otherwise I have no idea what I will actually get when I hit render.

Cinema 4D R20.059
Octane 2020.2
Latest c4d plugin as of 4th May
Xparticles build 732
Current machine (but have tried other systems)
Geforce 3090, win 10 latest, 128gb, ryzen 5950x
NV Driver 457.51 (have tried others)

Not sure why we can't see your scene. Also a picture will be much appreciated. Wanting these always because to don't spend our development times for every cases to recreate with endless trys.

Hi,
have you tried with the Lock icon and Zoom factor? It should be much more precise.

ciao Beppe

File re-attached

Screenshot example also attached, you can see the figure's feet sinking below the render frame when they're fine in the opengl view.

The lock icon does fix the problem in effect, but that just creates a new problem, now I have to try and match the render resolution to the live viewer otherwise I'll be rendering pixels I don't need. It is quicker to re-arrange the C4D UI to fix it.

Yes there's a problem without LOCKRES mode, but it's working FINE with LOCKRES mode. See my comparison, what do you say?
I'm not sure what you mean with trying to match or rendering unnecessary pixels. As you see it's perfectly same with standard renderer.

My live view window is roughly 1000x700 pixels.
My render resolution is 8000x6000 pixels

If I turn on the padlock icon to lock the resolution, the live view window will render @ 8000x6000. Obviously this would be a terrible way for me to fix the problem.

boxfx wrote:My live view window is roughly 1000x700 pixels.
My render resolution is 8000x6000 pixels

If I turn on the padlock icon to lock the resolution, the live view window will render @ 8000x6000. Obviously this would be a terrible way for me to fix the problem.

There's a CANVAS SCALE and also RESOLUTION FACTOR settings in Live viewer. Use it!

None of them are solutions to the problem, they're hacky workarounds. If I use the two render resolution and display zoom values, now Im either sat there faffing about clicking in 0.01 increments at a time to try and get it to match the window size, or Im using the zoom and lowering the display quality with image scaling. I may as well have just used the original workaround of resizing the live view window.

I appreciate that it can help with the problem, but please just take this post as a bug report for something we'd appreciate being fixed at some point in the future.

Hi boxfx,

from what you have written, it seems that you are working with an huge frame buffer but a very small Live View.
What about making a copy of the Render Settings at half of even lower proportional resolution, to batter match your Live View dimensions?
In this way, you should not need to use the zoom, everything should be more precise, and correctly reported also on the high res resolution.

My two cents,
ciao Beppe

Yes, but they're more workarounds to a bug. I appreciate being offered more options but I already have a simple workaround: resize the live view window. Im just asking for the bug to be addressed so that I can stop having to jump around it. It worked in octane 3 and 4, the problem has been introduced after this.