Access to viewport from the RecordTraversal?

[gwaldron]

Is there a way to access the current camera, viewport, or window from the RecordTraversal? My goal is to do some screen-space-error culling, not too different than the OSG's "pixel size on screen" LOD mode. This requires access to the viewport information or a window matrix of some kind. Thanks for your help.

[timoore]

Is there a way to access the current camera, viewport, or window from the RecordTraversal? My goal is to do some screen-space-error culling, not too different than the OSG's "pixel size on screen" LOD mode. This requires access to the viewport information or a window matrix of some kind. Thanks for your help.

@robertosfield just committed code today that writes the viewport dimensions to ViewDependentState, and you can get at that via getState()->_commandBuffer->viewDependentState() in the RecordTraversal object. Otherwise you can write a custom View object which will have direct access to the camera. See https://github.com/timoore/vsgCs/blob/873b1311c67a33a05f88cd2a5ec478b82ad08875/src/vsgCs/CsView.cpp . Your application will have to use that View class.

[gwaldron]

Thanks Tim. I see that viewDependentState->viewportData is an array. What does it mean to have multiple viewports in this context? (Or is it just an array since that is what maps easily into a BufferInfo?)

[timoore]

It's for the support of writing to multiple viewports using a geometry shader, and eventually the VK_KHR_multiview extension that produces multiple sets of attributes from a vertex shader, like for VR. I don't think any of this is particularly supported in VSG right now.

[robertosfield]

Have a look at the LOD code as it uses a screen based calculation for selection the LOD child.

[gwaldron]

Thanks Robert. I saw this; it's clever. I will take a closer look.

[robertosfield]

No I'm at my dev system I can more easily look up the specific code in RecordTraversal::apply(LOD&):

https://github.com/vsg-dev/VulkanSceneGraph/blob/master/src/vsg/app/RecordTraversal.cpp#L148

The scheme is not entirely straight forward because I'm trying to lower the CPU overhead as much as possible and enable use of non-dimensional screen height ratios for the LOD cutoff, rather than more traditional distance cutoffs.

The vsg::State object used internally by the RecordTraversal caches a pre-processed vec4 lodScale value that is updated each time the view frustum changes during traversal. The lodScale is computed from the model view and projection matrices and is used to distill the work required for the LOD calculations. Unfortunately I don't have a record of how I derived the maths, just the the final C++ code remains. Fingers cross I don't have to an further debugging on it :-)

[robertosfield]

As a general note, during the VSG development I've been using the "Minimal and Complete" principle to help decide what to implement and what not. Many features that we might find in the OSG also appear in the VSG, but many haven't been included - if a feature isn't essential and can be implemented with other means then I have often chosen not to implement it.

What one might deem essential will vary from project to project, as the VSG's usage becomes more widespread that the diversity of the projects that use it will increase and with it the potential set of features we might now deem as essential. I'm fully expect this process to continue - boundaries will be pushed potentially to breaking point and when things break or become far too awkward to implement then refactoring or extending the existing API and implementation will be warranted.

By not trying to over-think what users might need off in the future, and instead focusing on what existing uses or near-future uses require one keeps the implementation distilled and focused on actively used features which can be tested against, and avoids implementing features that don't have an immediate use case or a means for testing them - and avoids the extra complexity, that may never by needed.

So if you root around for a solution but don't find one, and no one else can come up with a sensible solution just raise your hand and say "it looks like feature X is missing as I can't do Y without it." If you can also suggest a minimal change to address this feature X then even better :-)

[gwaldron]

Haha :)
For my purposes I'm trying to match geospatial imagery dimensions to pixels on screen, so the window height ratio isn't quite enough info to make that happen. For now, I adapted your old code from 2002 - I hope you don't mind - and it still works, but like you say, it is particular to this application and perhaps too much math to do by default when most users don't need it.

[robertosfield]

Oh my that ages me, code I wrote from 21 years ago. Useful code lives forever!

The lodScale in vsg::State is very similar in principle, just has a bit more specific usage case. I wonder if you could use the viewport height to scale the lodScale as a short cut.

[gwaldron]

Good idea. This works just as well with much less code:

    auto& vp = state->_commandBuffer->viewDependentState->viewportData->at(0);
    float min_screen_height_ratio = (TEXTURE_SIZE + SSE)/ vp[3];
    float d = state->lodDistance(bound);
    bool visible = (d > 0.0) && (bound.r > (d * min_screen_height_ratio));

[robertosfield]

The ability to get the viewportData from the viewDependentState is workaround that might it more sensitive to internal API changes - this particular feature I just added this week for a completely different purpose that you're using it for and made still require further refinement.

It may make sense to cache more data in vsg::State if it's going to be commonly used.

[robertosfield]

@timoore mentioned about recent changes to the core VSG that extend ViewDependentState to include viewportData so that shaders can now use this.

One example of where it can be used is when scaling point sprites relative to the window size, something that vsgPoints used have to do manually providing the viewport data as a uniform, but using the new feature have been able to simplify the code, the changes are:

vsgPoints changes using the ViewDependetState::viewportData

The brick.vert shader provide an example of how it's used:

brick.vert shader from vsgPoints

The code that scales he point size is simply:

float dist = max(pointSize.minDistance, abs(eyePos.z));
vec4 viewport = viewportData.values[0];
gl_PointSize = viewport[2] * (pointSize.size / dist);