First off, it does the same artifact thing on Mac OS X.
Second, the artifacting seems to essentially disappear in hardware rendering but be quite prominent in software rendering: this is surprising to me since I tend to see more weirdness in HW than SW rendering. For once GL's inadequacies work in its favor, I guess.
Third, as you observed, the artifact appears at a certain distance (as shown in your images), but decreases as the camera zooms in. It also changes as you rotate the object.
Now for interested others who haven't downloaded this stuff, what Dragos has is a volumetric mesh with a blade-shaped hole in it; I'm guessing you defined this so that the field would not pass through the boundary of the material. It is that mesh that carries the field data (from which the isolines are created). To see the blade, he's essentially put a boundary around the hole (discarding all the other meat). The problem is that the blade is very very thin, so the effect is like folding a piece of paper in half til it almost touches itself. It does not actually touch, so it's not the classic problem of coincident surface rendering artifacts. But it comes so close that the gap is about the size of the triangular elements on the surface, which are quite small with regard to the overall object.
I showed the problem to Drew here and we concur that it's probably a rule-based Z-buffer algorithm that is being pushed past its limit. You have isolines, which DX renders as lines. Rule 1: Lines have rendering priority when coincident with surfaces. This can be overridden with the Options(fuzz) attribute, but that doesn't help in this case, cause you'd be applying fuzz to all the isolines, so making the whole set move either closer to the camera, worsening the artifact, or further away, making the front lines disappear behind the blade (I tried it).
(We also tried making the isolines or the blade slightly transparent, but that didn't fool Mother Nature either.)
You have two surfaces that are so close they almost touch and 2 sets of lines that therefore are almost co'planar' (on the curved planes of the blade face). At a certain distance, the renderer simply cannot resolve the Z-buffer depth of these "4" objects (front lines, front face, back face, back lines). Lines win due to rule 1. As you zoom in, the relative distance from camera to object and object to object changes and the camera can finally resolve the Z-buffer stack. This is strongly suggested by the fact that as you rotate the object, the artifacts will progressively disappear as your view vector approaches parallel with the blade surface; thus, the distance between the "front" and "back" surfaces (along the view vector) finally exceeds the Z-buffer criterion and the back objects are properly pushed down on the stack and are occluded.
Unfortunately, I don't have an easy fix. I think you must find a way to properly define the blade object as a mesh of tetrahedra, not as a folded plane. I don't think you can derive that mesh from your volume with a hole in it, but maybe you can see a way. Obviously, you have the definition of the mesh, so deriving the "anti-mesh" can't be impossible. I believe this will probably help, but can't be absolutely sure. I didn't have time to Construct a really skinny volumetric object, of thickness = blade thickness, but I'm sure you can try this before tackling the bigger hassle of defining the blade as a tet mesh. My hope would be that the renderer uses a different rule for "line, volume, line" than for "line, surface, surface, line".
Cheers,
<x-tad-bigger>____________________________
Chris Pelkie
Vice President (607) 257-8335
Conceptual Reality Presentations, Inc.
30 West Meadow Drive
Ithaca, NY 14850</x-tad-bigger><x-tad-bigger>
</x-tad-bigger>
On May 26, 2005, at 11:16, Dragos MOROIANU wrote:
Hi Chris,
The data is about 7MB so I attached it to this mail together with the net.
If you have time to tacke a look at it and tell me the result I will be
gratefull.
Thank you,
Dragos
--
[The attachment pressure.dx has been manually removed]
[The attachment dx.net has been manually removed]
