Render 3-D Wireframe to Postscript? 13
W88 writes "I am very familiar with the 3-D rendering packages available including Blender and POVRay, but I am looking for something a little different. I am writing a paper that could benefit significantly from some three dimensional projected views of a fairly complex apparatus. I can easily model the apparatus, but do not want rendered bitmaps in the paper (I am using pdflatex). I would prefer edges with hidden lines removed rendered to a vector format like EPS or PDF (or even FIG). Has anyone seen anything like that? A web search turned up something called hlp that appears to be public domain from NASA but it is only available on a $300US CDROM from Public Domain Aeronautical Software." Note that any software created by the U.S. Government can be obtained with a Freedom of Information Act request, probably for less than the PDAS guys are charging.
Re:write it yerself. (Score:1)
Gnuplot (Score:4)
Try converting your models to Gnuplot format and converting to PS with that. It probably won't handle perspective, but it does orthographic and isometric projections just fine.
Some OpenGL solutions (Score:2)
http://reality.sgi.com/opengl/tips/Feedback.html [sgi.com]
http://www.easysw.com/~mike/opengl/ [easysw.com]
Couple of options (Score:2)
Adobe Dimensions [adobe.com] (wireframe and other 3D to postscript)
An SGI Article [sgi.com] on how to render OpenGL to postscript (with examples and source)
GLP [easysw.com] (another OpenGL to PostScript app w/ source)
Adobe Dimensions is probably your best bet. Hope one of them works for you.
--
He had come like a thief in the night,
Write your own (Score:2)
If you want hidden surface removal, then you might as well use the GL to PS solutions that others suggest.
Rhinoceros. (Score:1)
www.rhino3d.com
xfig (Score:2)
However, the fig2dev program is able to translate fig files (generated by xfig) to any number of formats -- eps among them. The fig file format is pretty straight forward vector graphics, so all you need to do is decimate all the surfaces to triangles, rotate the figure, sort the surfaces in z-depth order, and dump it to fig format.
fig2dev makes an eps file, and then you let the printer take care of it. Filled polygons is something a postscript printer can draw in its sleep; hidden surface removal becomes moot.
Someone already suggested the OpenGl -> PS library, but my suggestion has the benefit of requiring almost no APIs at all; just rotate, decimate, sort, and dump to file.
Johan
Re:Write your own (Score:2)
are mentioning (using the feedback mode) don't
write out bitmaps, but rather interrupt the
rendering pre-rasterisation and output the
(geometric) primitives. It's a much more powerful
method.
K.
-
Mathematica (Score:1)
Unfortunately, I don't think it can do hidden lines. Also, it costs money. However, it is easy to use.
Re:xfig (Score:2)
As you've stated it, it assumes that you have no intersecting surfaces. Now if the original poster is doing some sort of mechanical, CAD/M kind of thing, this may in fact apply to the problem, because the model will be constructed to be able to be a physical thing. Anything else and you open yourself up to lots of potential errors.
Getting Painter's right involves checking for intersecting polygons, and splitting the intersecting polygons. Aside from being an expensive operation, it's highly sensitive to floating point errors.
So beware of the simple way out in 3D graphics....
GMT (Score:1)
Re:xfig (Score:2)
so painter's (didn't know it was called that) isn't even able to deal with the simple cases.
crap.
Little bit of math (Score:1)
struct lat_ring {
struct lon_ring {
struct vertices {
double x; double y;
lon_ring *lonr;
lat_ring *latr;
};
These techniques, while hinted at by others and only briefly outlined by me all take a lot of work for something so small. If you don't have the time, I hope you have the money. If you have neither, I hope you like your bitmaps.
One little beast which may rear it's ugly head on you is the case of intersecting polygons. In short, the only way to handle this in the vector sense is to bisect the two polygons into extra pieces (usually four, but sometimes three, when rendering with triangles or rectangles). This sounds easy in concept until you realize that every polygon has to be tested against every other polygon for intersection. The check, however simplified is complex and computationally expensive. Try and find a way to avoid having bisected polygons and you can ignore this problem.
Hope this helps. Also, recommend you check out the Computer Graphics Gems book series.