Re: [osg-users] [osgPlugins] bug stl pugin?
Just to follow up on this, I've confirmed that the behavior we're each seeing is caused by the same bug. The STL plugin for 3.2.0 does not initialize its normal vector array correctly (it reserves all the memory it needs, but only fills in 1/3 of it), which results in undefined behavior. For you it aborts whereas for me it renders badly. It seems that they patched this in version 3.2.1, so if you update to that, the problem should be resolved. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61512#61512 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] model rendering glitch on osg versions > 3.0.1
Thank you so much! Now it makes perfect sense why the behavior I was seeing didn't match the code; I didn't realize that the version on the repo wasn't released yet. I guess I'll see about putting 3.2.1 on all my computers. Thanks again! --Grey -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61511#61511 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] model rendering glitch on osg versions > 3.0.1
Hi, Robert I think the one that generated the output I posted was found here: http://www.thingiverse.com/thing:60726 --Grey -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61509#61509 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [osgPlugins] bug stl pugin?
This might be related to an issue that I'm currently having. It seems that during the transition from 3.0 to 3.2, binding per primitive was deprecated, but the STL format binds its normal vectors per primitive. To deal with this, there was an ad hoc addition to the STL plugin where the normals of each primitive is being copied and applied to each vertex of the primitive. In theory, this should be fine, but I've noticed that STL files are being rendered incorrectly, and I believe it has to do with the normal vector array being ... wrong somehow. When I print out the data in the normal vector arrays, many of the vectors have invalid magnitudes and look like their memory is uninitialized. It might be the case that something is very wrong about the way the normal array is being stored or initialized. It might be triggering a run time check for you where the program just quits, whereas for me it's just allowing it to be rendered even though the values are corrupted or invalid. But this is all speculation... -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61500#61500 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] model rendering glitch on osg versions > 3.0.1
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
Re: [osg-users] model rendering glitch on osg versions > 3.0.1
Hi, I'm running into an issue that I think is related, but not exactly the same. Prior to the 3.2 release, I could load an .stl file using the osgDB::readNodeFile(~) function, and it would come out looking like a diffuse white material. Presumably this was just a default setting somewhere in OSG or OpenGL, because the .stl file doesn't encode color or material properties. In the latest release, the file gets loaded as a shiny golden color (attachment "A"). I tried applying setGlobalDefaults() to the Viewer's Camera, but this had no effect. I also tried applying setGlobalDefaults() to the node which gets generated from osgDB::readNodeFile(~), and this changed the golden color to a blackish color (attachment "B"). I found that I could crawl through the auto-generated node and parse out its geodes and geometries, then change their color array to whatever I want. I imagine I could do something similar with their materials to get rid of the shininess. However, this is a problem for two reasons: (1) It's annoying, and more importantly (2) If some color/material properties are loaded from the file, I don't want to overwrite them. I'd really just like a way to get back the behavior prior to 3.2 where a loaded node would have some reasonable default rendering properties if the properties aren't provided by the file that's being loaded. If anyone has suggestions for how I might be able to accomplish this in a robust way, I would greatly appreciate it! I suspect there's probably some stupidly simple thing I could do that I'm just not aware of because of my inexperience with OSG. Thanks! -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61381#61381 Attachments: http://forum.openscenegraph.org//files/dark_robot_376.png http://forum.openscenegraph.org//files/gold_robot_174.png ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
