Render output size/aspect different between version 4 and 5

[AMG445]

Hi there, I have just updated from a late version 4 to 5. I have used the same render settings that I always use (that my client requires) this worked perfectly in 4. But now the same camera angle in viewport with the same settings crops the sides of the render. I have attached screenshots of the SU window with and without safe frame (I don't use safe frame normaly. And the rendered output with both sides of the images cropped. If I rill back to version 4 it renders perfectly. Any help would be appreciated,
Cheers,
Nick

[konstantin_chaos]

Hi Nick,

I don't think the behavior you're seeing is caused by the V-Ray update.
It is most likely due to a SketchUp update - 2021.

Here's what is going on:
We use the SketchUp API to determine the horizontal field of view of the camera.
It is not straight forward though since SU gives us vertical FOV when safe frames are off and horizontal when they are on.
We basically have to account for that and manually calculate the horizontal FOV - making sure that what you see on screen fits horizontally in the rendered frame (top and bottom might be cropped when safe-frames are off).
This calculation seems to fail in SketchUp 2021.

The problem that you've demonstrated is V-Ray failing to get the horizontal FOV when the safe frame is off - I'm assuming your render was done this way.
You can clearly see that the horizontal crop of the rendered image does not match the viewport.
However the vertical crop does match - 9 tiles are visible on the ground.
You can try rendering the same scene in SU 2020 - I'd assume it'll render as expected.

As a conclusion:

1. There is an issue in our code for determining the horizontal FOV in SU 2021 that we'll fix as soon as possible.
2. I'd recommend you always enable Safe Frame in your projects. This will ensure consistent output.
   Note that when the safe frame is off and you change the SU window size, the toolbar size or even open the project on a system with a different monitor - the rendered image will be different.

Thank you for bringing this to our attention!

Regards,
Konstantin

[AMG445]

Hi there Konstantin, thanks for getting back to me. This is actually in SU 2020. If I re-install version 4 it will go back to 'normal' and as soon as I install version 5 it will render cropped (with the same camera in the same model). As a work around I have just put version 5 on match viewport rather than 16:9 widescreen. But it's just strange that they don't work 'the same'. I don't use safe frame either. I just thought I would turn it on for the screen shot. It would be great to go back to 16:9 at 3800 x 2138 (as that's what all my files are set up to in photoshop rather than match viewport at 3800 x 1874. Thanks again for the reply.

[konstantin_chaos]

Hi AMG445,

This is actually in SU 2020. If I re-install version 4 it will go back to 'normal' and as soon as I install version 5 it will render cropped (with the same camera in the same model)

Now, that is strange. I'll continue testing and hopefully get to the bottom of this.
And as I mentioned rendering without safe-frames is risky - try making your SU window narrower and the FOV of rendered image will change.

Konstantin

[AMG445]

Thanks Konstantin, that would be great as it is very strange. It's probably a bad habit but have never used safe frame. But, yes very strange that there's a difference between versions, Thanks again, Nick

[delineator]

[*]I'd recommend you always enable Safe Frame in your projects. This will ensure consistent output.
Note that when the safe frame is off and you change the SU window size, the toolbar size or even open the project on a system with a different monitor - the rendered image will be different.[/LIST]Thank you for bringing this to our attention!

Regards,
Konstantin

I was going to create a thread about this, but figured I would jump on this one. My response would be - yes, kinda true, though that behavior is still present with safe frames on (we always have safe frames on). As a firm, we are dealing with "pixel shift" pretty constantly as different scenes are rendered on different computers, monitors. You are correct, we have minimized this by setting the SKP UI all the same (same number of toolbars top, left and bottom, same tray size on the right, small toolbar icons, using safe frames, etc). However, occasionally we would still have a very slight "pixel shift" from version to version. I tracked down what I believe the issue is yesterday: Windows resolution and scale. We had most of the office running 1440p monitors at 100% scale BUT we have a few 4k monitors running 150% scale. This was enough to cause the issue, tracked down to the vrscene as:

CameraFilmTransform CameraFilmTransform {
postscale=0.8499638;
transx=-0.05301976;
transy=0.1501703;

On 100% scaled monitors, the transx was .053, on 150% scaled monitors it was .052. Literally everything else in the vrscene files was exactly the same. This was tested on both 1080p monitors at 100% and 1440p monitors at 100%

The temporary fix for me is to tweak Windows' horrible high dpi settings and set it to high dpi scaling on "system (enhanced)" This allows me to keep using 150% scaling in Windows and sketchup appears MOSTLY the same, it just doesn't realize its being scaled. There are some major downsides as toolbars not lining up and your mouse doesn't click where its pointing BUT, I confirmed in the vrscene output that the camerafilmtransform was the same and the cams matched up.

[konstantin_chaos]

Hi guys,

Here's what is going on:
We use the SketchUp API to determine the horizontal field of view of the camera.
It is not straight forward though since SU gives us vertical FOV when safe frames are off and horizontal when they are on.
We basically have to account for that and manually calculate the horizontal FOV - making sure that what you see on screen fits horizontally in the rendered frame (top and bottom might be cropped when safe-frames are off).
This calculation seems to fail in SketchUp 2021.

I consulted with the developers and it seems I made a mistake here.
The described behavior only applies to V-Ray Next.
There is a change in V-Ray 5:
When the safe-frame is disabled the vertical FOV is the constant and the horizontal crop changes when you change the viewport size.
There is no real difference between SU 2020 and 2021 except for the fact that the default Tray size is different (based on the OS scaling I suspect), which changes the viewport (and hence the horizontal FOV).
We will now have an internal discussion about this and explore ways to improve the UX.

I was going to create a thread about this, but figured I would jump on this one. My response would be - yes, kinda true, though that behavior is still present with safe frames on (we always have safe frames on). As a firm, we are dealing with "pixel shift" pretty constantly as different scenes are rendered on different computers, monitors. You are correct, we have minimized this by setting the SKP UI all the same (same number of toolbars top, left and bottom, same tray size on the right, small toolbar icons, using safe frames, etc). However, occasionally we would still have a very slight "pixel shift" from version to version. I tracked down what I believe the issue is yesterday: Windows resolution and scale. We had most of the office running 1440p monitors at 100% scale BUT we have a few 4k monitors running 150% scale. This was enough to cause the issue, tracked down to the vrscene as:

Now, this is new.
I have to do some testing myself but it sounds reasonable.
Unfortunately I suspect that the SU API is giving us inconsistent values between different OS Scaling factors and I'm not sure if there is anything we can do to fix it.
In any case we'll look into it and I'll post our findings.

Thank you both for bringing these issues to my attention!
Konstantin

[konstantin_chaos]

OK, I also missed this part:

CameraFilmTransform CameraFilmTransform {
postscale=0.8499638;
transx=-0.05301976;
transy=0.1501703;

This shows you're using two point perspective.
In this mode the handling is quite a bit different.
The safe frames will not help you much in this situation since SketchUp itself is changing the view when you resize the viewport and there is no way for us to work around this.

Test 1:

1. Activate 2pp in a scene
2. Pan to the side
3. Start resizing the SketchUp window > The objects start moving from side to side, relative to the viewport center

Test 2:

1. Activate 2pp in a scene
2. Activate Safe Frames
3. Pan to the side
4. Start resizing the SketchUp window > The objects start moving from vertically, relative to the viewport center

The bottom line is that in all cases (SF or not) resizing the SU window moves the objects relative to the viewport center.
This makes it impossible for us to ensure consistency between different viewport sizes (with one exception - described below).

There is only 1 way to ensure consistency with 2pp enabled:
Do not pan or zoom after you enable it... (I know)
To determine if you have panned or zoomed you can use the following snippet:

puts "-"*10 + "\n2D Pan:"
puts Sketchup.active_model.active_view.camera.center_2d.to_a
puts "-"*10 + "\n2D Zoom:"
puts Sketchup.active_model.active_view.camera.scale_2d.to_s

If it prints all zeroes and 1.0 for the zoom - you haven't moved.

I was also able to reproduce the issue - switching from 175% to 150% scale on Windows.
For me running the code for both scales prints exactly the same values.
This makes me think that SketchUp is giving us the correct data and we're messing up somehow.
And so the issue has been logged in our bug tracking system - SK-3415

I hope this clarifies things to some extent.
Konstantin

[Peter.Chaushev]

Allow me to give a brief update on the issue at hand
You are correct about the discrepancy between V-Ray 4 and 5 when having the same viewport aspect ratio.
This, however, is due to an improvement on our side that guarantees the same render result no matter how the SketchUp viewport is resized. The output will always be the same for a project that is opened and rendered on different systems.
For the sake of stability, it was deemed best to leave the current behavior as it is.

Kind regards,
Peter

[konstantin_chaos]

Hi delineator,

Back to the 2 point perspective thing:
We were able to reproduce the 1px discrepancy (caused by the OS scaling) and we also found what's causing it.
Unfortunately there is no simple fix in sight.

Basically, when safe frames are enabled SketchUp doesn't give us the correct 2d camera transformations.
That is why we have to do a couple simple calculations to derive the correct transformation and ensure that what you see in the safe-frame is actually rendered.
The viewport width and height (both integers) are used in the equation - they are divided giving us the aspect ratio...
And when the System DPI changes the viewport size also changes (measured in pixels).
When we divide the new width / height the resulting aspect ratio value is different unless the width and height divide exactly (...very rarely the case).
This calculation inaccuracy eventually leads to 1 or 2 pixels offset between systems using different OS Scaling.

The issue has been reported to Trimble and we might see a fix in there API at one point.
Without a fix it does not seem possible to avoid this behavior.

I hope this clarifies things to some extent.
And I'm also sorry for this inconvenience.

Konstantin

[delineator]

Ok, sounds good. My workaround for now (the system enhanced high dpi switch via windows) seems to work for now. Of course the larger issue for me and my firm would be just the general craziness of the skp cameras and how they pixel shift in 2pt perspective, but as you alluded to above, there isn't really a way to fix that.