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

Reply via email to