Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Houdini: Publish any ROP node (Generic Creator) #2
base: develop
Are you sure you want to change the base?
Houdini: Publish any ROP node (Generic Creator) #2
Changes from 3 commits
5b7fdfd
b5d5e09
421adbf
a267cd2
d6d7e9e
5b6f0ec
46da010
83e70d5
e74903e
7e9bbd0
6934ba6
3791df1
6126888
c14710c
36c65ad
5e5cef2
930615b
db57f1e
21ab75e
adf9236
ddcf908
41dfc25
fae1a89
3f70401
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Why it's not stored as json string? (talking about
"publish_attributes"
and"creator_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.
So that the attributes are actually accessible as options on the node for the user to click. We want them to be like native houdini parms so houdini users can do with them using houdini logic whatever they want - that's the whole point. ;)
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.
So
"handleStart" = 0
will become"handleStart": True
(as an example).BTW considering in progress feature on create context: "Value change based callbacks to update attribute definitions or values." will break this assumption that you can freely change create and publish attributes with no consequences.
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.
Does exposing these publisher UI attributes on the node actually make sense?
Yes, makes sense. There's just a plethora of reasons why one WOULD want to actually exploit this type of full control in Houdini but I'm not confident whether those are production use cases that really make sense over time.
@fabiaserra @krishnaavril @MustafaJafar how much use would you say there is in actually having all these publisher UI options exposed as separate Houdini parms? Like, would you really ever have those parms reference some other attribute in a production scenario? Or is setting those via the publisher UI sufficient (it would allow us to create more dynamic UI over time without 'unexpected changes' coming back from Houdini).
See here for a screenshot with some of those exposed attributes.
In this case in particular the Creator Attributes and Publish Attributes
Luckily those are not exposed like that in Houdini 🙈 - but yes, that definitely points to a crucial bug that would need solving. However, 'setting' them om the attribute definitions in publisher UI themselves would then automatically turn that back into 0 and 1 so it may be 'ok' but it's definitely illogical code. Thanks for point it out!
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'm not sure I understand the questions but let me try explain why:
What do you mean by "separate"? If you just mean if there's a point on having these options exposed on the Houdini nodes natively... yeah, there's a lot of use, it allows artists to use Houdini workflows and not be limited by another UI, making it very easy entry point for Houdini users (the advanced options are probably confusing and irrelevant for anyone though?)
Potentially, that's the beauty of Houdini
Not as it is, but not because just of the UI setting parameters... the whole publish framework being coupled with the export of the nodes is very limited IMO as I have already explained a few times
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.
Additionally, the node parameters and the publisher attributes are synced.
From the node to the publisher and from the publisher to the node.
That logic is implemented in
collect_instances
by creating the instance manually and adding it to the context andupdate_instances
by theimprint
method.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.
Hello @BigRoy ! I think it was completly fine having properties in ayon publisher window, Honestly Me and my teams uses only visualise purpose, there is no change scenario seen in production from our end. (I was writing this coz we tested this rop publish when houdini is in core)
Can we write a logic where ayon filters the rop node inside any studio specific otl?
This will help to identify what kind of files will be writting(pointcache/renders) by node or by the location of node we adding(obj -> pointcache/usd, stage-> Usd/USD render rop), this will help on creating generic for any otl(without we hardcoded in the script), this should essentially open the possiblity of adding generic for any custom otl with no code changes(or a ayon frontend parameter will be good too, where we mention our node names and parameters). we also know studio uses there own otls for render, we can put in the documentation that to add duplicate there parameter and name it as a picture parameter, thus it refers the path and publishes.
Let me know if this make sense.