Hi Dimitry,

Had a look at the vids for RD 0.1. Looks great, but one of the things that stood out for me is how slow it is currently to apply the constraints to the Rhino elements. I am wondering how RD stores its constraints info.

In future,

1. Can the constraints and objects be stored separately? I guess we are looking for components (with constraints attached) stored in a catalogue (say the shelves in the cabinet vid) that can be dragged and dropped onto other components. This would save a lot of time. I guess, there will need to be a popup menu to ask the user to choose the appropriate constraint or/and connecting component.

2. Can the components be copied with its constraints? I imagine most users will want to copy the constrained component and not re-constrain every time. Will we be able to array them? Think of lots of shelves. I think this will eventually lead to a history 'stack' as one of the other users mentioned. I hope that there isn't anything that will prevent this later as it is a real time saver. See RhinoParametrics and many other MCAD apps like IronCAD.

3. Can there be a scripting interface to handle the constraints? I think you were one of the authors of Nemo+? Going back to the cabinet example, it reminds me of the way CityEngine could work if Peter Wonka has his way. If the overall wood frame can have named faces, inserting the shelves would be much quicker if the constraints could be automatically selected by an inference engine using an established rules base or grammar, or rules based scripting. I think inferencing is being looked at as part of the Sketchup DD plugin?

4. Will there be more visual 'glyphs' based access to editing the constraints? ACAD 2010 can display the type of constraints next to the CAD elements on screen. Constraints can be suppressed by clicking on the identifying glyph. Drag and drop or copy and paste constraints between elements would also help speed things up.

5. Can the RD manager display the constrained components as well as the constraints? Mark Gross' old programme CoDraw had a very visual way of displaying the constraints and their components. Also, is there a way to give the user some feedback on the order in which the constraints are solved? I know that this will probably be dynamic, but it will be useful to help the user limit / break up over large dependency sets.

6. Can a constrained assembly be converted to a series of imperative generative commands like the scripts that Grasshopper produces? I know that some intelligence will be lost, but perhaps this can be recorded? I imagine some dimensional constraints are really just fixed parameters that can be translated as an imperative style value linked to a CAD command ?

Cheers !

Thank you for these useful suggestions, dseah!
I'd like to comment your topics and will appreciate your feedback.

1. We didn't think a lot on this subject. For sure, it is one of possible ways of evolution of our software, but probably not a part of version 1.0. Can you give us some examples of similar functionality in other CAD systems?
   
2. It is definitely a "must have" feature. It will be implemented in one of the forthcoming beta releases before v.1.0.
   
3. We are now working on a kind of scripting interfaces for internal testing. Not rule-based, of course. This is far beyond our current vision of v.1.0 functionality. However, it is a good idea for future evolution.
   
4. Will working on that. We have to learn more Rhino features and prototype some ideas before making a particular decision on this topic.
   
5. This feature is listed in our nearest plans.
   
6. What practical usage of such a functionality is supposed? As you noticed, there is not general way to translate a set of constraints with internal loops (dependencies) into a sequence of modeling commands, so before analyzing this complex problem we have to have some good motivation for it.

1. Other examples? Not sure, I think IronCAD smart parts automatically tries to match / align the incoming parts when it is dragged onto another part. I think Kubotek Keycreator also has something similar. In many ways, CATIA's Imagine and Shape, which is based on Attilio Rimoldi's Functional Modelling, seems to be able to make discrete parts behave in a defined way in relation to each other that is not history dependent. This make it look like constraints are used.

2. See http://www.public.asu.edu/~pwonka/Publicat...ture_SG2003.pdf for an impression of how naming / rules can be used to guide or automate constraints selection. Scripting, with or without rules based working, I think is important because modern CAD / computational design is really about setting up relationships between CAD elements in an intelligent and extensible way. Constraints are a type of relationship and needs to be able to be accessed / manipulated via scripting.

6. Interoperability + Scalability.

Actually, the question I wanted to ask is whether a scripted construction could be redefined in terms of constraints. But, you are coming from the constraints modelling world so I tried going the other way instead.

At the moment, I think there are three big approaches to capturing design intent / relationships in CAD:-

1. Scripting / history based
2. Rules based (using a inference engine + rules base) / agents
3. Constraints modelling

MCAD programmes like CATIA encapsulate constraints modelling in sketches or as as 'mates' in assembly design, but also mix in history based feature modelling. Scripting or dataflow type modelling extends the history based implicit feature based modelling by allowing the user to add bespoke instructions. I think the way constraints defined geometry interacts with other geometry is through a 'black box' approach where inputs and outputs provided does not allow much access by scripting. It would be useful if constraint relationships could be part of a script and vice versa.

Scripting I think will always be faster and therefore more scalable than constraints modelling because it does not have to do any solving. I think It would be useful if a set constrained geometry could converted into a construction history. For example, two lines, A & B, constrained by a coincident and perpendicular requirement can be approximated by a history based script. I.e. Draw line A, from vertex (A,1) draw line B using the 'draw perpendicular line from point' method. The disadvantage of this is that manipulating B will not ensure the perpendicular condition when the script is re-run. Ideally, the script / history stack could be re-ordered dynamically depending on what element the user was manipulating. The reordering would be informed by the type of constraints relationship was selected.