Hi,
Is there any progress on getting a marginally less annoying graph layout tool?
I'd settle for one that was totally manual (i.e. didn't sporadically jump all my manually laid out nodes back to starting positions)
Ideally a graph to dot converter would be the best way to do it in the short term, that way dot can do all the layout and I can inspect it for exciting ideas and then do the layout myself manually
(unless of course you have a good graph ready to go right now!)
Ben,
We have done and are still doing lots of researches on the incremental auto layout but so far haven't yet found a good one. If you or anyone else have any information to share, it will be appreciated.
-Xun
HI Xun,
Have you looked at CityEngine 2010's new visual programming interface? Its pretty impressive. See the tutorial vid titled Rules base Models at the Procedural website.
It has some nice features:
There is a dynamic update between the four input views:
a. Script: text. Has 'intellisense' type completion.
b. Symbolic: Blocks of script, connected by 'wires'. Not sure if the wires can be manipulated to change the 'go to' propagation path like Grasshopper, XSI ICE etc.
c. Model Hierarchy: Shows the object configuration. Selecting an object in this view, makes the symbolic window show the dependent code 'graph'.
d. Geometry Viewport: Linked to the other views. Selecting geometry here, changes the focus in the other views. Also nice that object related orientation info like local ACS triads are gylphed on screen.
If we think of the views as nodes in a GC graph, the way that user input in one view propagates changes in the other associated views suggests that there is a cyclic relationship between them, that needs to be managed.
Actually, its probably just old fashioned 'event driven' main loop-style programming, but I think it raises some questions about how GC's DAG nodes need to function in an 'event driven' environment aka Usability. Probably why Maya has dependency nodes that are not DAG, in addition to DAG nodes?
I remember reading that a lot of OO software tools were originally developed to deal with dynamic user interaction associated with OS GUI's. User interaction is not uni-directional and acyclic. Maybe GC should look at a graph that accommodates events, like a Petri net? One example.
There was some research done at CMU, using Mstn ProjBank that dealt directly with OO tools that were user-task focused, about the same time GC was being developed, I think. The CMU examples rely on UML-style diagrammes to model user interaction. This guy at MetaCase thinks that he has a quicker (and more interactive) way to providing a UI. The Nokia phone example reminds me that for GC to be really useable and scalable, it needs to be able to deal with user interaction in a much better way.The GC DAG nodes will need a UI 'shell' (?) that is not 'acyclic' like the CityEngine views example above? Like Maya, the end user will need to be able to access this non-DAG world as part of his 'scripting', and therefore should be part of the 'symbolic' graph.
GC talks about 'nodes' and 'transactions', which are comparatively static. Maybe it should really start to think in terms of 'events' and 'behaviours'.
Lots of apps like Sketchup, AutoCAD, Catia etc have 'observers', 'listeners', 'reactors', 'containers' that are used to propagate algorithms/commands that do not involve DAG's. More radically, this guy has been arguing for an 'event-based programming' style based on an declarative 'algebra of events'. Maybe, there is a common framework here that can consolidate GC's data-driven ways with Mstn's event-driven environment.
Would be great if the GC graph could provide Petri Net style 'control' or 'port' nodes that are 'event transaction' aware, and end user programming friendly. I suppose its already starting to happen with Element Sensors. Someone recently mentioned that working with GC is like or should be like 'sketching with parameters'. I think this a contradiction is terms at the moment, as GC is not very event aware, while a big part of manual sketching is.
It would also help GC become more scalable. Scripts are supposed to capture design intent, but the way only the resultant 'dumb' geometry was thrown over the wall was more about GC / Mstn's limitations than real world requirements. The scripted 'design intent' needs to be 'live' within a network of intelligent objects to be really useful. No real world project can be defined / developed as a single monolithic 'DAG' graph, with unbreakable propagation / total regens as a precondition. Event aware 'control' nodes could provide a user friendly way to manage and channel the necessary data propagation. Again, I guess this seems to be changing.