• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
0

api - new methods

Community Beginner ,
Sep 28, 2023 Sep 28, 2023

Copy link to clipboard

Copied

please consider adding this stuff to the api, thanks

```

All of this i know is pretty much GUI stuff. But its deffo cool stuff and would give us a lot more variety when letting the creative juices run wild.
Im sure someone else would probs like other things ive not mentioned/not generally related to GUI.
 
 
Some things i think we should be able to do:
 
1) subclass nodes, graph scene
why?
so we can access the following methods:
mouseMoveEvent
MousePressEvent
MouseReleaseEvent
etc
..or at least provide a callback for this.
 
2) map mouse cursor to scene(graph) pos
When i have a node follow the mouse cursor, theyre not aligned.
Its due to mouse cursor going off monitor coordinate system and node going off graph coordinate system so need a method like mapCursorToScenePos() which handles the offset conversion for us.
 
3) change node outline color,
   mark a node as selected so the outline actually appears,
   change a connections color / thickness.
   change the main ui theme, font, color, etc. i get it that you might not want to allow us to change the look of designer as a theme can be as part as much of the brand as the name, so i understand if that one isnt implemented.
   change color of dot nodes
   change color/font of frame, comment, node input/out text
   change the actual size of a node.
 
4) set a name for dot node portals
 
5) make comments resizable
 
Some things i think we need:
1) a local coordinate system for the graph scene view. 
what does this mean exactly? well, with the node.setPosition(float2(0,0)) approach, that should be thought of setting a nodes pos globally.
 
Would be nice to be able to also do node.setPositionInLocalSpace(float2(0,0)). 
This then allows us to place a node at the center point of the "viewable" graph viewable as in the actual section of the graph that is literally viewable, so no matter how zoomed in i am on any portion of a graph, placing a node at pos (0,0) on a local coordinate system it will place it in the center still).
 
We are most of the time working with the graph panel not-maximised and constantly moving the graph around with no indication to where (0,0) actually is. and with the current setPosition(float2(0,0)), the node could well be placed "out of view".
So a local coordinate system for the actual visible part of the graph would be an absolute godsend.
 
 
Add the graphs x & y coordinates along with left-side and top-part of the scene grid so regardless of the size of the graph panel as well as how zoomed in/out we are, we'll always know what coordinates are "in view"(this feature is a a pre-2010 3d editor program so shouldnt be too hard for you guys to implement).
 
I thought the above approach might work n save time but it isnt actually any use when placing stuff via script. sure its handy for delevopment mode during testing so users can quickly see exactly what coordinates are in view, but its not useful for dynamic entity placement.
This is where a local(viewable) coordinate system would be epic cause the program would know the graph panel size, its zoom level, and off that it would map out a temp coordinate system. so node.setLocalPosition(float2(0,0)) would place it exactly in the center of the graph regardless of its size/zoom level.
 
 
2) Lastly a cool feature would be able to add a graphical line(horzontal and vertical) that we can use for dividers. Portal node is a huge game changer (congrats on that!) in terms of graph layout/structuring and i personally would love some kind of divider. A simple straight line of which we can decide on its:
color,
thickness,
starting pos, ending pos. to set its length
 
 
oh and maybe the ability to add a dot node along a connection line(just like when you hold down Alt and Left-Click on a connector). Also the option to merge multiple dot nodes(i.e say you have 5 diff nodes each with its own connected dot node. of which all of these dot nodes are portalling to another node, so being able to merge them would be cool. atm i simply create all the dot/portal nodes and then hold down shift and manually merge them).


I am really into plugin creation and have a ton of ideas of which quite a few utilise non-existant methods so please consider implementing the above for us Pluginists!

many thanks!
Idea No status

Views

85

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
4 Comments
Community Beginner ,
Sep 28, 2023 Sep 28, 2023

Copy link to clipboard

Copied

You notice that when you copy n paste graph ents (nodes/objects) it doesnt actually position them exactly where the cursor is? which suggests that you guys havent even implement a mapCursorToScenePos() core function which is strange. definitely hope to see that & other things in an api update in a not so distant future.
 
And why is such a thing important? well 1) being i purposely position my cursor away from scene ents specifically when pasting a new frame to ensure it doesnt disrupt other scene ents. its annoying having to reposition scene ents after the pasted frame got positioned behind said scene ents and 2) it'll be very handy for api stuff

Votes

Translate

Translate

Report

Report
Community Beginner ,
Sep 28, 2023 Sep 28, 2023

Copy link to clipboard

Copied

can we have a method that allows us to get & set the portal node name.

Votes

Translate

Translate

Report

Report
Adobe Employee ,
Sep 29, 2023 Sep 29, 2023

Copy link to clipboard

Copied

Hello Phil,

 

Thank you for taking the time to share these suggestions. I have merged your suggestions in other posts into this thread.

I am happy to discuss your suggestions, as a fellow Designer plugin developer! 🙂

 

An API method for mapping viewport position to graph position – and the other way round – is definitely possible, and something we actually have discussed in recent months. I personally would also have a need for it!

As for setting the name of a Dot node ("sbs::compositing::passthrough"), this is indeed also missing.

 

Implementing callbacks for mouse events in the Graph view is not congruent with the use cases we envisioned for the API. The same applies for selecting nodes. The actions made available when nodes are selected should be done directly through the API without the need for selecting them in the first place.

An important connecting block for this is a way to quickly find specific nodes. Naming nodes with a user-defined name is a possible way to approach this. We have no plans to share for facilitating these operations at this point in time.

That said, I am interested in the actions you would like to take through the API after selecting nodes. Feel free to share!

 

Now, regarding your other suggestions:

 

  • Change a connection's color/thickness: That cannot be done, because both are meaningful attributes that convey the nature of the data they transmit:
    • Yellow: Color (RGBA) image;
    • Gray: Grayscale (Luminance) image;
    • Thin: 8-bit integer bitdepth;
    • Thick: 16-bit integer, or 16/32 bit floating point bitdepth.
  • Change the main UI theme, font and color: These are designed to be consistent with the Substance 3D ecosystem of applications. That being said, the installation directory includes a style.qss file that lists the appearance properties of Designer's interface. However this is not recommended nor supported, and you may perform these edits at your own risk.
  • Change color of Dot nodes: color-coding these may indeed have some uses, especially when used as portals. In the meantime, you may put them in small unlabelled frames.
  • Change color/font of frames and comments: A frame's color can already be edited through its properties. As for other appearance attributes: stay tuned! 😉
  • Change color of node input/output labels: These are controlled by the overall interface style.
  • Change the size of a node: Nodes automatically adjust in height according to their number of connectors. Resizing them manually is not planned.
  • Change the size of a comment: We have discussed this recently. I will add you feedback to the discussion.
  • Display the coordinates of the graph area framed in the viewport: An interesting suggestion, that could be useful as an option!
  • Divider graphical object: Can you share a mockup of a relevant use case for these? I understand the concept yet I am interested in the situations in which such a tool would be valuable to you.
  • Add a Dot node on an existing connection: That is already possible! Hold down the Alt key and click anywhere on a connection.
  • Merging Dot nodes: Again, could you share a mockup of a relevant use case? There are connection rules to be considered here.

 

I hope this addresses all your suggestions and opens the discussion in an exciting way!

 

Again, thank you for taking the time to share these, they will be discussed in the team. Feedback is always valuable to us!

 

Best regards.

Luca Giarrizzo | QA Analyst, 3D & Immersive | Adobe

Votes

Translate

Translate

Report

Report
Community Beginner ,
Sep 30, 2023 Sep 30, 2023

Copy link to clipboard

Copied

LATEST

Hi Luca Giarrizzo,


Change color of Dot nodes: color-coding these may indeed have some uses, especially when used as portals. In the meantime, you may put them in small unlabelled frames.

 

I am currently doing this.

 

Change color/font of frames and comments: A frame's color can already be edited through its properties. As for other appearance attributes: stay tuned!

 

I mean't the text color.

 

Divider graphical object: Can you share a mockup of a relevant use case for these? I understand the concept yet I am interested in the situations in which such a tool would be valuable to you.

 

Just for time's when one prefers to segregate nodes w/ using frame's.

 

Add a Dot node on an existing connection: That is already possible! Hold down the Alt key and click anywhere on a connection.

 

I mean't via code.

 

Merging Dot nodes: Again, could you share a mockup of a relevant use case? There are connection rules to be considered here.

 

That's ok, can scrap this idea. No longer needed.

#######################################

An API method for mapping viewport position to graph position – and the other way round – is definitely possible, and something we actually have discussed in recent months. I personally would also have a need for it!

As for setting the name of a Dot node ("sbs::compositing::passthrough"), this is indeed also missing.

 

Implementing callbacks for mouse events in the Graph view is not congruent with the use cases we envisioned for the API. The same applies for selecting nodes. The actions made available when nodes are selected should be done directly through the API without the need for selecting them in the first place.

An important connecting block for this is a way to quickly find specific nodes. Naming nodes with a user-defined name is a possible way to approach this. We have no plans to share for facilitating these operations at this point in time.

That said, I am interested in the actions you would like to take through the API after selecting nodes. Feel free to share!

 

As for the callbacks. Could you not add a couple callback methods for cursor entering/leaving a node of which we could register just like we do with one of the stock methods: `registerGraphViewCreatedCallback`

Id personally love to have a custom qt pie menu appear around a node when cursor enters a node. Would need a couple things for this:
1) enterEvent callback
2) qt widgets to be able to be placed directly on the graph((wouldnt need to worry about saving the widgets in the sbs file. They'd only be on the graph during its curr session).
I love UI stuff and always thinking of new ways to make things interractive in different ways.

 

I think we should be able to toggle the graphs permanent header toolbar too.

 

And lastly. i would love to be able to create custom workspaces like you can in blender.
-Sometimes im making a material so i want the 2d/3d panel on view. Other times im just testing my ui plugins of which i dont need them. I know we can just close/reopen the panels adhoc and theres some kind of default designer ui layout storer thing but there are times where im still having to constantly open/close & also resize the panels when working on different things. So workspaces would be great where they save the panels location and size.


In "short".. lol.

I think sometimes its best to just add as much to the api as possible (even if  you cant think of a gd reason/need for it) cause the more freedom we have, the more our creative juices can flow.

When i was a kid, like most, played with Lego. A fair amount of variations for sure.
But then i discovered another toy called Knex and my mind blew up with all extra possibilities of things i could create. 
..When i think of the designer api, i think of lego, not knex.


Regards, Phil

Votes

Translate

Translate

Report

Report