I presume you are using Bruce's QuadricSurface macro. From personal experience (Bruce and I worked together here for years), I know that this macro was constructed as a teaching tool for his Computer Graphics course. It has warts. You can open the macro and hack on it, as I have done, to try to deal with some of its inherent issues. The main issue is that it attempts to create an entire family of quadric surfaces with the cheap but effective trick of warping a 2D grid. So the problem is that for some surfaces, this causes the grid to get too tightly wrapped as it were and there is indeed overlap of surfaces, which is what your hardware image looks like to me. (I can see it a bit in the software image as well). There is no trick to remove this artifact ("fuzz" attribute will not help: it only applies to two or more different surfaces).
If you really need quadric surfaces, you'll have to diddle with the macro to change the starting grid resolution, or the parameters you feed to the ellipsoid parameterization to try to get the grid to not overlap. I don't have a recipe; I spent a good deal of time trying to figure one out and I don't think I improved a whole lot on what Bruce had, unless one tosses the hyperbola and cone and stuff, and optimizes for ellipsoid.
But if you only need ellipsoids, there's an easier way. Construct a single sphere Glyph, then scale the Glyph by the eigenvalues. (If necessary, then transform the orientation to match the eigenvectors.)
If you only need one, this is trivial. If you have a field of values, you must do this within a macro that iterates over all the input positions, feeding one at a time to Construct, then making a unique Glyph, then scaling by that instance's eigenvalues, transform by eigenvectors, then Append'ing each to a multigrid.
That is because Glyph normally will create a monolithic field if fed a field as input, so you do not have individual access and control over each glyph created in order to separately scale each along different axes (you can only affect the overall scale of all spheres, but cannot warp them into ellipsoids).
On Monday, Oct 25, 2004, at 17:19 America/New_York, Abbye McEwen wrote:
I'm having trouble using hardware rendering of a parametric surface (an adaptation of Bruce Land's net) in openDX--for lack of better words, it just looks plain ugly. See the attachments for the piece of the net that's giving us trouble and a comparison of how software and hardware rendering look on this machine. My set-up includes a duel Xeon 3.0 gHz processor, 4 gigs of RAM, a PCI express bus, and an nVidia GeForce PCX 5750 video card. We are considering upgrading to a high end video card designed for scientific visualization such as the 3DLabs Wildcat Realism 800. If using a new video card won't improve things, we won't waste the money. What cards are some of you using for scientific visualization? How can we make this look better? Any help would be greatly appreciated, as this is part of a figure for a paper that we need to send off for publication ASAP._______________________________
P.S. We need to use hardware rendering because the macro we are using to do stereo images stops working when changed from hardware to software rendering mode.
Thanks for taking a look,
Abbye McEwen
Department of Molecular and Cellular Biology
The University of Texas at Dallas<ellipsoid.net><software.jpg><hardware.jpg>
Chris Pelkie
Scientific Visualization Producer
622 Rhodes Hall, Cornell Theory Center
Ithaca, NY 14853
