Re: OROCOS: (Graphical) User Interfaces: Discussion ...

[email protected] wrote:

> On Tue, 27 May 2003 [email protected] wrote:
>
> [...]
> >   - ordinary visualization server for distributed components
> >     where everything from an arbitrary number of clients is
> >     simply displayed
> "simply" :-) I think one of the things that make this desirable server
> not so simple is the need for widget independence: how can we decouple
> as much as possible the visualization functionality from the
> visualization implementation.
> Another aspect of 3D visualization: how can we use as much OpenGL as
> needed/possible without committing to a widget set.

Some hints on where to look at for our 2D drawing widget which might be of
interest ....

a Qt widget for metric 2d drawing which
can be zoomed and panned conveniently,
offers many signals for mouse events with metric arguments,
delegates repainting through a signal void redraw(Faw::Painter &painter).
(see Faw::DrawingWidget) an output abstraction which provides a uniform
interface (Faw::Painter) for output to GUI widgets, xfig files (and
various
other formats by means of the fig2dev package) (Faw::FigPainter), and
storing/transmitting/replaying drawing actions
(Faw::DrawingStoreReplayPainter).

http://www1.faw.uni-ulm.de/orocos/html-documentation/classFaw_1_1Painter.html

http://www1.faw.uni-ulm.de/orocos/html-documentation/classFaw_1_1DrawingWidget.html

http://www1.faw.uni-ulm.de/orocos/html-documentation/classFaw_1_1Painter.html

http://www1.faw.uni-ulm.de/orocos/html-documentation/classSmart_1_1QtPushTimedClient.html

http://www1.faw.uni-ulm.de/orocos/html-documentation/classSmart_1_1QtPushNewestClient.html

http://www1.faw.uni-ulm.de/orocos/html-documentation/classSmart_1_1QtSignallingInterface.html



> >   - Combination of Open Inventor with Collision Checker
> >     - forward the triangles generated by Open Inventor
> >       to Swift / PQP collision checkers
> >     - worked as hack, but nothing stable ...
> My impression is that Open Inventor is too much focused on being a
> "viewer" and not so much an "input" interface.

Yes, but user interfaces in 3D are a difficult topic. Nevertheless, open
inventor can be extended since
you can extend the scene graph nodes and it already provides nice
manipulators for rotating and
translating objects in the viewer. What I like with tools like open
inventor is the high abstraction
level which is far beyond the OpenGL level. This however has drawbacks
when connecting to
collision checkers since there you need the geometric representation
again.

> >   - Visualization of LOOM knowledge base
> LOOM? <http://web.media.mit.edu/~kkarahal/loom/>?
>

Knowledge base from artificial intelligence community, see here

http://www.isi.edu/isd/LOOM/LOOM-HOME.html


> >     - if object is placed in midair, object is moved downwards
> >       till it hits a supporting object.
> What performs the collision detection? How is a "stable" support
> defined and calculated?

Very simple (and not a full fledged physical simulation): move the object
downwards till it collides with an object and it is placed there even if
that
is physically not a stable result   :-))

> All these "collision detection clients" register their "callbacks"
> with the collsion detector component. I think this basically solves
> this decoupling problem, doesn't it?

Yes, that's true. But what is with performance ? If we find a convenient
set of
object primitives then we only need to communicate the changes in the
kinematic
chain of the objects. Otherwise we perhaps have to communicate triangles
etc.
By the way, we have to communicate triangles from the collision checker as

soon as we want to highlight the collision zone in our visualization ...

> >   - therefore no activity nodes as available in "open
> >     inventor" where one can move objects along a trajectory
> >     etc.
> ???

You can have nodes in your scene graph which perform simple calculations
and for example modify a transformation in the scene graph. The open
inventor example is a windmill where the wings rotate solely based on
the interpretation of the scene graph in the viewer without further
interaction of any clients ...

In my views such activities belong to the client and not to the viewer
since
you otherwise introduce pose changes etc. which impose the problem of
being communicated back to the clients ...

Christian

---------------------------------------------------------------------
Christian Schlegel
FAW Ulm (Research Institute for Applied Knowledge Processing)
PO Box 2060
D-89010 Ulm
Germany

Tel. : ++49 (731) 501 8949
Fax  : ++49 (731) 501 999
email: [email protected]
WWW  : http://www.faw.uni-ulm.de/
---------------------------------------------------------------------