You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Also, things like transformation operations live on a stack and aren't always done in the same order for every prim.
I was thinking that we might want to expose attributes like this:
In a list (think the modifier list from blender, or the stack based modifiers of 3dsMax
Ordered in the evaluation order, (with the ability to resort them by dragging?)
Not show more attributes than actually exist on an object
Adding transformation operations with like, a button or some menu would be good too.
I think we should avoid exposing something a standard transformation matrix for all prims that are selected, because it'd lead to creation of unnessecary attributes, bloating the file.
There's also the primvars, but these are so highly specific to each primitive that I do not know if we'd want to override them.
Animating parameters is also a thing that could be done but way out of
As for "normal transformations"
We can start by writing a "transformations" utility library that ingests data and applies them to a prim Xform/Xformable, as suggested here: #30 (comment)
I feel like this is enough of a seperate concern to warrant it's own issue, and I'd be down to work on that too.
It would be great if we could expose a dedicated attribute editor which would allow to display the properties/attributes a of a particular.
USD View exposes a 'view' to the data like this:
With special icons and color coding based on this:
We might want to stick to similar colors as USD view for familiarity.
However, it'd be great if additional to just displaying properties if we can implement editing functionality for most property types.
This would only really get useful with #25 because it'd need to respond to a Prim getting selected.
UX References
References would be:
Houdini's Inspector
Quiltix Property Editor e.g.:
- It seems that Quiltix relies heavily on the Node Property Factory from
NodeGraphQt
defined hereThe text was updated successfully, but these errors were encountered: