Hi, Robert Thanks for your advice! I finally got back to this issue, and did as you recommended. I loaded a few of the STL files in the osgviewer application, and it had similar strange coloring problems (as seen in the attachment).
As you recommended, I looked at the change in the source code between version 3.0 and version 3.2. Indeed, there were some changes pertaining to the normal array (I would add links to the commit history, but I am currently forbidden from including links in my posts). It looks like these changes may have been related to BIND_PER_PRIMITIVE being deprecated, because it takes the per-triangle normals that are used in the STL file format and then tries to extend them to be per-vertex. I decided to print out the normals that the OSG node has for the STL files, and I found an interesting mixture of normals that were perfectly fine along with normals that were very bad, as in the magnitude of each normal was very far from 1 (many had a magnitude of 0, ~1e-42, ~1e+32, and a few were even NaN). This makes me think that they're uninitialized. Grabbing a few random STL files from around the internet produces similar results. I think this would explain much about the strange coloration, especially the way many vertices seem to drop to pitch black or be extremely bright for no apparent reason. A few things I've noticed... Even though this is in the STL plugin source code: Code: perVertexNormals->push_back(*itr); perVertexNormals->push_back(*itr); perVertexNormals->push_back(*itr); The values that I'm seeing are not consistently triple repeats. I'm using the code in the .cpp file that I've attached, and I get the following print out using an STL file that I'm testing with (this print out is truncated because it would be hundreds of lines): > Got a Group > Got a Geode > Got vertex array (718) > Got normal array (718) > #0 (1) -0.111759 -0.993735 0 > #1 (1) -0.111759 -0.993735 0 > #2 (1) -0 0 -1 > #3 (1) 0 0 -1 > #4 (1) 0 0 -1 > #5 (1) -0 0 -1 > #6 (1) -0 0 -1 > #7 (1) -0 0 -1 > #8 (1) -0 0 -1 > #9 (1) 0 0 -1 > #10 (1) -0 -0 -1 > #11 (1) 0 0 -1 > #12 (1) -0 0 -1 > #13 (1) 0 0 -1 > #14 (1) 0 0 -1 > #15 (1) 0 0 -1 > #16 (1) 0 -0 -1 > #17 (1) 0 0 -1 > #18 (1) 0 -0 -1 > #19 (1) 0 0 -1 > #20 (1) 0 0 -1 > #21 (1) 0 0 -1 > ... The source code in the STL plugin suggests that we should see triples of each normal vector, but that's not quite what we seem to be getting. Also, strangely, the vertex array count and the normal array count seem to have a size that's NOT divisible by 3, but this varies from file to file. Most files produce a vertex & normal array that's divisible by 3, but not all. In every case so far, the size of the vertex array and size of the normal array match each other. I think I've dug into the matter about as much as my level of expertise is capable. I strongly suspect there is something wrong with the way surface normals are being stored or accessed, and I think this is causing the strange darkness/shininess. Would there be a better place for me to post about this issue? Thanks for any advice or suggestions you can offer! --Grey ------------------ Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61499#61499 Attachments: http://forum.openscenegraph.org//files/visual_test_164.cpp http://forum.openscenegraph.org//files/osgviewer_example_151.png _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
