#1 - When I click on a job, I get this node view layout.
#2 - The layout I want to have, but every time I un-select the job in the job list and go back to the job, I end up back at #1.
For many jobs with many dependencies, it makes the Node View hard to work with.
We’re aware of this issue, but we’re not sure how to address it at this point. The only solution that comes to mind is to cache the layout for every job…
If we were to go down that route, I guess we would want to save the layouts locally when the monitor is closed so that they persist between sessions.
Save the node layout in the job properties but not expose it?
But then that means that someone could potentially change your layout. Not sure if that’s a big deal though. Also, I’m not sure at this time how much info we would have to store with the job to restore its layout.
I dont think globally similar layouts are a requirement, global job property seems like a redundant thing to put in the database. I’d vote for local temp files that could be cleaned up with a threshold setting by a monitor cleanup process (if job doesnt exist, delete the layout, etc)
I hear you guys…just thinking about something like Nuke’s DAG. You arrange nodes, save the Nuke script. Another user opens it and the DAG has the same arrangement? If another user hits RESET on your node layout, then so be it? Is this a requirement? Good question! One thing I do know, is the node layout does need to be ‘remembered’ somehow. Do you just hold the node layout information in memory and it’s cleaned up when monitor is exited?
Good point about users modifying Nuke scripts! If the amount of bytes required to store these layouts is relatively small, it would be nice to store it in the Database with the job object. Or maybe it can be broken off into a separate object? We’ll definitely consider all possibilities when start working on a solution to this problem.
Thanks guys!
Ryan
The thing I notice about caching also is what if new dependencies are added or a user clicks on a different node in the same dependency chain would we want it to show the same way?
For how it is base drawing currently that is an algorithm I kind of thought up on the spot that would allow us to draw all of the nodes without them overlapping. With really interconnected jobs it can draw fairly poorly, that job is a great example of this. At some point I would like to go back to it to see if I can improve it but for now I went with the simple no fail method.
Grant
I think this is a really good example of what I’m thinking…should work in any version of Nuke (PLE, etc)
- you should see all the nodes get automatically aligned. Nice.I can see how this would work well when there are limited numbers of inputs/outputs like in nuke however we have an arbitrary number which makes it more difficult, and in fact nuke does not handle it well.
A quick example of that is create multiple color correct nodes as you did and have them all connect to the viewer node (i tested with 4 which is enough to get my point across)
Align them all and bam you have lines going directly through other nodes so you have no idea which are connected, worse off in there system if you drop some nodes in the same location they will change your graph by auto connecting
I am not saying it is a bad system, we just need to find a good algorithm that will work for our needs (which are different then them)
Grant
