-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Lanierd/hydra 1054 #169
Lanierd/hydra 1054 #169
Conversation
lanierd-adsk
commented
Sep 13, 2024
- Support material assignment on a usd prim
- Support default material for usd procedural prims (sphere, capsule, cylinder etc..)
…hich is in USD 24.08 will be needed to fully validate this.
…cone and cilynder_1 are not supported on OSX for USD 24.05
FYI : @ppt-adsk @lilike-adsk |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good! Just one outdated comment
@@ -68,7 +88,7 @@ HdSceneIndexPrim DefaultMaterialSceneIndex::GetPrim(const SdfPath& primPath) con | |||
bool DefaultMaterialSceneIndex::_ShouldWeApplyTheDefaultMaterial(const HdSceneIndexPrim& prim)const | |||
{ | |||
// Only for meshes so far |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comment needs to be adjusted
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, thanks! Only minor comments.
// Support implicit surfaces from USD as well, not only meshes | ||
bool _IsDefaultMaterialCompliantPrimitive(const TfToken& primType) | ||
{ | ||
static VtArray<TfToken> const compliantPrimitives = { HdPrimTypeTokens->cone, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Minor: would be slightly better as an std::set, with the check using either std::set::find() or std::set::count().
@@ -78,6 +78,11 @@ SdfPath DagPathToSdfPath( | |||
const bool stripNamespaces) | |||
{ | |||
std::string name = dagPath.fullPathName().asChar(); | |||
if ( name.empty() ) { | |||
MFnDependencyNode dep(dagPath.node()); | |||
TF_WARN("Empty fullpath name for DAG object : %s of type : %s", dep.name().asChar(), dep.typeName().asChar()); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we know when this happens? Is this for non-Dag nodes? Does this indicate missing functionality, missing logic, or a bug?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I had this with Bifrost nodes and also when selecting the default material set. But the problem is that wer get dag nodes with no type and no name, we should try detect useful dag nodes that need to be translated as some may not need to be treated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Github is erroring out saying that "You need to add a comment indicating the requested change.", even though I've done exactly that. Hoping that this additional comment will help.
Here's a useful reference: |
Co-authored-by: ppt-adsk <[email protected]>