Render 3-D Wireframe to Postscript?

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.

Comments

Gnuplot

[Pseudonym]

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

[mmp]

If you're willing to write a little opengl application that draws your wireframes, etc, there are two nice options that producting high quality postscript output by intercepting the opengl calls and then turning them into appropriate postscript calls.

http://reality.sgi.com/opengl/tips/Feedback.html

http://www.easysw.com/~mike/opengl/

Couple of options

[ClubPetey]

Here's a list of options:

Adobe Dimensions (wireframe and other 3D to postscript)

An SGI Article on how to render OpenGL to postscript (with examples and source)

GLP (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

[UberLame]

With a little inginueity, and a copy of the book "thinking postscipt" (now a free download off the web), you can easily write own own 3D renderer in Postscript in an hour or so. Just think of drawing your figures as a series of planes. Then, each plane going away from the viewer gets scaled downwards. For transformations, all you need is a little algebra and trig. In some ways, this is a particularly elegent way of doing 3D wireframe because your are letting the printer do the work. With the OpenGL to PS solutions other recommend, the printouts are sent to the printer as a bitmap.

If you want hidden surface removal, then you might as well use the GL to PS solutions that others suggest.

Re:Write your own

[K.]

Strictly speaking, the opengl2ps solutions people
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.
-

xfig

[jovlinger]

It is not clear exactly how much control you have of the system and where you want this software to take over.

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:xfig

[nellardo]

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

This is the so-called "Painter's Algorithm," and while it is simple, there is a major gotcha there.

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....

Re:xfig

[jovlinger]

ugh. AND if you have a case of A covers B covers C covers A (which you can set up with three triangles) you can get a situation that requires splitting (what I called decimation) but has no intersection.

so painter's (didn't know it was called that) isn't even able to deal with the simple cases.

crap.