Daniel, I've really seen your efforts and that OO design that John has started in the 'jbrlcad' module as really the starting point for what is being called the Geometry Engine (GE). As you should know, BRL- CAD has had a "geometry engine core" for as long as it's been around, but it's not been pervasively object-oriented and that fact has limited its adoption. I've seen the GE effort as one to really clean up our API while still leveraging the several staff-years of effort that have already been invested in our core. The GE is really going to be the foundation of all geometry processing for a new editor.
As a distinct and separate product, I've tried to maintain the characterization that the GE is our version of a proper 3D modeling kernel that can be used for application development. That makes it a project that is nearly identical in scope to that of the ACIS engine by Spatial [1], the Parasolid engine by Siemens [2], and the Granite engine by PTC [3]. I don't think we should over-extend ourselves as those are products with thousands of staff-years of effort invested, but the goal of most any engine is to provide a clean API to core geometry services. [1] http://en.wikipedia.org/wiki/ACIS [2] http://en.wikipedia.org/wiki/Parasolid [3] http://www.ptc.com/products/granite/faq.htm From our development perspective, I completely agree with your goals of having an easy to use interface that's not affected (API-wise) by changes to the lower C libraries (LIBBU, LIBBN, LIBRT, LIBGED). It will of course necessarily need to be very fast so we can deal with utterly massive models but I also don't want to dwell too much on making design decisions under the claim of "it's for performance" until someone actually profiles a planned interface and has actual numbers to back it up indicating we have a problem. That is not to say that some though hasn't gone into or shouldn't go into performance -- it's more to say that I don't want to over-architect or limit the infrastructure based on a perceived performance limitation without seeing that it's actually something that will matter during interactive use. That in turn will require developing a prototype interface and integrating it early on in the design process so that we can continually test. That is where the prototype GUI that was started by Manuel during GSoC comes into play. There's of course a *lot* of work that has to go into that effort, but it's a great start. Right now, it's tied directly to LIBGED, but the goal is to eventually (fully) decouple it from LIBGED and instead go through a socket-based port protocol (client-server design) using the Geometry Service (GS). The GS sits on top of the GE as a network service allowing the GUI to leverage local or remote CPU processing as well as allowing clients to intercommunicate, share geometry and notifications, and otherwise collaborate. That hopefully characterizes things a little better? The goal isn't to alienate any of our needs as I think they're pretty much all in line, though there has been a communication issue in keeping terms consistent and seeing how the pieces all relate to each other given the design should be shared and discussed among all interested developers that want to contribute. Using the devel mailing list and the wiki is probably our best interaction medium for in-depth discussions. It's also a good place to more carefully characterize thoughts after interactive discussion on the IRC channel. Cheers! Sean On Nov 21, 2008, at 9:24 AM, Daniel Roßberg 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
