-
Notifications
You must be signed in to change notification settings - Fork 10
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
Enhancement: Prim Hierarchy Delegate and default prim / variant set features #21
Conversation
BigRoy
commented
Nov 26, 2023
•
edited
Loading
edited
- Add a style delegate to draw whether a prim is default prim DFT, has references/payloads REF and/or has variant sets VAR
- Fix renaming of prim moving the prim to a different index among siblings - fix Bug: When renaming Prim in the Prim Hierarchy it moves it to the end of the siblings #15
- Allow to add reference or payload to a prim
- Allow to add variant set to a prim (it doesn't yet allow any other authoring in that regard)
- Add "Move to layer" functionality to Prim Spec editor
… Prim into menu of its own
…ange only reparent Fix #15
… on Prim + allow to add reference or create variant set
…ype name in Prim Spec Editor
Note: If moved to a PrimSpec path already existing in the target layer then any opinions on that PrimSpec or it children are removed. It replaces the prim spec - it does not 'merge' it into an existing prim spec. This is an implementation and thus fix for #20
…layers across multiple parents that are also shared - make the key unique by the full parent layer stack to ensure uniqueness
…tic equivalents This fixes an issue where the first call to `get_prim_types_by_group` would send out a bunch of `pxr.Sdf.LayersDidChange` notices
Note: The view now also shows the pseudoroot - it's up for discussion whether that's preferred or not
@Sasbom @MustafaJafar any chance you could give this PR a go and see what stands out? The Otherwise, this is roughly what I've been running to test with: import logging
from pxr import Usd
from qtpy import QtWidgets
from usd_qtpy.editor import EditorWindow
from usd_qtpy.style import load_stylesheet
DEBUG = True
if DEBUG:
# Clear all root logging handlers just to ensure our basic config is used
root = logging.getLogger()
if root.handlers:
for handler in list(root.handlers):
root.removeHandler(handler)
logging.basicConfig(
format=(
'%(asctime)s,%(msecs)03d %(levelname)-8s '
'[%(filename)s:%(lineno)d] %(name)s.%(funcName)s() '
'%(message)s'
),
datefmt='%Y-%m-%d:%H:%M:%S',
level=logging.DEBUG
)
filepath = r"C:\Users\User\Desktop\shot\shot.usda"
stage = Usd.Stage.Open(filepath)
app = QtWidgets.QApplication()
dialog = EditorWindow(stage=stage)
dialog.resize(1400, 800)
dialog.setStyleSheet(load_stylesheet())
dialog.show()
app.exec_() |
… it was running to early and the bug was actually in teh filtering of resynced paths on objects changed
I tried all the features, caching seems to be working OK! However, the styling still has some issues here and there, I found out that from Win-10 onwards, "Base" Courier isn't present by default, it has been replaced with "Courier New" usd-qtpy/usd_qtpy/layer_editor.py Line 606 in f7235b0
and usd-qtpy/usd_qtpy/layer_diff.py Line 63 in f7235b0
to text_edit.setStyleSheet('* { font-family: "Courier New"; }') On my system helped, so it seems that some font environment checking for "Courier-like" fonts would be good, If all else fails, we should probably include a font backup! I find myself REAALLLY wanting:
after all of this, now it looks so neat and refined! |
Could you try again with the latest commit 936c6c8 ?
That'd be great - yes. A full blown USD editor. There goes the idea of just making some useful USD Python Qt widgets. We'll be competing with Maya next ;) Anyway, thanks - those would definitely make for good issues to track interest in those. Will create those in a bit. |
Done did! It works as intended. Looking good. Also: After reading the prim hierarchy model and cache and how they interact, Since we are allowing edits, are we going to support undo and redo? It seems that the entire tree is cached in one HierarchyCache object, so I wonder if we could use this to implement an undo/redo stack. This would further improve the editability down the line, but we could also implement this using some way of collecting differences after each operation, since I reckon most operations aren't destructive (if they even can be, in USD). Either way, that'd be something to explore for a further future. |
Have thought about that but oh boy - that's a whole different can of worms. Having a global Other only option I think is to wrap any change we make into a dedicated "command" that keeps track of the changes to undo/redo accordingly - but admittedly, I'd argue it's out of scope unless we're aiming to design a full blown USD Editor to compete with DCCs. Anyway, will also create an issue to track this - but I wouldn't take it as a high priority. |