Re: [brlcad-devel] BRL-CAD C++ Geometry Engine

[Christopher S. M. <br...@ma...>]

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  
> <dan...@go...> 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
> brl...@li...
> 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
> brl...@li...
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel