Re: Announcement: GDHE 3.2

On Fri, 27 Jun 2003, Matthieu Herrb wrote:

[...]
>  > Do you plan to add some "symbolic representation" of all 3D objects?
>  > (As the scene graph in Coin3D or so.)
> 
> It will be needed in order to be able to implement a 3D user
> interaction. But I'd like to be able to hide this representation for
> users that don't need it. 

Agreed. Do you have any links about where this kind of "scene graph"
stuff is already designed/implemented in a viewer-independent way?

[...]
> The frame I mentionned here is a visual representation (ie 3 arrows of
> a given length drawed at a given position + orientation. You use the
> OpenGL transforms to place it at a relative position with respect to a
> given object. 
Ok, but it doesn't "snap" to the closes geometric primitive, does it?
(Which is a handy feature to have in a GUI, because mostly one wants
to attach frames to such geometric features...)

[...]
> A visualisation system only generates images. The fact that GDHE
> computes some interesting data to generate those images, or that it
> can also accept user input is marginal imho. 

Can I interpret this statement as your saying that you have no
interest in seeing GDHE evolve into a full-fledged two-way GUI? :-)

>  > [...]
>  > > In distibuted multi-robots applications, if all robots send their
>  > > position to GDHE, it becomes possible to detect some events
>  > > (collisions,...) in GDHE and send them back to the robots because GDHE
>  > > becomes the only centralisation point of the application. But you
>  > > don't want to do that if you're working on a distributed
>  > > architecture...
>  > Why not? _Somewhere_ one has to have a component that has information
>  > about all distributed component that need to be synchronized in one
>  > way or another, isn't it?
> 
> Not necessarly. One reason for building distributed architectures is
> that you can't always have this centralized view, for instance because
> of communication loss between nodes. 

I think that, almost by definition, there must be a level of control
that centralizes information. Otherwise your fleet of robot can never
perform a global task, or evaluate how well it does that task...

[...]
>  > On the Orocos GUI workshop, the examples of Coin3D/OpenInventor/Java3D
>  > were mentioned, which support this kind of interaction by allowing to
>  > put callbacks in several places in the "graphics pipeline". 
[...]
> It seems to me that the scripting language approach offers more
> flexibility here, 
Yes, but in some cases one needs events+callbacks to make your GUI and
your application(s) synchronize and work together I guess...
SO the availability of a scripting language is not a sufficient
condition for success :-)

Herman
-- 
  K.U.Leuven, Mechanical Engineering, Robotics Research Group
<http://people.mech.kuleuven.ac.be/~bruyninc> Tel: +32 16 322480