Hi Grey, Could you point us in the direction of an stl file that reproduces this problem?
Robert. On 3 November 2014 22:26, Michael Grey <[email protected]> wrote: > 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 > [email protected] > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org >
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
