Hi,
Once the STL file is written, there is no reason to keep the data in the
drawing.
A system could easily be made with a menu call to copy the surface, set the
style of the copy, explode it and then run the program to write the STL file
and lastly delete the 3D faces, so that the drawing ended up unchanged.
There is no reason to expect the code would be run slowly whether done with
lisp or VBA or anything else. If done in this way it would almost certainly
be faster from start to finish than any other process which involved the
user exporting a file and then finding that file again with an external
program.
The only user input needed would be to start the program, select the
surface, browse to the required output directory and type the output file
name
If the Surface name was used as the Output file name and the drawing
directory used as the output directory then user input could be reduced
again.
--
Laurie Comerford
CADApps
www.cadapps.com.au
www.civil3Dtools.com
wrote in message news:5589151@discussion.autodesk.com...
While STL is ultimately the solution that works well, we try to maintain our
drawings as clean & uncluttered as possible. Having to duplicate & explode a
surface not only increases drawing size significantly, but creates
unecessary drawing entities. Also, having to run LISP routines or
multi-stepped functions only increases the chance for user error. As Brian
stated, not only is the LISP routine processor intensive, but it's not also
the quickest tool in the world.
With the advent of Civil3D 2008, we now have the ability to export a surface
as a DEM. This functionality was not available in 2007 (to my knowledge). By
utilizing the DEM export ability, combined with some secondary program
processing, we are able to quickly & easily generate STL files.
Until we have an STL export function, this seems to be the quickest &
cleanest way to achieve and STL file from a surface. The DEM export was
definitely a step in the right direction from Autodesk, for our needs. We're
getting closer!