Re: [osg-users] model rendering glitch on osg versions 3.0.1
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 chaotic.actua...@gmail.com 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 osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Handling double precision data: node's meta-data or plugin data or what?
Hi Mike, 2014-11-04 8:22 GMT+01:00 Mike Connell michael.conn...@gmail.com: 1 Read your data into a Vec3Darray - as doubles 2 Decide upon a local origin - best may be the centroid of your data, but the first point is somewhat quicker to find. 3 Subtract the local origin from all the points in your array - they are now still doubles, but each is a much smaller number which can be accurately represented by a float 4 Build a osg::Geometry with a Vec3Array for vertices, using your translated points 5 Put the Geometry under an osg::MatrixTransform, set the MT translation to your local origin return the MT OK, now I understand. You *can* keep the original Vec3DArray if you want, but you probably don't need to, you'd have to compare the values there against the values of (local origin+p) to see if the difference is a problem for you, I doubt it will be. Indeed, I think that I can safely discard the double precision data once reduced in floats and decorated by the MatrixTransform. Furthermore this approach has the advantage of keeping only one vertex array copy in memory. Many thanks for the clarification, Émeric ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Swapping out geometry in the cull visitor for just the shadow camera?
Hey all, I have a shadowed scene that hosts a detailed city model and some 15000 objects using instanced geometry that also casts shadows. The instance positions are provided through a 2D float texture (128x128) to the vertex shader. To reduce the render times I was thinking that I should maybe replace the geometry of these instanced geometries with something much simpler. My shadow resolution is coarse and observers likely wouldn't notice the difference. Could it be a good idea to install a NodeCallback on the instanced geometry that replaces the Geometry of the geode with a cube while we're in the shadow camera pass, and reinstalls the original object when we're in the main camera pass? If possible I would like to avoid the overhead of having a second instanced geometry for just the shadow casters, as updating this 128x128 comes with some costs - and simply swapping out the geometry should accomplish that. Christian ___ 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] model rendering glitch on osg versions 3.0.1
Hi Grey,
I have just tested the OSG-3.2 branch and OSG svn/trunk and both load the
two .stl ( CoffeeSpoonHolder.stl and CoffeeSpoonHolder2.stl) perfectly,
with no odd lighting affects.
From the svn log for stl plugin there was a patch applied a couple months
after the OSG-3.2.0 release:
$ svn log ReaderWriterSTL.cpp
r13821 | robert | 2013-10-02 12:09:22 +0100 (Wed, 02 Oct 2013) | 21 lines
From Björn Hein, it seems that for generating per vertex normals as
stated in the
comment, two of them are missing. This results in wrong display of
STL-files regarding normals. Following simple fix seems to work:
Index: ReaderWriterSTL.cpp
===
--- ReaderWriterSTL.cpp(Revision 13797)
+++ ReaderWriterSTL.cpp(Arbeitskopie)
@@ -108,6 +108,8 @@
++itr)
{
perVertexNormals-push_back(*itr);
+perVertexNormals-push_back(*itr);
+perVertexNormals-push_back(*itr);
}
geom-setNormalArray(perVertexNormals.get(),
osg::Array::BIND_PER_VERTEX);
This means the patch will be part of OSG-3.2.1 so I'd recommend you update
to this version of the OSG.
Robert.
On 4 November 2014 15:48, Michael Grey chaotic.actua...@gmail.com wrote:
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
___
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] [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
[osg-users] Slaves, RTT, and HUD
Hello, I'm looking to get the following scenario working: A scene with a HUD rendering on a distortion mesh using slave cameras. What I've tried so far is... 1. A normal Viewer class with two Cameras in the scene graph, one on a pre-render pass that renders the main scene to a texture and one on a post-render pass that renders a screen space mesh with the other Camera's texture applied to it. 2. A Viewer class with two Cameras attached as slaves, with the same pre- and post-render setup as above. The RTT (pre-render) Camera has the main scene as the child and the mesh (post-render) Camera has just the screen space mesh as a child. For these, I can get a HUD displaying on the following Cameras when I attach it as a child to the respective Camera: - 1's pre-render Camera, attached to the texture and set up as a FBO - 1's post-render Camera - 2's post-render Camera For my HUD, I'm simply creating a Camera with an Absolute reference frame, orthogonal 2D projection, and on the post-render pass. See osghud.cpp, as I've pretty much copied that with the modification of an optional Texture parameter. The part I'm having trouble getting to work is getting that HUD rendering to a texture when that RTT Camera is a slave of a View. The thing that baffles me is I can get it working on a non-slave RTT Camera in the same way, and I can get it working on a non-RTT slave Camera, but not the intersection of both. I've tried searching for a similar solution, but I haven't found anything for this specific scenario. Any help or direction would be appreciated. :) ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Slaves, RTT, and HUD
Hi Ben, Have a look at the osgdistortion example as it does exactly what you describe you want to do. Robert. On 4 November 2014 19:53, Ben Strukus ben.stru...@flyte.com wrote: Hello, I'm looking to get the following scenario working: A scene with a HUD rendering on a distortion mesh using slave cameras. What I've tried so far is... 1. A normal Viewer class with two Cameras in the scene graph, one on a pre-render pass that renders the main scene to a texture and one on a post-render pass that renders a screen space mesh with the other Camera's texture applied to it. 2. A Viewer class with two Cameras attached as slaves, with the same pre- and post-render setup as above. The RTT (pre-render) Camera has the main scene as the child and the mesh (post-render) Camera has just the screen space mesh as a child. For these, I can get a HUD displaying on the following Cameras when I attach it as a child to the respective Camera: - 1's pre-render Camera, attached to the texture and set up as a FBO - 1's post-render Camera - 2's post-render Camera For my HUD, I'm simply creating a Camera with an Absolute reference frame, orthogonal 2D projection, and on the post-render pass. See osghud.cpp, as I've pretty much copied that with the modification of an optional Texture parameter. The part I'm having trouble getting to work is getting that HUD rendering to a texture when that RTT Camera is a slave of a View. The thing that baffles me is I can get it working on a non-slave RTT Camera in the same way, and I can get it working on a non-RTT slave Camera, but not the intersection of both. I've tried searching for a similar solution, but I haven't found anything for this specific scenario. Any help or direction would be appreciated. J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Slaves, RTT, and HUD
Hi Robert, The osgdistortion example is a great resource and I've used it quite a bit to set up the RTT and the distortion mesh, however when it comes to rendering a HUD (text, in my case) to that texture using slaves, I'm not seeing that being done in the example. Here's what I have: - A slave camera that renders the main scene to a texture. - A slave camera that renders a screen-space mesh with the above texture applied to it. - A lone camera acting as a HUD that I would like to render to the texture, but can't seem to get this working. I've tried attaching the lone camera as a child of the RTT camera, and that doesn't seem to work. I can get it to work when the RTT camera isn't a slave, but as soon as I make it a slave it doesn't work. I can get the HUD to render directly to the screen when I attach it as a child of the screen-space mesh camera, however it won't appear distorted. From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Tuesday, November 04, 2014 12:14 PM To: OpenSceneGraph Users Subject: Re: [osg-users] Slaves, RTT, and HUD Hi Ben, Have a look at the osgdistortion example as it does exactly what you describe you want to do. Robert. On 4 November 2014 19:53, Ben Strukus ben.stru...@flyte.commailto:ben.stru...@flyte.com wrote: Hello, I'm looking to get the following scenario working: A scene with a HUD rendering on a distortion mesh using slave cameras. What I've tried so far is... 1. A normal Viewer class with two Cameras in the scene graph, one on a pre-render pass that renders the main scene to a texture and one on a post-render pass that renders a screen space mesh with the other Camera's texture applied to it. 2. A Viewer class with two Cameras attached as slaves, with the same pre- and post-render setup as above. The RTT (pre-render) Camera has the main scene as the child and the mesh (post-render) Camera has just the screen space mesh as a child. For these, I can get a HUD displaying on the following Cameras when I attach it as a child to the respective Camera: - 1's pre-render Camera, attached to the texture and set up as a FBO - 1's post-render Camera - 2's post-render Camera For my HUD, I'm simply creating a Camera with an Absolute reference frame, orthogonal 2D projection, and on the post-render pass. See osghud.cpp, as I've pretty much copied that with the modification of an optional Texture parameter. The part I'm having trouble getting to work is getting that HUD rendering to a texture when that RTT Camera is a slave of a View. The thing that baffles me is I can get it working on a non-slave RTT Camera in the same way, and I can get it working on a non-RTT slave Camera, but not the intersection of both. I've tried searching for a similar solution, but I haven't found anything for this specific scenario. Any help or direction would be appreciated. :) ___ osg-users mailing list osg-users@lists.openscenegraph.orgmailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Swapping out geometry in the cull visitor for just the shadow camera?
Hi Christion, you could use a switch above the 2 geometries or different cullmasks for the geodes and control it via the cameras cullmask/setting the switch before culling Hey all, I have a shadowed scene that hosts a detailed city model and some 15000 objects using instanced geometry that also casts shadows. The instance positions are provided through a 2D float texture (128x128) to the vertex shader. To reduce the render times I was thinking that I should maybe replace the geometry of these instanced geometries with something much simpler. My shadow resolution is coarse and observers likely wouldn't notice the difference. Could it be a good idea to install a NodeCallback on the instanced geometry that replaces the Geometry of the geode with a cube while we're in the shadow camera pass, and reinstalls the original object when we're in the main camera pass? If possible I would like to avoid the overhead of having a second instanced geometry for just the shadow casters, as updating this 128x128 comes with some costs - and simply swapping out the geometry should accomplish that. Christian ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
