-
Notifications
You must be signed in to change notification settings - Fork 12
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
Instanced attribute sets #91
base: master
Are you sure you want to change the base?
Changes from 9 commits
945611f
f33f6f6
c2f6fd7
583d73e
7e8291c
ead81e2
d5f67a9
dadb64b
725a4fe
ddb9c1f
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -54,11 +54,15 @@ class Attribute { | |
AttributeElement element; | ||
uint flags; /* enum AttributeFlag */ | ||
|
||
/* Multiplier on the size of the buffer */ | ||
uint instances; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I am not sure if we follow some here some encapsulation design principles or has this field intentionally been made public for free manipulation? What happens if we instantiate There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Nope, the field can be made private. |
||
|
||
Attribute(ustring name, | ||
TypeDesc type, | ||
AttributeElement element, | ||
Geometry *geom, | ||
AttributePrimitive prim); | ||
AttributePrimitive prim, | ||
uint instances = 1); | ||
Attribute(Attribute &&other) = default; | ||
Attribute(const Attribute &other) = delete; | ||
Attribute &operator=(const Attribute &other) = delete; | ||
|
@@ -175,8 +179,9 @@ class AttributeSet { | |
Geometry *geometry; | ||
AttributePrimitive prim; | ||
list<Attribute> attributes; | ||
uint instances; | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Can There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. They can't be different and the one in |
||
|
||
AttributeSet(Geometry *geometry, AttributePrimitive prim); | ||
AttributeSet(Geometry *geometry, AttributePrimitive prim, uint instances = 1); | ||
~AttributeSet(); | ||
|
||
Attribute *add(ustring name, TypeDesc type, AttributeElement element); | ||
|
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.
Honestly, I have problems wrapping my head around this PR to understand what is going on. How
numkeys
is different thannumverts
and whynumfaces
has been added. I suspect that keys are actually vertices for curves? And whynumfaces
is important for instancing. Is because we want to override face attributes?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.
Yes, the goal is to override attributes with different interpolation (or element in cycles speak). If an attribute has
ATTR_ELEMENT_VERTEX
interpolation, we want to bump the offset by the number of vertices.The current code was using numkeys for points in a cloud, while attributes authored on those point have ATTR_ELEMENT_VERTEX as interpolation. If we wanted to branch on the type of geometry to calculate the indexed offset, the code would have to be scattered and duplicated in the various
primitive_*_attribute
. I decided to make that change to streamline the logic.So far numkeys/numverts was being used for motion blur positions, so faces wasn't needed until now. I know that on the delegate side we currently only support constants, but the USD point instancer specification doesn't impose this limit so I went for a more generic approach. And for completeness.
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.
If you are talking about the fact that numkeys and numverts are never set together and we could avoid using one of them, I totally agree. It hasn't been done in this PR to limit the number of changes as it would require patching more parts of the code.