On Sun, 7 Apr 2002, Lloyd A Treinish wrote: > > Well, this is an issue that's about a decade old. There has been > occasional discussion about the issues over the years... > > The architecture of DX certainly supports it. But some "programming" would > be required to create an appropriate module or to enhance an extant one. > It was never done in the commercial days only because it was a lower > priority compared to other requirements. Thinking about it as an Export > format would be easier than than an alternate renderer, but incomplete. To > prove the point, both have been done by DX users over the years. A place > to start would be the Export module, specifically for VRML. The issue is > that DX and the DX renderer supports many more types of geometry than > Postscript (or VRML) supports. While Export could accept any DX object, > only a subset makes sense for the target format.
I'm at least going to try implementing a postscript export module. I though about doing a two-stage conversion of the data to postscript - first select the objects the postscript exporter is capable of transforming to postscript code, second use the exising render module to create an image for the remaining objects. Now compose a postscript document out of the two parts. The question is, as you noted, how to handle the camera in this case. Is there a way to "apply" a camera to a dx object hierarchy to gain "2d" objects? There's another possibility of the place the postscript exporter could be done - as a different sort of hardware renderer. But here I have two questions: - is there a intermediate object representation created for hardware renderers (i.e. a polygonal representation?) - are text and higher level objects (spheres, etc.) preserved? I'll have a look at the VRML exporter as you suggest. Any other suggestions are highly appreciated! Richard. -- Richard Guenther <[EMAIL PROTECTED]> WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/ The GLAME Project: http://www.glame.de/
