Daniel,
I think the other part worth mentioning about LIBGED is that it's
main purpose is to make functionality that was previously ONLY
available in front-end application code within mged also available
outside of mged. Regardless of seeming scripting-based (which it
naturally is since it came from mged), LIBGED is a way to push
functionality up into libraries, clean up (and test) their
implementation, and leverage the time and effort that went into them.
There's literally more than a hundred staff-years invested across
more than 100k lines of code in mged that would be horrible to
ditch. While moving the code to LIBGED, that gives us the
opportunity to decouple the implementation from Tcl and makes it even
easier then to push some of the functionality all the way up into
LIBRT as well where much of it belongs. LIBGED is a first step.
It's a way to begin cleaning the code up so it can be used for
another, better, new GUI.
If the GE uses LIBGED, it will be a back-end detail like how GE uses
LIBRT and probably only as a temporary measure at that until it can
be cleaned up. Again, there's about 100k lines of functionality that
we're not about to rewrite so there will undoubtedly be things that
will be much more easily implemented via LIBGED than via LIBRT or
from scratch. Long term, though, GE's focus isn't to be command-
driven like the GUI. It's to be a clean OO geometry kernel API like
other geometry kernels.
Cheers!
Sean
On Nov 21, 2008, at 9:36 AM, David Loman wrote:
Daniel: Firstly, thanks for writing this up. My fingers are numb
from all the documenting I have been doing the past week!
To comment on a few items in the previous mail:
-Speed is also a major factor for iBME, but is considered an
optimization issue. Since we are early in design, its a bit too
premature to optimize at this point.
-libged will only be part of the interface into brlcad's libraries.
We will be accessing many functions directly from the root libs
themselves (librt, libwdb, etc). libged will be a shortcut to
obtain functionality quickly, at the expense of speed.
-iBME will definetly be able to make use of Daniels work thus far,
especially since part of the first milestone to meet involves db io.
-You are correct in your analysis of the levels of abstraction
between the two projects.
Once i finish documenting things on http://brlcad.org/wiki/
IBME_Main, I will dive into your implementation of things in depth.
Thanks for your time and effort! Since this is a mailing list,
anyone is more than welcome to jump on the discussion train!
-Dave Loman
On Fri, Nov 21, 2008 at 9:24 AM, Daniel Roßberg
<[EMAIL PROTECTED]> wrote:
Currently there are two ongoing efforts to create a C++ wrapper for
BRL-CAD.
First, there is my project (supported on code contributions from TNO)
to write the C++ layer right on top of the core functions (mainly
provided by librt). This way I want to
- create an easy to use interface which
- is not effected by changes to the inner (librt etc.) structures,
- is fast and
- acts as a reference on how to use BRL-CAD's core functions.
This interface shall be used in other fast running programs. One
problem which arises then is the decision about the owners and live
times of the objects. I don't want to use memory allocation or string
comparisons in simple operations. A solution is the use of call backs
(which may look ugly for some people). Well, we will see how far I
will go with this.
The other C++ interface project is part of iBME (Integrated BRL-CAD
Modeling Environment) with David Loman as the main developer of its OO
design. It will use BRL-CAD via libged's command-line like interface.
There I would like to know more about the reasons for the design.
What are the intended applications?
In my opinion these two projects are trying to develop different
layers on BRL-CAD (iBME a more abstract, higher layer than mine).
Maybe iBME's Geometry Engine could be based on my core interface.
Sziasztok,
Daniel
PS: Both projects have a wiki-page on brlcad.org and their source code
can be found on brlcad.svn.sourceforge.net/brlcad/rt^3 at
include/brlcad, src/coreInterface or src/iBME respective.
----------------------------------------------------------------------
---
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win
great prizes
Grand prize is a trip for two to an Open Source event anywhere in
the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
BRL-CAD Developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
----------------------------------------------------------------------
---
This SF.Net email is sponsored by the Moblin Your Move Developer's
challenge
Build the coolest Linux based applications with Moblin SDK & win
great prizes
Grand prize is a trip for two to an Open Source event anywhere in
the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
BRL-CAD Developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
BRL-CAD Developer mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/brlcad-devel
