Content scale when ScaleContentWithWindow property is disabled

[psyabcd]

In PolySpatial 2.0 MR mode, let’s say we have a 0.4x0.4x0.4 cube in a bounded volume camera whose input dimension is 0.5x0.5x0.5 and output dimension is 1x1x1, and ScaleContentWithWindow property is disabled. What is the actual size of this cube when running on a Vision Pro device?

The document states that “content will be the same size as it would’ve been within an Unbounded volume window”, so I assume that the actual size should also be 0.4x0.4x0.4 on device. However, I made a small demo and found out that the size looked more like 0.8x0.8x0.8 to me, which is double-sized by the ratio of outDim/inputDim

[vcheung-unity]

Hi!

I believe this is a case where the documentation should be updated to more closely describe behavior. ScaleContentWithWindow property essentially desyncs the size of the content with the size of the window, or in other words, the OutputDimensions. If you modify the OutputDimensions on a volume camera with ScaleContentWithWindow disabled, the content size should stay the same and should not change.

Things such as the Dimensions property on the VolumeCamera and VolumeCamera scale still affect content size, as they would on an unbounded camera (with the caveat that the Dimensions field on an unbounded camera is greyed out, but you can still manipulate the size of content by using the Scale of an unbounded volume camera).

The resultant 0.8x0.8x0.8 is correct, and you should get the same cube size if you create an unbounded volume camera in the scene, and then set the Scale to 0.5x0.5x0.5.

Hope that helps!

[psyabcd]

Thanks for your response!!

@vcheung-unity

Things such as the Dimensions property on the VolumeCamera and VolumeCamera scale still affect content size

By “scale” of a volume camera, do you mean the scale of the gameobject that the VolumeCamera script is attached to?
I don’t get it how Dimensions property would affect content size in bounded mode when ScaleContentWithWindow is disabled. My understanding is that the input dimension only affects how many content would be displayed on device, but their size thould be fixed to their size in editor (which is the same in unbounded mode)

We can assume that the volume camera script is always attached to a gameobject with uniform scale. The cube size is fixed 0.4x0.4x0.4. Here’s what I get on device:

1. With unbounded volume camera, the actual size is 0.4x0.4x0.4, which looks good to me and is consistent with the document, but it’s differerent from what you said here

@vcheung-unity

you should get the same cube size if you create an unbounded volume camera in the scene, and then set the Scale to 0.5x0.5x0.5.

Could you please verify this?

2. With bounded volume camera, input dimension 0.5x0.5x0.5, output dimension 1x1x1
   • ScaleContentWithWindow disabled, the actual size is 0.8x0.8x0.8, which is not the same size as in unbounded mode, inconsistent with document (which says that they should be the same)
   • ScaleContentWithWindow enabled, the actual size is 0.8x0.8x0.8, which is good and there’s no confusion here

Thank you for your patience!

[vcheung-unity]

For the scale - yes, that’s correct. That would be the scale of the gameObject the VolumeCamera component is attached to.

I’ve mocked up a small scene showing what I mean with creating an unbounded volume camera in the scene and setting the transform.Scale to 0.5x0.5x0.5. You can see that the two cubes, although in different volume windows (one is in a bounded and one is in an unbounded), are roughly the same size (I tried my best to position them next to each other, but the bounded one is slightly recessed, so it may appear slightly smaller). I encourage you to try this scene set-up as well - it’s a fairly small scene and should be quick enough to manually re-create.

For the purpose of calculations, transform.Scale is basically multiplied with volumeCamera.Dimensions, so you can treat them as somewhat equivalent for the purposes of determining content size.

Both properties inversely affect the root transform of the whole scene - this applies whether the VolumeCamera is bounded or unbounded, and whether ScaleContentWithWindow is disabled or enabled. In the editor, if you modify the Dimensions or transform.Scale property of a bounded or unbounded VolumeCamera, you can see that the corresponding transform.Scale of PolySpatialRoot is set to the inverse of Dimensions.

Enabling ScaleContentWithWindow forces content to additionally scale so that it remains proportional to the volume window size (i.e. content that appears to be half the size of the VolumeCamera boundaries in the editor will remain so on device no matter the size of the volume window), while disabling it breaks that forced proportionality, so that the only thing that affects content size is volumeCamera.Dimensions and transform.Scale. By volume window size, I mean the OutputDimensions, which is the initial size of the volume window itself.

This behavior is true for the unbounded camera as well - you can modify content size by changing transform.Scale, hence the comparison to unbounded camera mode (which I acknowledge may be muddying things up more than being helpful!).

I hope that helps! Any feedback on how to improve the docs for clarity would be welcome! I think some improvements to the VolumeCamera gizmo tool would help in visualizing this on editor as well, and will make a task to look into modifying the gizmo tool to accurately reflect what content will look like with respect to the volume camera.

[psyabcd]

Thank you for the clarification and great example!!

Now I finally understand how scale and dimensions affect the content size when ScaleContentWithWindow is off in bounded mode