> Thanks, Miguel. That all makes good sense. > > Then the problem must be in the calculation of the vertex normals. I'm > displaying those now.
It is not clear to me which problem you are seeing. > (If you look again, you should see white sticks > coming out I looked again ... I do not see any white sticks. > - those are tne vertex normals, and I can see that there are points where > these > are causing trouble. Not because of a bug, but just because the > combination of > Gouraurd and marching cube is not optimal. > > The shading itself is great. So the Gouraurd methods are excellent. I am not sure what you are saying. The implementation is correct, but the Gouraud algorithm is a shortcut that leads to shading problems. > What > is > getting messed up is the specular reflection. When that is off, everything > looks > extremely nice. But the reflection itself has a very broken look when it > is on. Correct. I believe that if you look at any other system that uses marching-cubes + Gouraud shading for isosurfaces you will get the same thing. In fact, for most molecular viewers that use OpenGL, you will get the same specular hiliting anomolies on the atoms themselves, since they are made out of triangles. > So I'm guessing that it is very sensitive to each vertex normal. (Because > that's > what determines the extent of "reflection", right? Correct. > In the Marching Cube business we get some very thin-sliced > triangles, as you mentioned earlier. It appears to be at > those locations -- intersections very > close to a vertex point -- are where the problems lie. Even in a geodesic sphere wher all the triangles are essentially the same size, you still get a still tend to get a 'starburst' effect when a single vertex falls within the specular 'cone' and turns white. And yes, the problem gets worse when you have thin-sliced sliver triangles. > What I can see are radically different vertex normals at > almost the same location -- probably > those points your debug code was finding. Yes, could be ... but I think my debugging code goes through a 'fast' algorithm and then falls back to a 'slow' algorithm to double-check. The 'slow' results are returned because they are guaranteed to be correct. The debug output shows up when the two do not match. But, no doubt there is some error that is introduced by the 'quantization' in converting to 'normix' values. But also the linear interpolation between voxel scalar values may be breaking down ... don't know ... I'm guessing. > One solution would be to average the vertex normals for > nearby vertices. Maybe not too much of a load, considering > we know that any such points from > their edge > fractions. A bit tricky, perhaps.... Your idea of smoothing the normals is a good one. These normals get calculated only once. You could spend as much time as you want running some kind of smoothing/averaging filter over the normals and it would be fine. The computer graphics people spend a lot of time on this problem. The problem of 'optimally' tessellating a surface is an area of active research. Everybody wants to have the triangles be about the same size and within some acceptable range of not too-acute nor too-obtuse. It has significant academic and commercial value. You know that I spent a great deal of time trying to come up with a 'better' algorithm for the solvent-accessible-surface. Much of my motiviation was to eliminate these sliver triangles. It just really bugged me that most of the triangles in the SAS were for generating the convex 'spheres' of atoms sticking out on the surface. I thought that I should be able to generate these portions of spheres as truly spherical ... or that I could tesselate them perfectly (as with the 'dots' representation) and have prettier triangles ... but no luck so far. Miguel ------------------------------------------------------- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnk&kid7521&bid$8729&dat1642 _______________________________________________ Jmol-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jmol-developers
