Hello,
I know it might be too early to propose features while the tool is still in the development stage… but anyway.. some generic ideas and concepts that could fall nicely into the PDG framework infrastructure:
1. Add *LR* (Left to Right) horizontal graph representation style (example: houdini's material network graphs)
2. Add dedicated generic ‘language agnostic’ code building/generating nodes concept (example: houdini's Principled Shader encapsulated node graph and its vex code generation) - i.e. allow procedural and adaptive shading/code network building.
3. Add custom context definition/segregation for PDG nodes (example: houdini's ch/obj/mat/etc. contexts - each contexts has *LR* or *TB* (Top to Bottom) layout style)
Those features are all existing in Houdini at the moment but could have many applications in non-houdini based pipelines.
–
Thanks,
Nick
PDG feature proposal
2480 6 0- N G
- Member
- 3 posts
- Joined: Jan. 2016
- Offline
- kenxu
- Member
- 544 posts
- Joined: Sept. 2012
- Offline
- N G
- Member
- 3 posts
- Joined: Jan. 2016
- Offline
kenxu
What would be the advantage of having a LR graph over a TB one in your view?
Visually Material Graphs / Shading Networks are better represented/read with LR graph layouts.
Also if applicable to shading / code generation horizontal layouts allow for more convenient parameter in/outs
connection. An example of such graph in Houdini is RIS Shader Network
Still tasks and processes are better read with TB layouts.
What I propose as a feature for PilotPGD (as a stand alone tool) is to keep the ability to build and embed into the TOP networks smth. structure-wise similar to RSL Material (RSL code generator) or Principled Shader (VEX code generator) graphs.
PS. What I describe above is currently possible to implement with Houdini + PDG bundle but not with PilotPDG itself.
Thanks,
Nick
- Ostap
- Member
- 209 posts
- Joined: Nov. 2010
- Offline
- anon_user_40689665
- Member
- 648 posts
- Joined: July 2005
- Offline
- DASD
- Member
- 453 posts
- Joined: Feb. 2013
- Offline
I would suggest an alternative solution:
The main problem is that nodes cover each other, because the amount of tasks makes the node bigger.
So I suggest you make an expanded node a fixed size (that can be tweaked by user).
If there is more tasks, you get a scroll bar. Also if you just hover your mouse over the node and scroll, it should also scroll through the tasks.
The main problem is that nodes cover each other, because the amount of tasks makes the node bigger.
So I suggest you make an expanded node a fixed size (that can be tweaked by user).
If there is more tasks, you get a scroll bar. Also if you just hover your mouse over the node and scroll, it should also scroll through the tasks.
Edited by DASD - April 11, 2019 03:34:08
- kenxu
- Member
- 544 posts
- Joined: Sept. 2012
- Offline
-
- Quick Links