Skip to content

Conversation

@marktucker
Copy link
Contributor

Description of Change(s)

Implementing a vectorized version of FromPickHit called FromPickHits. This
amortizes the high cost of computing instancer information when generating pick hit information for multiple hits with one function call.

@jesschimein @tcauchois this is my stab at vectorizing FromPickHit we discussed. This was easier than I expected. It gets Houdini's selection performance with scene index imaging up to par with UsdImagingDelegate performance using GetScenePrimPaths.

Checklist

[ X ] I have created this PR based on the dev branch

[ X ] I have followed the [coding conventions]

[ ] I have added unit tests that exercise this functionality
I did not do this because there is no unit test for FromPickHit, and I suspect a fair bit of infrastructure would be required to unit test this. I have however verified it functioning in an unreleased build of Houdini.

[ X ] I have verified that all unit tests pass with the proposed changes

[ X ] I have submitted a signed Contributor License Agreement (Reference:
Contributor License Agreement instructions)

… This

amortizes the high cost of computing instancer information when generating
pick hit information for multiple hits with one function call.
@tcauchois
Copy link
Contributor

Amazing, glad it was straightforward and the approach looks great! We've got internal tests for this; some of the usdImaging and Presto picking tests exercise this when we turn hydra 2 on.

@jesschimein
Copy link
Collaborator

Filed as internal issue #USD-10417

@jesschimein
Copy link
Collaborator

/AzurePipelines run

@azure-pipelines
Copy link

Azure Pipelines successfully started running 1 pipeline(s).

return resultVec;
}

for (int i = 0, n = hits.size(); i < n; i++) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is there a risk that i could overflow here because hits.size() is a size_t? Could you use std::transform here?

Copy link
Contributor Author

@marktucker marktucker Nov 18, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I think changing int to size_t is the correct thing here, thanks.

std::transform I had to look up :) It seems it was introduced in C++17? So my objections to this change would be that it makes USD require C++17 (maybe it does already?).

But more importantly I think such a change would obfuscate the operation of the code (I, for example, would have had to look up std::transform to know what the modified code was doing). If there is some performance advantage to std::transform I'm happy to do it. But otherwise I'd rather leave the old-school code, as purely an aesthetic/readability choice.

@spitzak
Copy link

spitzak commented Nov 18, 2024

Actually std::transform dates back to C++98. But I agree almost all the "algorithms" in std are impossible to read and very difficult to write, and especially with the addition of for (auto a : range) syntax really does not provide much improvement over raw C++ code.

…ows.

Addresses one of the points in feedback from @nvmkuruc.
@pixar-oss pixar-oss merged commit acec033 into PixarAnimationStudios:dev Dec 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants