Conversation
| } | ||
|
|
||
| // Can't rely on UsdImagingGLEngine::GetRenderAovs() as it may interfere with the current renderer | ||
| TfTokenVector _GetRenderAovs(HdRenderIndex* renderIndex) |
There was a problem hiding this comment.
Copy the implementation of UsdImagingGLEngine::GetRenderAovs() here, will ask HVT to see if it can provide one utility to do this query.
| for (auto* instance : _allInstances) { | ||
| if (instance->_initializationSucceeded | ||
| && passIndex < static_cast<int>(instance->_framePassesData.size())) { | ||
| UsdImagingGLEngine engine( |
There was a problem hiding this comment.
Reuse same hgi/hgiDriver in a new engine may interfere with the existing engine
lanierd-adsk
left a comment
lanierd-adsk
left a comment
There was a problem hiding this comment.
I don't think using a hardcoded list is correct, the render delegate are proposing custom AOVs that are not part of the hardcoded list we use.
| // Set the AOV to visualize for the current pass if it exists | ||
| const TfToken aovName = TfToken(visibleAOVNames[visibleIdx].asChar()); | ||
| const bool aovNameExists = currentPass->GetRenderBuffer(aovName) != nullptr; | ||
| const TfToken aovName = TfToken(visibleAOVNames[visibleIdx].asChar()); |
There was a problem hiding this comment.
This code is wrong in the sense that you only have hardcoded AOVs :
HdAovTokens->primId,
HdAovTokens->depth,
HdAovTokens->normal,
HdAovTokens->Neye,
HdAovTokensMakePrimvar(TfToken("st"))
But the render delegate , like Arnold, has some other AOVs available that the user may want to use for display. I don't think we should check in the visibleAOVs name if it exists sibnce this list is hardcoded.
There was a problem hiding this comment.
This is the same code used in UsdImagingGLEngine::GetRenderAovs() , yes, a better way is required in the future, before that, we have to copy that piece of code here as using UsdImagingGLEngine::GetRenderAovs() will affect the current rendering.
| const TfToken aovName = TfToken(visibleAOVNames[visibleIdx].asChar()); | ||
| // Can't rely on GetRenderBuffer(aovName) here as the AOV may not have been created yet | ||
| const auto renderDelegate = _GetRenderDelegate(actualPassIndex); | ||
| const bool aovNameExists |
There was a problem hiding this comment.
Here we are doing the same test as in visibleAOVNames, if it is in AOVNames then this will always be true since we tested for the same thing in MtohRenderOverride::GetAvailableFramePassAovs. But I don't think we should use this hardcoded list.
There was a problem hiding this comment.
We still need to validate if the AOV is supported by a renderer here, as user may specify a non-supported AOV by the commad and we didn't validate the user input.
There was a problem hiding this comment.
ok thanks. I was confused and thought we needed to have the diaplsy aov be part of the hardcoded list which is not the case.
2 participants
Fix the AOV buffer sharing issues: