Bengt,
No problem. The missing implementation isn't specific to either g-
stl or mged. It's the geometry engine that represents and describes
all BRL-CAD geometry. You'll run into the tessellation problem with
the DSP for *any* of the exporters as they all require tessellation
to perform the geometry conversion.
BRL-CAD doesn't inherently store geometry in a polygonal format
(unless it's already polygonal geometry). BRL-CAD defaults to and
prefers more mathematically and numerically robust representation
types. Example, for a sphere, it really is just a point and a radius
to represent it .. no polygons, no spline surfaces, just point and
radius. To convert that sphere to pretty much any other geometry
format requires a data conversion -- tessellation.
When new primitives are implemented, the programmer has to describe a
lot of information, define a lot of ways of representing whatever
shape that is, ways to convert to other types (like tessellated
types), and more. For DSP, apparently the tessellation routine
simply wasn't written and it hasn't (until now) ever come up as
nobody has tried exporting or needed to export one that badly.
Like I said, it's really not something hard for a programmer to do,
but you're sort of stuck until someone does implement it. Even
Salome and TetGen and pretty much every other system you're going to
encounter will only take tessellated geometry formats as input.
It's really hard to say how long it might last until tessellation
support is added. It could be tomorrow, it could be years from now
(or never in all honesty). One of the realities of being free open
source software is that the developers work on what they work on.
Most of our developers that could implement this feature are
considerably overtaxed with other priorities at the moment but
someone still might work on it out of the blue. That said, while
there is no guarantee, the fact that you've asked for it puts the
request on our radar and means that someone will, in all
probabilities, eventually get to it now.
If you've never coded before, it'd be too much to tackle --
especially given it really would only take an hour or two to
implement tessellation support and it'd take much longer than that to
explain everything you'd need to know without a programming background.
Cheers!
Sean
On Sep 10, 2008, at 2:38 AM, Bengt Wennehorst wrote:
Dear Sean,
thank you VERY much for your quick reply! Now I know at least that
I haven’t got to spend more time with the current g-stl version (or
does the missing implementation refer to the mged-code?). I’d
pretty much like to try coding myself to save time, but since I
haven’t got any practical coding experience, this will be too
difficult for me (guess it will require a bit more than just doing
copy+paste of some lines that you might give me and recompile g-stl ).
Theoretically another interfacing option could be iges as import
format for the Salome-meca package (if you are interested, just
have a look at http://www.salome-platform.org/home/presentation/
overview/), but the import process for the g-iges output file
unfortunately fails (I’ll try out more converting options).
But the definitely preferred way currently still would be using the
standalone TetGen mesher via the STL format.
Just for my personal time planning: considering your brl-cad
development experience, do you have any idea how long it might last
until a fixed version of the g-stl converter could be available? Or
do you think that (from what I mentioned) it might be an additional
short-term option that I try (guided :-) ) coding myself as well?
Once again, thank you very much for your help!! I’d really
appreciate your comments or suggestions.
Best regards
Bengt
-----Ursprüngliche Nachricht-----
Von: Christopher Sean Morrison [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 10. September 2008 03:35
An: Bengt Wennehorst
Cc: [email protected]; [EMAIL PROTECTED]
Betreff: Re: Question concerning dsp-creation and subsequent g-stl
export
Bengt,
Hello and thanks for writing!
The error message you mentioned (_nul_tess unimplemented) pretty
much sums up the problem. To export any geometry to the STL format
requires tessellating the geometry and apparently tessellation of
the DSP primitive is not yet implemented.
It really isn't something that would be hard at all to implement
(could probably be done in an afternoon) but that probably doesn't
help you a whole lot.. Surprisingly enough, you're the first to
bring it up that I can recall. Can't say that I've ever even tried
to export myself. :-)
I've added it to the TODO for someone to hopefully look at and
implement soon. If you know how to code, I'd be glad to point you
at where in the source code you'd need to look to implement the
tessellation support.
Cheers!
Sean
On Sep 9, 2008, at 5:32 AM, Bengt Wennehorst wrote:
Dear BRL-CAD developers,
first of all thank you very much for this powerful free cad system!!
During a web search I’ve recently discovered brl-cad and installed
it at home on ubuntu 8.04. I am particularly interested in the dsp
(displacement map) feature and the g-stl translator, since I’d like
to use the results of height-calibrated microscopic fluorescence
measurements as input for cad modelling and further cfd
preprocessing (requiring stl-interfacing).
The dsp-feature seems to be extremely useful for solid-modelling of
my “microscale terrain data” and I’ve successfully used a 16 bit
RAW image file for dsp primitive creation.
However, trying to translate the database consisting only of this
object to stl format, the translator aborts due to tessellation
faults (modifications of the different tolerance values didn’t have
any effect). Error messages include something like “…_nul_tess
unimplemented” and “…boolean_walk_subtree…” (If necessary, I’ll
send you the exact messages). Using a simple sphere primitive shape
as the only database object, the translation was successful.
Since I wasn’t able to find any further details concerning the
creation and handling of dsp primitives (e.g. required input file
format - I identified raw by trial and error but I am not sure) and
the g-stl translation of those primitives (tessellation process and
possible problems/restrictions), I would like to ask if you could
give me some hints how dsps are properly being created and
translated to stl.
I would greatly appreciate your reply!
Best regards,
Bengt Wennehorst
-------------------------------------------------------------------------
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