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

Re:write it yerself.

[BlackHat]

Starting point in "rendereps.c" part of the stock GLUT examples from Mark J. Kilgard.

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

Rhinoceros.

[modecx]

It may or may not be what you need, but Rhinoceros has a feature like the one you describe. There is a 'draw2d' function that takes the current view, and makes an isometric-style line removed flat 2-d drawing. This can be easily converted to dxf, and a host of other formats. I'm unsure of the ability to output to ps, or whether or not it can do this with a wire-mesh (triangulated-non-NURBS model). I have used it on engineering projects, and the complexity that can be easily acheived left some stunned.

www.rhino3d.com

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.

Mathematica

[fullcity]

I made 3D wireframe and shaded images for my dissertation using Mathematica. http://www.cs.unc.edu/~geom/MAT/

Unfortunately, I don't think it can do hidden lines. Also, it costs money. However, it is easy to use.

GMT

[SEWilco]

GMT, the Generic Mapping Tool perhaps. The page does mention quite an assortment of processing possibilities, including 3-D coordinates and surface rendering.

Little bit of math

[Midnight Warrior]

Since you are building the wireframes yourself, I will work off the following assumptions:

1. My example will be a wireframe of a sphere, with North pointing in the positive up (Y) direction.
2. You are storing points along the lines which, when drawn, form a latitude ring (NtoS).
3. Then, after bisecting the sphere into horizontal slices, you draw longitudinal rings (EtoW).
4. You already know how to do the world-space to viewport transformation of all your data points. (ie orthoganal correction, etc)

I assume this since that's probably how you get the lines to connect in a meaningful format. To solve the problem, we will borrow some of the techniques from OpenGL without having to use OpenGL.

1. Take latitude rings and the longitude rings and associate them into vertices on a square (however NURBed the square may be). In other words, other than have the same point in a latitude ring and a longitude ring, bring the point together, remembering which latitude and longitude rings the point belongs to (so we can draw our lines later).
2. Each vertex in your object should contain data in a format similar to the following C structure:
   struct lat_ring { ... };
   struct lon_ring { ... };
   struct vertices {
   double x; double y; /* in world space */
   lon_ring *lonr; /*pointer to the ring*/
   lat_ring *latr; /*pointer to the ring*/
   };
3. Now that you have an array of "vertices", The vertices need associated together to form (your choice) either triangles or rectangles. Hint: triangles are the best and will only be used for computing a normal.
4. Two approaches can be taken.
   • One is geared for print, the other is geared for additional rendering techniques. You can either draw the picture from front to back (by drawing the squares at the greatest depth) and do a Z-buffer like technique whereby each square drawn is drawn in two parts: one is a white, filled square which overwrites any previous lines, and the other is the drawing of the outline of the square. I say this only works for print because you assume the page background is white, which it usually is.
   • Order the vertices in each square/triangle in a consistent fashion such that a normal can be computed. Normals, which are a three-dimensional vector, can be associated with your viewpoint. Normals which point away from the user can either be culled out or drawn in a faded fashion (e.g. a light grey box). If you have a closed object, then you can cull vertices. Otherwise, consider fading out the outline. In either case, the rectangles must still be drawn in depth order, with the farthest away being drawn first.

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.