osg vs vsg camera projection render loop

[blobfish]

If memory serves, osg updates the near and far planes of the cameras projection matrix every frame. I am not seeing that behavior in some simple tests of vsg. Is this difference on purpose?

Just to be clear, I found it cumbersome implementing an orthographic camera zoom with osg messing with the projection matrix behind the scenes. I am hoping that vsg has excluded this behavior on purpose.

[robertosfield]

The VSG doesn't have a near/far computation and projection matrix update mechansim.

The cost of computing the near/far distances each frame is performance overhead that I wanted to avoid, it's also simpler w.r.t public interface and implementation.

If application want to adjust the near/far ranges on the projection matrix they will need to implement their own mechanism. For most applications I don't think this will be neccessary.

[AnyOldName3]

As a bit of extra context, the VSG defaults to using a depth buffer format with a larger bit depth than the OSG did, and uses an approach called Reverse Z to use more of the bit depth on parts of the depth range that matter more, so applications should see much less z-fighting even with a very large depth range. That should make per-frame depth ranges redundant, so there's no benefit to keeping that complexity anymore, even though it was justifiable for the OSG.