The results generated by the Volume To World shader node are offset on the Z-Axis. For a 50x50x50 volume the offset is approximately 1.6. Which means adding VolumeCamera.rotation * new Vector3(0,0,1.6f) to the result of the shader node almost corrects it.
@kapolka The code is the same as the previous bug report, just updated to 0.7.1
So far, while I can replicate the behavior with the project from IN-65666, I can’t replicate it after copying the content to a new project using 0.7.1. I’ll keep looking for what the difference might be.
It looks like the difference is the PolySpatial “Default Volume Camera Window Configuration” setting. With that set to an Unbounded configuration (versus the Bounded configuration in IN-65666), the discrepancy goes away. Likewise, with a new project using 0.7.1, the issue reproduces if I set the default to a Bounded configuration.
I have no idea why the default configuration would have an effect (despite the Volume Camera explicitly specifying a configuration), but that should be enough to find the underlying issue. Thanks for the repro case!
Long story short, the default configuration is opened automatically, and we weren’t picking up a resize event that happened immediately after opening. It’ll be fixed in the next release, but for now you should be able to work around it by using any Default Volume Camera Window Configuration other than than the one you’re using in your Volume Camera (assuming you’re using bounded mode).
Ok, it works if I set an unbounded volume as the default. It did not work with the default bounded volume, presumably because it has the same output dimensions. I expect it might also work if I set a different sized bounded volume as default.
It does shift the entire volume causing slightly different clipping, so had to adjust a few things, but otherwise it looks like nothing else broke.