## Re: [Jmol-developers] curious specular behavior

 Re: [Jmol-developers] curious specular behavior From: Bob Hanson - 2006-05-27 02:39:56 ```Problem solved. Thanks, again, Miguel. It was, in fact, the vertex normal problem; it is solved now. As for you not seeing the normals, Miguel, your browser probably cached the JAR files. If you still don't see the white lines, take a look at http://www.stolaf.edu/people/hansonr/jmol/test/proto/jvxl-compare-normal.jpg White lines are vertex normals; dots are grid points. Triangles are shrunk by 10% so as to distinguish them. I found this very helpful in understanding how that triangulation works. (I can see how it was worth a patent! Someone can be very proud of that little trick!) What I've done is just a little additional summing of the vertex normals. Rather than just for each associated triangle, I add in any triangles associated with the generating grid point whenever the intersecting surface point is within 30% of the distance to a grid point. The final code replaces Mesh.initialize() with: void initializeMesh() { int vertexCount = currentMesh.vertexCount; Vector3f[] vectorSums = new Vector3f[vertexCount]; for (int i = vertexCount; --i >= 0;) { vectorSums[i] = (assocGridPointMap.containsKey("" + i) ? (Vector3f) assocGridPointNormals.get((String) assocGridPointMap.get("" + i)) : new Vector3f()); } currentMesh.sumVertexNormals(vectorSums); currentMesh.normixes = new short[vertexCount]; for (int i = vertexCount; --i >= 0;) currentMesh.normixes[i] = g3d.getNormix(vectorSums[i]); } Hashtable assocGridPointMap; Hashtable assocGridPointNormals; int addVertexCopy(Point3f vertex, boolean iHaveAssociation, String sKey) { int vPt = currentMesh.addVertexCopy(vertex); if (vPt == 0) { assocGridPointMap = new Hashtable(); assocGridPointNormals = new Hashtable(); } if (iHaveAssociation) { assocGridPointMap.put("" + vPt, sKey); if (!assocGridPointNormals.containsKey(sKey)) assocGridPointNormals.put(sKey, new Vector3f(0, 0, 0)); } return vPt; } In this JPG you can see how this aligns the normals, thus guaranteeing the same specular reflection for all nearby triangle points. Mind you, these images were taken at specular 80, specpower 80, so that's rather ridiculous. When you back off to the default specular 22, specpower 45 it's much more subtle. In the end, I'm not convinced it's really worth the trouble, but since it's almost no additional computational effort, I think I'll leave it in this way. It was certainly an interesting challenge, and we can have fun with the depictions, anyway. OK, I have to stop fooling around! Bob Miguel wrote: > > 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. I'm satisfied that the solution I arrived at is 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_______________________________________________ > Jmol-developers mailing list > Jmol-developers@... > https://lists.sourceforge.net/lists/listinfo/jmol-developers -- -- Robert M. Hanson, hansonr@..., 507-646-3107 Professor of Chemistry, St. Olaf College 1520 St. Olaf Ave., Northfield, MN 55057 mailto:hansonr@... http://www.stolaf.edu/people/hansonr "Imagination is more important than knowledge." - Albert Einstein ```

 [Jmol-developers] curious specular behavior From: Bob Hanson - 2006-05-26 16:55:08 ```I can't figure out what is wrong with the isosurface specular display. Please look at http://www.stolaf.edu/people/hansonr/jmol/test/proto/new.htm?scriptno=3 Why the specular problem there on the lower right? I think if we could solve this problem, isosurfaces would look a whole lot better. All suggestions welcome. Bob -- -- Robert M. Hanson, hansonr@..., 507-646-3107 Professor of Chemistry, St. Olaf College 1520 St. Olaf Ave., Northfield, MN 55057 mailto:hansonr@... http://www.stolaf.edu/people/hansonr "Imagination is more important than knowledge." - Albert Einstein ```
 Re: [Jmol-developers] curious specular behavior From: Miguel - 2006-05-26 18:20:05 ```> I can't figure out what is wrong with the isosurface specular display. > > Please look at > > http://www.stolaf.edu/people/hansonr/jmol/test/proto/new.htm?scriptno=3D= 3 > > Why the specular problem there on the lower right? I think if we could > solve > this problem, isosurfaces would look a whole lot better. > > All suggestions welcome. It is a difficult problem that is somewhat hard to explain. The question relates to how shading is calculated. There are three main types: - flat shading - Gouraud shading - Phong shading Flat shading simply uses the triangle surface normal to apply the shading= . That is, the entire triangle has the same color. That makes the tessellation very obvious. I may be mistaken, but I think that there may be an option to the 'isosurface' command that allows you to render with flat shading. Gouraud and Phong shading involve calculating the normal at each vertex. This is done by averaging the normals of all of the triangles that touch the vertex. How they are averaged can be important. If I recall correctly= , Jml currently uses a simple average. Another algorithm that might be better would weight the faces that meet at a vertex so that faces with a lot of surface area have more impact on the vertex normal. Now that you have the vertex normals, you need to figure out how you are going to interpolate across the face of the triangle. Gouraud shading essentially does a linear interpolation of the pixels between the vertices. This is what most graphics cards do because it is fast and relatively simple. This is basically what the Jmol g3d package does. It takes the RGB values= at the 3 corners and linearly interpolates between those RGB values. This= allows relatively smooth transitions of color as well as lighting. Phong shading actually interpolates the normals at each point of the surface. This gives much better results because the specular hiliting is calculated at each point using the normal at that point. Since the specular lighting function is so non-linear you get better results. The problem with Phong shading is that it is very expensive. Basically, you need to do vector transformations for each pixel. I may be out of date, but I suspect that Phong shading is only available on very high end= graphics hardware. If results are unacceptably, it is generally less computationally expensive to increase the number of sample points and stick with Gouraud shading. Miguel ```
 Re: [Jmol-developers] curious specular behavior From: Bob Hanson - 2006-05-26 20:58:42 ```Thanks, Miguel. That all makes good sense. Then the problem must be in the calculation of the vertex normals. I'm displaying those now. (If you look again, you should see white sticks coming out - 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. 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. So I'm guessing that it is very sensitive to each vertex normal. (Because that's what determines the extent of "reflection", right? 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. What I can see are radically different vertex normals at almost the same location -- probably those points your debug code was finding. 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.... Bob Miguel wrote: >>I can't figure out what is wrong with the isosurface specular display. >> >>Please look at >> >>http://www.stolaf.edu/people/hansonr/jmol/test/proto/new.htm?scriptno=3 >> >>Why the specular problem there on the lower right? I think if we could >>solve >>this problem, isosurfaces would look a whole lot better. >> >>All suggestions welcome. > > > It is a difficult problem that is somewhat hard to explain. > > The question relates to how shading is calculated. There are three main > types: > - flat shading > - Gouraud shading > - Phong shading > > Flat shading simply uses the triangle surface normal to apply the shading. > That is, the entire triangle has the same color. That makes the > tessellation very obvious. I may be mistaken, but I think that there may > be an option to the 'isosurface' command that allows you to render with > flat shading. > > Gouraud and Phong shading involve calculating the normal at each vertex. > This is done by averaging the normals of all of the triangles that touch > the vertex. How they are averaged can be important. If I recall correctly, > Jml currently uses a simple average. Another algorithm that might be > better would weight the faces that meet at a vertex so that faces with a > lot of surface area have more impact on the vertex normal. > > Now that you have the vertex normals, you need to figure out how you are > going to interpolate across the face of the triangle. > > Gouraud shading essentially does a linear interpolation of the pixels > between the vertices. This is what most graphics cards do because it is > fast and relatively simple. > > This is basically what the Jmol g3d package does. It takes the RGB values > at the 3 corners and linearly interpolates between those RGB values. This > allows relatively smooth transitions of color as well as lighting. > > Phong shading actually interpolates the normals at each point of the > surface. This gives much better results because the specular hiliting is > calculated at each point using the normal at that point. Since the > specular lighting function is so non-linear you get better results. > > The problem with Phong shading is that it is very expensive. Basically, > you need to do vector transformations for each pixel. I may be out of > date, but I suspect that Phong shading is only available on very high end > graphics hardware. > > If results are unacceptably, it is generally less computationally > expensive to increase the number of sample points and stick with Gouraud > shading. > > > 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_______________________________________________ > Jmol-developers mailing list > Jmol-developers@... > https://lists.sourceforge.net/lists/listinfo/jmol-developers -- -- Robert M. Hanson, hansonr@..., 507-646-3107 Professor of Chemistry, St. Olaf College 1520 St. Olaf Ave., Northfield, MN 55057 mailto:hansonr@... http://www.stolaf.edu/people/hansonr "Imagination is more important than knowledge." - Albert Einstein ```
 Re: [Jmol-developers] curious specular behavior From: Miguel - 2006-05-27 01:18:35 ```> 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 whe= re > 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, everyth= ing > looks > extremely nice. But the reflection itself has a very broken look when i= t > 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. (Becau= se > that's > what determines the extent of =22reflection=22, 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 singl= e vertex falls within the specular 'cone' and turns white. And yes, the problem gets worse when you have thin-sliced sliver triangle= s. > 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. Th= e 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 an= d 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 bugge= d 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 b= e 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 ```
 Re: [Jmol-developers] curious specular behavior From: Bob Hanson - 2006-05-27 02:39:56 ```Problem solved. Thanks, again, Miguel. It was, in fact, the vertex normal problem; it is solved now. As for you not seeing the normals, Miguel, your browser probably cached the JAR files. If you still don't see the white lines, take a look at http://www.stolaf.edu/people/hansonr/jmol/test/proto/jvxl-compare-normal.jpg White lines are vertex normals; dots are grid points. Triangles are shrunk by 10% so as to distinguish them. I found this very helpful in understanding how that triangulation works. (I can see how it was worth a patent! Someone can be very proud of that little trick!) What I've done is just a little additional summing of the vertex normals. Rather than just for each associated triangle, I add in any triangles associated with the generating grid point whenever the intersecting surface point is within 30% of the distance to a grid point. The final code replaces Mesh.initialize() with: void initializeMesh() { int vertexCount = currentMesh.vertexCount; Vector3f[] vectorSums = new Vector3f[vertexCount]; for (int i = vertexCount; --i >= 0;) { vectorSums[i] = (assocGridPointMap.containsKey("" + i) ? (Vector3f) assocGridPointNormals.get((String) assocGridPointMap.get("" + i)) : new Vector3f()); } currentMesh.sumVertexNormals(vectorSums); currentMesh.normixes = new short[vertexCount]; for (int i = vertexCount; --i >= 0;) currentMesh.normixes[i] = g3d.getNormix(vectorSums[i]); } Hashtable assocGridPointMap; Hashtable assocGridPointNormals; int addVertexCopy(Point3f vertex, boolean iHaveAssociation, String sKey) { int vPt = currentMesh.addVertexCopy(vertex); if (vPt == 0) { assocGridPointMap = new Hashtable(); assocGridPointNormals = new Hashtable(); } if (iHaveAssociation) { assocGridPointMap.put("" + vPt, sKey); if (!assocGridPointNormals.containsKey(sKey)) assocGridPointNormals.put(sKey, new Vector3f(0, 0, 0)); } return vPt; } In this JPG you can see how this aligns the normals, thus guaranteeing the same specular reflection for all nearby triangle points. Mind you, these images were taken at specular 80, specpower 80, so that's rather ridiculous. When you back off to the default specular 22, specpower 45 it's much more subtle. In the end, I'm not convinced it's really worth the trouble, but since it's almost no additional computational effort, I think I'll leave it in this way. It was certainly an interesting challenge, and we can have fun with the depictions, anyway. OK, I have to stop fooling around! Bob Miguel wrote: > > 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. I'm satisfied that the solution I arrived at is 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_______________________________________________ > Jmol-developers mailing list > Jmol-developers@... > https://lists.sourceforge.net/lists/listinfo/jmol-developers -- -- Robert M. Hanson, hansonr@..., 507-646-3107 Professor of Chemistry, St. Olaf College 1520 St. Olaf Ave., Northfield, MN 55057 mailto:hansonr@... http://www.stolaf.edu/people/hansonr "Imagination is more important than knowledge." - Albert Einstein ```
 Re: [Jmol-developers] curious specular behavior From: Miguel - 2006-05-27 14:29:12 ```> Problem solved. Thanks, again, Miguel. It was, in fact, the vertex norm= al > problem; it is solved now. As for you not seeing the normals, Miguel, y= our > browser probably cached the JAR files. If you still don't see the white= > lines, > take a look at > > http://www.stolaf.edu/people/hansonr/jmol/test/proto/jvxl-compare-norma= l.jpg Very nice=21 > What I've done is just a little additional summing of the vertex normal= s. > Rather > than just for each associated triangle, I add in any triangles associat= ed > with > the generating grid point whenever the intersecting surface point is > within 30% > of the distance to a grid point. Excellent=21 > In the end, I'm not convinced it's really worth the trouble, but since > it's > almost no additional computational effort, I think I'll leave it in thi= s > way. Yes, it is a nice improvement and you should certainly leave it in. As you know, calculations that are done at rendering time are expensive. But anything that can be done on a one-shot basis is well worth it. Well done. Miguel ```