Hi Kanzure,
I was wondering about the "explicit constraints" in particular. What
does this mean, and can anyone give me an example of another CAD
> software package that implements that, or how it would be used, or
> something? Also, what about this "Math Virtual Machine", what does
> this /mean/? So, presumably, users would type up some sort of
> mathematical expression which would state/specify constraints? When
> I've used parametric CAD systems before, I never had to do that- or
> I've never seen those options- but it's entirely possible that it's
> very important and something that I should know about.
Now take two spheres and you might want to guarantee that they are always
perfectly tangent to each other -- that'd be an explicit constraint. Or
consider just the one sphere and say that you want to require that the
sphere always have a radius between 1 meter and 12 meters -- another
explicit constraint. Those constraints, whether implicit or explicit are a
series of expressions that associate with and refer to geometric entities.
The MVM he refers to there is a system for evaluation those expressions and
constraints.
This is pretty common in most CAD systems where you can fully/under/over
constrain a given model. Some even give you a convenient little red light /
green light to let you know when you're fully constrained.
Implicit constraints as Sean explained are basically constraints implicit
in the definition of each primitive. It might be simple like
perpendicularity, parallelism, equality etc. to more complex cases (tgc for
instance) Explicit constraints are effectively
1. constraints between primitives ( variables of primitives : radius of
sphere == radius of a cone for instance) or
2. constraints between variables of the same primitive (consider a cone
whose volume is fixed : height is dependent on its radius squared)
These two cases can be unified into saying constraints between "Variables"
which are not necessarily involved in the definition of the geometry.
Regarding MathVM : Our idea of constraint expression is to support a large
spectrum of mathematical expressions in defining the constraints. This is a
very critical part of the actual utility of constraints since otherwise we
would be limiting the type of constraints defineable. For this purpose we
could take various approaches. Lazy functions seem to be a good bet. The
idea is that the solver would call the MathVM to evaluate the constraint
expressions while traversing the hypergraph modifying the state of the
constraints.
If you have used CATIA for instance using f(x) tool u can specify quite
advanced expressions between primitive parameters.
It has been many years since I've worked with the boost library.
> However, recently I have been working in the Automated Design Lab here
> at the University of Texas at Austin, on projects involving generative
> grammars and graph grammars for mechanical engineering problems. For
> instance, some of the recent work is in the automated design and
> optimization of gear trains; another fellow works on linkage design,
> and another on product disassembly sequencing.
>
Regarding BGL: My primary thoughts were the advantages of not having to
recode various traversal alorithms and boost being a very good container
library in a sense it is a very sensible approach to code reuse. Spirit and
Phoenix libraries are very helpful in terms of parsing of the expressions i
mentioned above.
There's a few classes there for the representation of graphs. The way
> that graph grammars work is by search-and-replace, more or less. Each
> grammar rule has a left-hand side and a right-hand side. The left-hand
> side represents a subgraph that it should 'match', and the right-hand
> side is the replacement. So, there's a 'ruleset' for different
> domains- a ruleset consists of a list of different grammar rules. A
> ruleset exists for linkages, for product disassembly, gears,
> electronic filter circuits, etc., and maybe one will be implemented
> for parametric constraints? The way that this works is that a 'seed
> graph' (input) is given, and then it's recursion over the list of
> possible rules that apply to it, and for each one that matches, that's
> a branch that is taken, and the branches are explored either in a
> breadth-first manner or depth-first manner, until there's no more
> manipulations possible to the graph, at which point you have a list of
> solutions to the original problem. Now, I'm not entirely sure about
> explicit constraints and weird grammar notations for constraints, so
> that's partly why I asked that question previously :-) so that I might
> be able to see whether or not GraphSynth code (as opposed to the boost
> library) would be appropriate here.
>
> GraphSynth-related references- full bibliography (in BibTeX):
> http://heybryan.org/books/Manufacturing/campbell/bibliography/campbell.bib
>
Regarding Graphsynth, regarding the query about the conditional constraints,
your suggestion was to specify the same in the Grammar.
Let me just restate the case here:
Vertices : A, B, C, D ,E and F
Constraints:
1. A perp B
2. C perp. D
3. E perp. F if A perp. B and C perp. D
else E parallel F
I am wonering whether by that you meant specifying a ruleset ( hope i am not
messing up on Graphsynth terminology here) specifying if you find A perp. B
and C perp. D make E perp. F. But there maybe other parts in the graph ( say
X perp. Y and Z perp. W which need to be connected in a similar way to T
perp. U) What I am trying to say is , don't you think the arc object
definition as per the xml here(
http://www.me.utexas.edu/~adl/graphsynth/graphs.htm ) is insufficient to
take into consideration such cases. Could you share the xml and ruleset for
the above case if it is possible ? My idea is that the designgraph should be
completely able to reprsent the particular design with the ruleset there
being to do the actual "Evaluation" and "Generation". Am I wrong in this
regard?
Also regarding an example of a logical constraint ( see again tgc implicit
constraint 4), though i feel this might be reprsentable in Graphsynth.
A pattern based search for constraints and associated graph reduction based
solutions is very effective for various applications as graphsynth shows
with its breadth. But do you think it has any clear advantages in terms of
geometrical constraint modeling ? Also, are there any results on the
scalability ? Compared to various discrete problems ( circuitry for instance
or linkages ) performance is going to be a major issuing when searching a
large solution space.
I understand that you are comfortable with Graphsynth. But do you think it
would have any significant advantages over
1. brl-cad coding our own solver ( not transforming graphsynth code for
instance)
2. utilization of some generic constraint solvers like minion.
3. utilization of geometric constraint solvers.
>
> presentations:
> http://heybryan.org/~bbishop/docs/repo/presentations/<http://heybryan.org/%7Ebbishop/docs/repo/presentations/>
> (older files are better, and I sincerely apologize for the pptx file
> format- some I've been able to convert to ODP, however)
>
> maybe this presentation would be most helpful:
>
> http://heybryan.org/~bbishop/docs/repo/presentations/Wed3-KurtogluCampbell-From%20Black-Box%20To%20Component%20Selection.odp<http://heybryan.org/%7Ebbishop/docs/repo/presentations/Wed3-KurtogluCampbell-From%20Black-Box%20To%20Component%20Selection.odp>
>
> ** Relevant diagrams- **
>
> seed graph example
>
> http://heybryan.org/~bbishop/docs/repo/2008-12-11/2008-12-11_waterlifting.gxml<http://heybryan.org/%7Ebbishop/docs/repo/2008-12-11/2008-12-11_waterlifting.gxml>
>
> screenshot of that example in GraphSynth
>
> http://heybryan.org/~bbishop/docs/repo/2008-12-11/2008-12-11_waterlifting.png.PNG<http://heybryan.org/%7Ebbishop/docs/repo/2008-12-11/2008-12-11_waterlifting.png.PNG>
>
[Offtopic: Interesting :) Are these energy based constraints ? What are the
coloured edges ]
> One idea that I suggested to 'madant' over IRC yesterday was the idea
> of representing constraint problems as a seed graph in GraphSynth by
> having two types of nodes- those nodes which represent an object in
> BRLCAD's dot g database, and those nodes which represent the type of
> constraint (parallel, perpendicular, etc.). So, any two nodes that are
> connected by a node of label 'parallel_$unique_ID' would be required
> to be parallel, and then some other labels would specify the xyz
> coordinates (or something), which means the graph for two
> perpendicular objects constrained to one two dimensions would be
> "objectA <-> perpendicular_1 <-> objectB" (in reality, there's more
> than two dimensions to deal with). The work that would need to be done
> is a ruleset for manipulating those graphs by recognizing the
> scenarios of perpendicularity and parallelism, and other types of
> constraints, and consequently find all possible ways of solving those
> constraints- which I suspect will probably involve a subset of matrix
> math rules or vector math rules.
Refer to the example i mentioned above.
> And again, the idea would be that
> GraphSynth would go through the recognize-choose-apply loop and
> automatically generate all possible solutions to the original
> constraints/seed graph, and then spit out those solutions to
> {something} (which I need some clarification on, like I said- maybe a
> user would select from a command line which option to use to solve the
> constraints problem when resizing, or something?) How about some user
> case stories? That would be amazingly helpful. I suspect this code
> would be implemented and integrated as the backend constraints
> solution engine, but I'm also open to the idea of gluing it together
> with shell or command line utilities depending on how exactly it's
> supposed to work when seamlessly integrated (just to make sure I
> understand completely).
In terms of the user interface the scenario I am visualizing is ( eg. say a
sphere is constrained in relation with a box : lets say there are three
variables which are presently not constrained enough : Radius of the sphere,
point of tangency ( considering the constraint is that the spehere and box
touch each other tangentially). The user could be shown a slider for
instance showing the spectrum of radii possible as well as (two sliders?)
for the position of tangency. Now selection of any one of these might
completely constrain the objects : Selection of a radius for instance might
if the centre of the sphere is already constrained, Or selection of the
x-coordinate for the point of tangency ( It may not in which case the y
co-ordinate might be constrained and again request the user for the radius)
)
http://heybryan.org/bioreactor/membraneless_filtration/2008-11-25_gnuplot.png
>
> http://heybryan.org/bioreactor/membraneless_filtration/2008-12-15_brlcad.png
>
> http://heybryan.org/bioreactor/membraneless_filtration/2008-12-16_spiral_generator_2.png
>
> http://heybryan.org/bioreactor/membraneless_filtration/2008-12-16_spiral_generator_2_other_issue.png
>
> http://heybryan.org/bioreactor/membraneless_filtration/2008-12-16_spiral_generator_works.png
> http://heybryan.org/bioreactor/membraneless_filtration/2009-01-22.png
> http://heybryan.org/bioreactor/membraneless_filtration/2009-02-01.png
> one-half the physical object:
>
> http://heybryan.org/bioreactor/membraneless_filtration/2009-03-18_spiral.jpg
>
neat ;)
hope this helps,
sincerely yours,
--
Dawn Thomas
" the strength to change what i can, the inability to accept what i can't,
and the incapacity to tell the difference"
------------------------------------------------------------------------------
Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are
powering Web 2.0 with engaging, cross-platform capabilities. Quickly and
easily build your RIAs with Flex Builder, the Eclipse(TM)based development
software that enables intelligent coding and step-through debugging.
Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com
_______________________________________________
BRL-CAD Developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
