Re: [osg-users] Missing ShapeDrawables in .obj export
Thanks Robert, I understand ShapeDrawable is an osg construct that obj won't understand. But i was under the impression that the conversion out of the osg format would de-OSG all shapes. in other words, make a mesh out of the ShapeDrawable. But clearly this is not the case. Is this feature on the todo list? Also, i know that the VRML format has some concept of primitive shapes. Do you think that the osg to wrl conversion would include the primitive ShapeDrawables? I would just try it, but unfortunately i did not build osg with vrml writing capabilities, and i won't have the opportunity to rebuild osg for a while. Thanks, -Ben From: osg-users-boun...@lists.openscenegraph.org [osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield [robert.osfi...@gmail.com] Sent: Wednesday, November 25, 2009 5:08 AM To: OpenSceneGraph Users Subject: Re: [osg-users] Missing ShapeDrawables in .obj export Hi Ben, Does .obj support ShapeDrawable? No... it knows nothing about ShapeDrawable so there is no way it can be exported without conveting it into another form that .obj supports. .obj support just meshes, lines and points so if you want to export to .obj then you'll need to stick to these types of objects in your scene graph. Robert, On Wed, Nov 25, 2009 at 5:34 AM, Ben Axelrod wrote: > I have a scene that has some primitive shapes in it created with > ShapeDrawables. When i save the scene to a .obj file using > osgDB::writeNodeFile() the ShapeDrawables don't show up in the file, but the > floor plane i created with simple geometry does. If i save it to a .osg file > instead, then everything is in in the file. I get the same results if i use > osgconv to convert my .osg file into a .obj. > > Note: i am viewing the exported files with osgviewer. And i am using OSG > version 2.6. > > Any clue on why this is or how to get around it? > > Thanks, > -Ben > ___ > 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Missing ShapeDrawables in .obj export
I have a scene that has some primitive shapes in it created with ShapeDrawables. When i save the scene to a .obj file using osgDB::writeNodeFile() the ShapeDrawables don't show up in the file, but the floor plane i created with simple geometry does. If i save it to a .osg file instead, then everything is in in the file. I get the same results if i use osgconv to convert my .osg file into a .obj. Note: i am viewing the exported files with osgviewer. And i am using OSG version 2.6. Any clue on why this is or how to get around it? Thanks, -Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Nested transparent objects
I am trying to view transparent objects inside of other transparent objects. My objects are simple ShapeDrawables with some color and alpha transparency. I am seeing strange behavior where the inner object is sometimes completely hidden by the outer object depending on camera angle. Also, some of the object edges that should be visible are not. (Again, depending on camera angle). In the attached images: "badalpha.png" there is a small red cube partially inside of a larger green cube. they both have some transparency and you should be able to see through both objects. however, some edges of the green cube are completely hidden by the red cube. The desired behavior can be seen in "badalphamodbyhand.png" in which I modified to show what should be shown. This must be a common problem, but I searched the archives and it did not turn up much. my GL_DEPTH_TEST attribute is on as well as GL_BLEND. I am using OSG 2.6.0 with an NVidia series 7 graphics card. Is there some way to improve the transparency visualization? Thanks, -Ben <><>___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VRML Normal Issue
I think we are agreeing with each other. I agree the simplest thing for a user is to specify normals in the file for the best control over shading. And I agree that in order to support the crease angle property, we will have to duplicate vertices. Despite the crease angle being a "kludge", I do think that it should be implemented. That is why I submitted the code, in case anyone wanted to implement the crease angle, I think that would be how to do it. Before, you said that duplicating vertices would lead to artifacts. Can you elaborate on this? I don't see how it would when we are in the sharp edge case, and we give it a proper normal, and point the proper face index at the new vertex. Thanks, -Ben -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jan Ciger Sent: Thursday, March 26, 2009 5:07 PM To: OpenSceneGraph Users Subject: Re: [osg-users] VRML Normal Issue -BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ben Axelrod wrote: > Can normals per primitive and normals per vertex both be used in a > single shape? Not that I am aware of. > > If not, the only way I can imagine having a shape with some smooth > and some sharp edges is if there is one normal per vertex per face. > Just like the diagram in the VRML spec shows, if a vertex has 2 faces > connected to it, it needs 2 normals for a sharp edge, and either 1 or > 2 for a smooth edge. That's right, however, if you do not specify the vertex normals explicitly in the model, the vertex normals are calculated from the *face normals* using the crease angle. If the face normals have an angle smaller than the crease angle, the vertex normals will be an average of the two face normals. For sharp edges you will indeed have to duplicate the vertices to accommodate the different face normals (as explained here: http://www.songho.ca/opengl/gl_vertexarray.html) On the other hand, if you want only sharp edges, you can bind normals per face and save yourself this whole escapade. Honestly, it is simpler to export the vertex normals from whatever tool you are using to produce the data than to fidget with the crease angle - it is only a kludge to let the program guess the model author's intentions. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJy+5tn11XseNj94gRAvHGAKCZxOcaPU9FnL73O06533yTtpSalwCg6GFc Kz6Y4w31hZgcHRjbDyna/jY= =dKWV -END PGP SIGNATURE- ___ 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] VRML Normal Issue
But normals per primitive or per vertex are 'global' for the entire shape. Aren't they? The crease angle is a 'local' feature so that you can have a shape with some smooth and some sharp edges. Can normals per primitive and normals per vertex both be used in a single shape? If not, the only way I can imagine having a shape with some smooth and some sharp edges is if there is one normal per vertex per face. Just like the diagram in the VRML spec shows, if a vertex has 2 faces connected to it, it needs 2 normals for a sharp edge, and either 1 or 2 for a smooth edge. -Ben -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jan Ciger Sent: Thursday, March 26, 2009 9:08 AM To: OpenSceneGraph Users Subject: Re: [osg-users] VRML Normal Issue -BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, Ben Axelrod wrote: > Thanks for the info. > > I took a look at the code. Adding crease angle support does seem > tricky since I think we would have to create new vertex points on the > fly to accommodate 2 or more different normal vectors at that point. > Here is some off the cuff pseudo code. > I do not see why you would want to do that. Just set the normal binding to be per primitive/face and not per vertex if you want to have sharp edges and define face normals. Otherwise, if the corners/edges are to be smoothed, you use normal binding per vertex and calculate normal as an average of the face normals of the faces adjacent to the vertex. There is no need to duplicate any vertices - in fact, that would only give you artifacts. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJy34Vn11XseNj94gRAlKlAJ49ebboolwzo75PcdLNog6W5y5vtgCggSZC 2e+pdTpYqi/E3IcYBd6wj1E= =+rJG -END PGP SIGNATURE- ___ 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] VRML Normal Issue
Thanks for the info.
I took a look at the code. Adding crease angle support does seem tricky since
I think we would have to create new vertex points on the fly to accommodate 2
or more different normal vectors at that point. Here is some off the cuff
pseudo code.
for (int i = 0; i != *it; ++i) // line 268 of IndexedFaceSet.cpp
{
float angle = acos((*normals)[indices[index + i]] * normal);
if (angle <= creaseAngle)
{
(*normals)[indices[index + i]] += normal;
}
else
{
// clone this vertex so we can give it 2 normals
coords.push_back(coords[indices[index + i]]);
// give it the new normal
normals.push_back(normal)
// now point this face at the new vertex
indices[index + i] = coords.size() - 1;
}
}
I am not sure if modifying the vertex and normal array on the fly is wise,
possible, or even if that is how it's done. But like I said, it is pseudo code.
What do you think?
-Ben
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jan Ciger
Sent: Wednesday, March 25, 2009 4:43 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] VRML Normal Issue
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ben Axelrod wrote:
> Just to clarify, the way the normals *should* work is sketched in the
> attached image. Please verify.
>
> When the angle between 2 faces is sharper than the crease angle,
> there is one normal per face, and when the angle is smoother than the
> crease angle, the normal is averaged.
Correct - what I had in mind was the angle between the normals, not the
faces. The end result would be the same, but this is how the VRML spec
specifies it and it is easier to calculate:
> The creaseAngle field, used by the ElevationGrid, Extrusion, and
> IndexedFaceSet nodes, affects how default normals are generated. If
> the angle between the geometric normals of two adjacent faces is less
> than the crease angle, normals shall be calculated so that the faces
> are smooth-shaded across the edge; otherwise, normals shall be
> calculated so that a lighting discontinuity across the edge is
> produced. For example, a crease angle of .5 radians means that an
> edge between two adjacent polygonal faces will be smooth shaded if
> the geometric normals of the two faces form an angle that is less
> than .5 radians. Otherwise, the faces will appear faceted. Crease
> angles must be greater than or equal to 0.0.
(from:
http://accad.osu.edu/~pgerstma/class/vnv/resources/info/AnnotatedVrmlRef/ch2-26.htm)
However, as I said - right now the loader will average *always*,
regardless of the crease angle. This is even documented in the code:
IndexedFaceSet.cpp, line 241:
> // GvdB: So I ended up computing the smoothing normals myself. Also,
> I might add support for "creaseAngle" if a big need for it rises. //
> However, for now I can perfectly live with the fact that all edges
> are smoothed despite the use of a crease angle.
Regards,
Jan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFJypdon11XseNj94gRAkaaAKDfByiriOZH8ntvtFI6hYbA/7VW2QCfX1nX
Bpzs2QlM9aiHrkhk40HJt64=
=KjWi
-END PGP SIGNATURE-
___
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] VRML Normal Issue
Thanks for the info.
I took a look at the code. Adding crease angle support does seem tricky since
I think we would have to create new vertex points on the fly to accommodate 2
or more different normal vectors at that point. Here is some off the cuff
pseudo code.
for (int i = 0; i != *it; ++i) // line 268 of IndexedFaceSet.cpp
{
float angle = acos((*normals)[indices[index + i]] * normal);
if (angle <= creaseAngle)
{
(*normals)[indices[index + i]] += normal;
}
else
{
// clone this vertex so we can give it 2 normals
coords.push_back(coords[indices[index + i]]);
// give it the new normal
normals.push_back(normal)
// now point this face at the new vertex
indices[index + i] = coords.size() - 1;
}
}
I am not sure if modifying the vertex and normal array on the fly is wise,
possible, or even if that is how it's done. But like I said, it is pseudo code.
What do you think?
-Ben
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jan Ciger
Sent: Wednesday, March 25, 2009 4:43 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] VRML Normal Issue
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ben Axelrod wrote:
> Just to clarify, the way the normals *should* work is sketched in the
> attached image. Please verify.
>
> When the angle between 2 faces is sharper than the crease angle,
> there is one normal per face, and when the angle is smoother than the
> crease angle, the normal is averaged.
Correct - what I had in mind was the angle between the normals, not the
faces. The end result would be the same, but this is how the VRML spec
specifies it and it is easier to calculate:
> The creaseAngle field, used by the ElevationGrid, Extrusion, and
> IndexedFaceSet nodes, affects how default normals are generated. If
> the angle between the geometric normals of two adjacent faces is less
> than the crease angle, normals shall be calculated so that the faces
> are smooth-shaded across the edge; otherwise, normals shall be
> calculated so that a lighting discontinuity across the edge is
> produced. For example, a crease angle of .5 radians means that an
> edge between two adjacent polygonal faces will be smooth shaded if
> the geometric normals of the two faces form an angle that is less
> than .5 radians. Otherwise, the faces will appear faceted. Crease
> angles must be greater than or equal to 0.0.
(from:
http://accad.osu.edu/~pgerstma/class/vnv/resources/info/AnnotatedVrmlRef/ch2-26.htm)
However, as I said - right now the loader will average *always*,
regardless of the crease angle. This is even documented in the code:
IndexedFaceSet.cpp, line 241:
> // GvdB: So I ended up computing the smoothing normals myself. Also,
> I might add support for "creaseAngle" if a big need for it rises. //
> However, for now I can perfectly live with the fact that all edges
> are smoothed despite the use of a crease angle.
Regards,
Jan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFJypdon11XseNj94gRAkaaAKDfByiriOZH8ntvtFI6hYbA/7VW2QCfX1nX
Bpzs2QlM9aiHrkhk40HJt64=
=KjWi
-END PGP SIGNATURE-
___
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] VRML Normal Issue
Just to clarify, the way the normals *should* work is sketched in the attached image. Please verify. When the angle between 2 faces is sharper than the crease angle, there is one normal per face, and when the angle is smoother than the crease angle, the normal is averaged. Thanks, -Ben -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jan Ciger Sent: Tuesday, March 24, 2009 1:36 PM To: OpenSceneGraph Users Subject: Re: [osg-users] VRML Normal Issue -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ben Axelrod wrote: > Thanks for the info. Is this standard procedure with mesh files? > Because I have noticed similar affects with a variety of file > formats. > > I agree that when no normals are specified, the proper behavior for > the parser is to use one normal per face, and calculate the face > normals from the vertex points, but the shading I see in badbox.wrl > does not look like one normal per face, it looks like one normal per > vertex. The shading of goodbox.wrl looks like one normal per face to > me. Am I mistaken on how these should look? I can't test it right now, because I do not have the VRML plugin compiled at the moment. I have loaded the models in WhiteDune editor, and both look OK to me, with the badbox one showing some artifacts. I had a look at the code and if you do not specify any normals, the OSG loader will not really handle it right. It seems that in that case an average normal out of the adjacent faces is computed and used per-vertex (i.e. the edges and corners are smoothed ...) This isn't completely correct, the VRML spec specifies use of crease angle parameter that will make all angles smaller than this one averaged and ones larger sharp. However, this is not intended to be a 100% compliant VRML viewer. Originally, the case without normals was not handled at all. You have basically two options: - - generate your VRML including normals - - fix the VRML plugin code to include handling of the crease angle (in IndexedFaceSet.cpp, around lines 240 and on in the VRML plugin) Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJyRn8n11XseNj94gRAhPtAKDd+ov0409iUlfCEoPs0Jgz8z2V/QCfTV6C trLfTvJTRgm+KjV2GCYphTA= =dT7/ -END PGP SIGNATURE- ___ 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] VRML Normal Issue
Thanks for the info. Is this standard procedure with mesh files? Because I have noticed similar affects with a variety of file formats. I agree that when no normals are specified, the proper behavior for the parser is to use one normal per face, and calculate the face normals from the vertex points, but the shading I see in badbox.wrl does not look like one normal per face, it looks like one normal per vertex. The shading of goodbox.wrl looks like one normal per face to me. Am I mistaken on how these should look? Thanks, -Ben -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jan Ciger Sent: Saturday, March 21, 2009 12:23 PM To: OpenSceneGraph Users Subject: Re: [osg-users] VRML Normal Issue -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello Ben, Ben Axelrod wrote: > I have noticed a very strange issue regarding VRML file rendering. This > issue happens in OSG viewer version 2.6, with openVRML version 0.14.3. > ... > Are there some VRML flags to prevent this behavior? Is this a bug in > the VRML parser? If so, is this part of OSG or openVRML? I happen to be one of the authors of the VRML plugin. I had a look at your files and badbox.wrl is incorrect. You need to explicitly specify the vertex normals, otherwise it will assume normal per face and if even those are not provided, calculate them from the vertices - leading to the behavior you are describing. The behavior is correct, IMO - the parser has no means to know what you want if you do not specify the normals. Regards, Jan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org iD8DBQFJxRRkn11XseNj94gRAsiVAKCNve8MXKvwkJ75hLM6kZcn1gZzfwCdH+Pr A8CF98dTVjegSqXWeKQdNm4= =NbCl -END PGP SIGNATURE- ___ 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] ShadowMap Required OpenGL Extensions
Oh cool, how do you do that? Thanks, -Ben From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Tomlinson, Gordon Sent: Monday, March 23, 2009 3:39 PM To: OpenSceneGraph Users Subject: Re: [osg-users] ShadowMap Required OpenGL Extensions We handle card discrepancies like texture size, number of units etc, by querying the the cards cabalilties and setting up our limits in our programs from them. ( now some dang cards can tell out right lies about what they support and drop to s/w mode at times but thats another story ) Gordon Product Manager 3d __ Gordon Tomlinson Email : gtomlinson @ overwatch.textron.com __ From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jason Daly Sent: Monday, March 23, 2009 3:24 PM To: OpenSceneGraph Users Subject: Re: [osg-users] ShadowMap Required OpenGL Extensions Ben Axelrod wrote: Thanks, Do you think that changing the shadow texture size will have any affect here? I have noticed a somewhat similar failure of ShadowMap when I have a very large mesh file, and decreasing the shadow texture size seems to fix that. Oh, possibly. The GeForce 5's might have had a smaller max texture size, too. It's been a while, so I don't remember the numbers exactly. In general, though, they had tighter limits than the modern cards. --"J" ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShadowMap Required OpenGL Extensions
Thanks, Do you think that changing the shadow texture size will have any affect here? I have noticed a somewhat similar failure of ShadowMap when I have a very large mesh file, and decreasing the shadow texture size seems to fix that. -Ben From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jason Daly Sent: Monday, March 23, 2009 1:40 PM To: OpenSceneGraph Users Subject: Re: [osg-users] ShadowMap Required OpenGL Extensions Ben Axelrod wrote: I should probably specify the graphics cards in question. The working card is a NVidia 7300 LE. The card that passes the test, but still does not work is a NVidia NV37GL [Quadro FX 330/Quadro NVS280] (rev a2) The NV37 is a GeForce 5-era card, so it should fully support programmable shading, although there were limits on how long and/or complex the shaders could be. I wonder if you're running into a shader instruction limit or something like that. --"J" ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ShadowMap Required OpenGL Extensions
I should probably specify the graphics cards in question.
The working card is a NVidia 7300 LE. The card that passes the test, but still
does not work is a NVidia NV37GL [Quadro FX 330/Quadro NVS280] (rev a2)
-Ben
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ben Axelrod
Sent: Friday, March 20, 2009 12:42 PM
To: OpenSceneGraph Users
Subject: [osg-users] ShadowMap Required OpenGL Extensions
My application checks for the existence of some OpenGL extensions before
allowing ShadowMap to be turned on. So far, I have been using this test:
if (GL_EXT_framebuffer_object &&
(GL_ARB_fragment_program || GL_EXT_fragment_program) &&
(GL_ARB_fragment_program_shadow || GL_EXT_fragment_program_shadow))
{
//enable ShadowMap
}
Note that I am using the 'fixed function fallback' by calling clearShaderList()
after init() but before first frame.
However, I have come across a graphics card that passes this test, yet does not
render shadows properly.
This graphics card has these key extensions:
GL_EXT_framebuffer_object
GL_ARB_fragment_program
GL_ARB_fragment_program_shadow
GL_ARB_fragment_shader
As far as I can tell, the only extensions this card does NOT have, that my
other card (which renders shadows fine) does is:
GL_ARB_texture_non_power_of_two
GL_ATI_texture_mirror_once
GL_EXT_clip_volume_hint
GL_EXT_texture_mirror_clamp
Does ShadowMap require any of these extensions?
Also, FYI, the graphics card in question has many more extensions that my
working card does not have:
GL_ARB_fragment_shader
GL_ARB_half_float_pixel
GL_ARB_multisample
GL_ARB_pixel_buffer_object
GL_ARB_shader_objects
GL_ARB_shading_language_100
GL_ARB_texture_rectangle
GL_ARB_transpose_matrix
GL_ARB_vertex_buffer_object
GL_ARB_vertex_shader
GL_S3_s3tc
GL_EXT_compiled_vertex_array
GL_EXT_Cg_shader
GL_EXT_framebuffer_blit
GL_EXT_framebuffer_multisample
GL_EXT_gpu_program_parameters
GL_EXT_packed_depth_stencil
GL_EXT_pixel_buffer_object
GL_EXT_point_parameters
GL_EXT_stencil_two_side
GL_EXT_texture_compression_s3tc
GL_EXT_texture_cube_map
GL_EXT_texture_filter_anisotropic
GL_EXT_texture_lod
GL_EXT_texture_sRGB
GL_EXT_timer_query
GL_IBM_rasterpos_clip
GL_KTX_buffer_region
GL_NV_copy_depth_to_color
GL_NV_depth_clamp
GL_NV_fence
GL_NV_float_buffer
GL_NV_fog_distance
GL_NV_fragment_program
GL_NV_fragment_program_option
GL_NV_framebuffer_multisample_coverage
GL_NV_half_float
GL_NV_multisample_filter_hint
GL_NV_occlusion_query
GL_NV_packed_depth_stencil
GL_NV_pixel_data_range
GL_NV_point_sprite
GL_NV_primitive_restart
GL_NV_register_combiners
GL_NV_register_combiners2
GL_NV_texture_compression_vtc
GL_NV_texture_env_combine4
GL_NV_texture_expand_normal
GL_NV_texture_shader
GL_NV_texture_shader2
GL_NV_texture_shader3
GL_NV_vertex_array_range
GL_NV_vertex_array_range2
GL_NV_vertex_program
GL_NV_vertex_program1_1
GL_NV_vertex_program2
GL_NV_vertex_program2_option
GL_SUN_slice_accum
Thanks,
-Ben
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] VRML Normal Issue
I have noticed a very strange issue regarding VRML file rendering. This issue happens in OSG viewer version 2.6, with openVRML version 0.14.3. Please view the two attached vrml files and observe very different shading on the 2 cubes. The only difference between the files is that in goodbox.vml, the coordinate indices are used only once per triangle. In badbox.wrl, the 8 vertices are reused for multiple triangles. You can see that in goodbox.vml, I duplicated the vertices so that they would be used only once. For example, for index '0', I copied it and made it also index 8 through 12, then used those new indices in the coordIndex[] definition. I think that the vrml parser tries to interpolate vertex vectors from the triangles they belong to. If a vertex belongs to two ore more triangles which are not co-planar then the vertex vector is something in between the different surface normals of the different triangles. And because normal vectors along a triangle surface are interpolated from the vertex normals, this leads to a gradient along the triangle surface (because the vertex normals are not pointing in the same direction). Hence, if only co-planar triangles share their points the problem disappears. Are there some VRML flags to prevent this behavior? Is this a bug in the VRML parser? If so, is this part of OSG or openVRML? Thanks, -Ben goodbox.wrl Description: goodbox.wrl badbox.wrl Description: badbox.wrl ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] ShadowMap Required OpenGL Extensions
My application checks for the existence of some OpenGL extensions before
allowing ShadowMap to be turned on. So far, I have been using this test:
if (GL_EXT_framebuffer_object &&
(GL_ARB_fragment_program || GL_EXT_fragment_program) &&
(GL_ARB_fragment_program_shadow || GL_EXT_fragment_program_shadow))
{
//enable ShadowMap
}
Note that I am using the 'fixed function fallback' by calling clearShaderList()
after init() but before first frame.
However, I have come across a graphics card that passes this test, yet does not
render shadows properly.
This graphics card has these key extensions:
GL_EXT_framebuffer_object
GL_ARB_fragment_program
GL_ARB_fragment_program_shadow
GL_ARB_fragment_shader
As far as I can tell, the only extensions this card does NOT have, that my
other card (which renders shadows fine) does is:
GL_ARB_texture_non_power_of_two
GL_ATI_texture_mirror_once
GL_EXT_clip_volume_hint
GL_EXT_texture_mirror_clamp
Does ShadowMap require any of these extensions?
Also, FYI, the graphics card in question has many more extensions that my
working card does not have:
GL_ARB_fragment_shader
GL_ARB_half_float_pixel
GL_ARB_multisample
GL_ARB_pixel_buffer_object
GL_ARB_shader_objects
GL_ARB_shading_language_100
GL_ARB_texture_rectangle
GL_ARB_transpose_matrix
GL_ARB_vertex_buffer_object
GL_ARB_vertex_shader
GL_S3_s3tc
GL_EXT_compiled_vertex_array
GL_EXT_Cg_shader
GL_EXT_framebuffer_blit
GL_EXT_framebuffer_multisample
GL_EXT_gpu_program_parameters
GL_EXT_packed_depth_stencil
GL_EXT_pixel_buffer_object
GL_EXT_point_parameters
GL_EXT_stencil_two_side
GL_EXT_texture_compression_s3tc
GL_EXT_texture_cube_map
GL_EXT_texture_filter_anisotropic
GL_EXT_texture_lod
GL_EXT_texture_sRGB
GL_EXT_timer_query
GL_IBM_rasterpos_clip
GL_KTX_buffer_region
GL_NV_copy_depth_to_color
GL_NV_depth_clamp
GL_NV_fence
GL_NV_float_buffer
GL_NV_fog_distance
GL_NV_fragment_program
GL_NV_fragment_program_option
GL_NV_framebuffer_multisample_coverage
GL_NV_half_float
GL_NV_multisample_filter_hint
GL_NV_occlusion_query
GL_NV_packed_depth_stencil
GL_NV_pixel_data_range
GL_NV_point_sprite
GL_NV_primitive_restart
GL_NV_register_combiners
GL_NV_register_combiners2
GL_NV_texture_compression_vtc
GL_NV_texture_env_combine4
GL_NV_texture_expand_normal
GL_NV_texture_shader
GL_NV_texture_shader2
GL_NV_texture_shader3
GL_NV_vertex_array_range
GL_NV_vertex_array_range2
GL_NV_vertex_program
GL_NV_vertex_program1_1
GL_NV_vertex_program2
GL_NV_vertex_program2_option
GL_SUN_slice_accum
Thanks,
-Ben
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenGL EXTENSION support
I just get them right out of OpenGL. But you have to have the current OpenGL context. const char* extensions = (const char*)glGetString(GL_EXTENSIONS); -Ben From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of ami guru Sent: Wednesday, March 18, 2009 5:09 PM To: OpenSceneGraph Users Subject: [osg-users] OpenGL EXTENSION support Hello forum, Is there any class or interface in OSG that can query and print out the supported extensions within the OpenGL driver ? Regards Sajjad ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] cast ray into scene
I have been using osgUtil::PickVisitor for a while now to pick objects in my tree under the mouse. But now I need to cast a ray into the scene under the mouse and manually intersect it with an imaginary plane. Is there some helper function to do this mouse ray cast for me? Specifically, something that would take as input 2 ints for the position of the mouse, and maybe the camera or projection and view matrices, then output a vector? Thanks, -Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] strange object clipping
Thanks guys, I found the problem. I was not dirtying the bound for all of my ShapeDrawables. I was only calling dirtyBound() on the parent geode. I guess this is not sufficient. -Ben -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Thursday, March 05, 2009 3:48 AM To: OpenSceneGraph Users Subject: Re: [osg-users] strange object clipping HI Ben, On Thu, Mar 5, 2009 at 2:01 AM, Ben Axelrod wrote: > Well, i tried it in osgviewer and there was no clipping. any ideas as to > what might cause this in my app? If osgviewer works on the data, so it's only the viewer that is different then it points to your viewer setup as being the problem. However, you've not specified anything about how you have set up the viewer, so pray how might I have the knowledge required to diagnose this problem? Let me ask a similar question and see if you can answer it. Description of problem. I have a box, and inside that box is a ball. Question: I don't know what colour of the is ball is, could you tell me please. Robert. ___ 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] strange object clipping
Well, i tried it in osgviewer and there was no clipping. any ideas as to what might cause this in my app? Thanks, -Ben From: osg-users-boun...@lists.openscenegraph.org [osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield [robert.osfi...@gmail.com] Sent: Saturday, February 28, 2009 2:49 AM To: OpenSceneGraph Users Subject: Re: [osg-users] strange object clipping Hi Ben, The visuals do look like they suggest a problem with the near/far computation or clamping of near/far. I'm not aware of a bugs in the bounding box calculation of ShapeDrawable, but it could certainly be an area to look into. Could you output the model to .osg, test this in osgviewer to see if the problem still exists and if it does then post this model so others can test against it. Robert. On Fri, Feb 27, 2009 at 9:10 PM, Ben Axelrod wrote: > > Hi, > > We are seeing some strange clipping of objects in OSG 2.6. It happens with > large numbers of ShapeDrawable boxes and spheres. What should be displayed > in the attached images is a large rectangular grid of small, colored cubes. > > The structure of our osg tree looks like: > > osg::Group > | > \|/ > osg::MatricTransform > | > \|/ > osg::Geode > ||| > \|/ \|/ \|/ > > Multiple ShapeDrawable () > > > Our camera is an osgViewer. > > "cube1.png" demonstrates the clipping we are seeing. the cubes are sliced, > as if by the near clipping plane of the camera. > > "cube2.png" has the camera and objects in the exact same positions, except a > large cone shape is added. You can see that the clipping is gone. We > believe this is due to some bounding box miscalculations by OSG. When the > other object is added, the bounding box can be calculated properly, so the > cubes are not cut. > > Any ideas on what is causing this issue and what can possibly be done about > it? > > I have heard that ShapeDrawables is not very efficient, and is only meant for > fast debugging. Will converting the ShapeDrawables to straight Geometry fix > it? > > Thanks, > -Ben > > ___ > 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::View NO_LIGHT bug?
I still don't know why osg::View::NO_LIGHT doesn't work, but to answer my own
questions, to turn off the default light completely:
_viewer->getCamera()->getView()->setLightingMode(osg::View::HEADLIGHT);
osg::Light* light = _viewer->getCamera()->getView()->getLight();
if (light != NULL)
{
light->setAmbient(osg::Vec4(0,0,0,1));
light->setDiffuse(osg::Vec4(0,0,0,1));
light->setSpecular(osg::Vec4(0,0,0,1));
}
-Ben
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Ben Axelrod
Sent: Tuesday, February 17, 2009 11:36 AM
To: osg-users@lists.openscenegraph.org
Subject: [osg-users] osg::View NO_LIGHT bug?
I cannot seem to turn off the light in osg::View. I can change it between
headlight and sky light, but when I try NO_LIGHT, I still get the headlight.
_viewer->getCamera()->getView()->setLightingMode(osg::View::SKY_LIGHT); //works
_viewer->getCamera()->getView()->setLightingMode(osg::View::HEADLIGHT); //works
_viewer->getCamera()->getView()->setLightingMode(osg::View::NO_LIGHT); //still
get headlight
How can I turn off this default light? How is it related to the osg::Lights in
the scene? I noticed when I add an osg::Light, then the headlight is
overridden. How can I change the light parameters of the SKY_LIGHT or
HEADLIGHT?
I am using osg version 2.6.
Thanks,
-Ben
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osg::View NO_LIGHT bug?
I cannot seem to turn off the light in osg::View. I can change it between headlight and sky light, but when I try NO_LIGHT, I still get the headlight. _viewer->getCamera()->getView()->setLightingMode(osg::View::SKY_LIGHT); //works _viewer->getCamera()->getView()->setLightingMode(osg::View::HEADLIGHT); //works _viewer->getCamera()->getView()->setLightingMode(osg::View::NO_LIGHT); //still get headlight How can I turn off this default light? How is it related to the osg::Lights in the scene? I noticed when I add an osg::Light, then the headlight is overridden. How can I change the light parameters of the SKY_LIGHT or HEADLIGHT? I am using osg version 2.6. Thanks, -Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] default lighting
When I don't have any lights in my scene, and my viewer's lighting mode is set to no_light: osgViewer::Viewer() -> getCamera()->getView()->setLightingMode(osg::View::NO_LIGHT) there is still some default lighting in the scene. Where does this light come from, and how can I change it to be brighter or darker? Thanks, -Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] openGL extensions
Hi Jean, Thanks for the list of extensions that you test for in the ShadowMap. However, I have a graphics card that meets those requirements yet still does not render ShadowMap shadows. Can you tell me if any of these extensions look like the 'smoking gun' as to why this card does not display shadows? Here is a list of extensions that ARE NOT supported on this graphics card. This list was extracted from a diff between a working graphics card that does display shadows and the current 'broken' one. I am sure there are more extensions that are not listed here that I am unaware of. GL_ARB_draw_buffers GL_ARB_fragment_shader GL_ARB_multisample GL_ARB_shader_objects GL_ARB_shading_language_100 GL_ARB_transpose_matrix GL_ARB_vertex_buffer_object GL_ARB_vertex_shader GL_ATI_draw_buffers GL_EXT_blend_equation_separate GL_EXT_compiled_vertex_array GL_EXT_Cg_shader GL_EXT_depth_bounds_test GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_gpu_program_parameters GL_EXT_point_parameters GL_EXT_stencil_two_side GL_NV_fence GL_NV_fragment_program GL_NV_framebuffer_multisample_coverage GL_NV_half_float GL_NV_occlusion_query GL_NV_pixel_data_range GL_NV_point_sprite GL_NV_primitive_restart GL_NV_register_combiners GL_NV_register_combiners2 GL_NV_vertex_array_range GL_NV_vertex_array_range2 GL_NV_vertex_program GL_NV_vertex_program1_1 GL_NV_vertex_program2 GL_NVX_conditional_render This is the list of extensions are ARE supported by this 'broken' card that does not display shadows: GL_ARB_color_buffer_float GL_ARB_depth_texture GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_half_float_pixel GL_ARB_imaging GL_ARB_multitexture GL_ARB_occlusion_query GL_ARB_pixel_buffer_object GL_ARB_point_parameters GL_ARB_point_sprite GL_ARB_shadow GL_ARB_texture_border_clamp GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_dot3 GL_ARB_texture_float GL_ARB_texture_mirrored_repeat GL_ARB_texture_non_power_of_two GL_ARB_texture_rectangle GL_ARB_vertex_program GL_ARB_window_pos GL_ATI_texture_float GL_ATI_texture_mirror_once GL_S3_s3tc GL_EXT_texture_env_add GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_func_separate GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_framebuffer_object GL_EXT_multi_draw_arrays GL_EXT_packed_depth_stencil GL_EXT_packed_pixels GL_EXT_pixel_buffer_object GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shadow_funcs GL_EXT_stencil_wrap GL_EXT_texture3D GL_EXT_texture_compression_s3tc GL_EXT_texture_cube_map GL_EXT_texture_edge_clamp GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_texture_mirror_clamp GL_EXT_texture_object GL_EXT_texture_sRGB GL_EXT_timer_query GL_EXT_vertex_array GL_IBM_rasterpos_clip GL_IBM_texture_mirrored_repeat GL_KTX_buffer_region GL_NV_blend_square GL_NV_copy_depth_to_color GL_NV_depth_clamp GL_NV_float_buffer GL_NV_fog_distance GL_NV_fragment_program_option GL_NV_fragment_program2 GL_NV_light_max_exponent GL_NV_multisample_filter_hint GL_NV_packed_depth_stencil GL_NV_texgen_reflection GL_NV_texture_compression_vtc GL_NV_texture_env_combine4 GL_NV_texture_expand_normal GL_NV_texture_rectangle GL_NV_texture_shader GL_NV_texture_shader2 GL_NV_texture_shader3 GL_NV_vertex_program2_option GL_NV_vertex_program3 GL_SGIS_generate_mipmap GL_SGIS_texture_lod GL_SGIX_depth_texture GL_SGIX_shadow GL_SUN_slice_accum Thanks, -Ben -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-Sébastien Guay Sent: Monday, September 22, 2008 8:12 PM To: OpenSceneGraph Users Subject: Re: [osg-users] openGL extensions Hi Ben, > I would like to detect if the user has the appropriate openGL extensions > in order to do shadowing. However, when I do: > > glGetString(GL_VERSION) > glGetString(GL_EXTENSIONS) > > They return null. How can I get a list of the available extensions? Is > there an easy way to get this info from OSG? For the first part of your question, they return NULL if they were called from a thread that does not have a graphics context. The safest way to do this is to create a camera predraw/postdraw/finaldraw callback or a node cull callback or a drawable draw callback. In each of these points you will have a graphics context. What I generally do is assume support is present and start the viewer with a detection callback attached (camera predraw callback on the main camera) which will check extensions and then remove itself from the camera. Then after the first frame, if I see that some feature is not supported, I disable the relevant options. There are other valid strategies of course. As for detecting actual extensions, instead of calling glGetString(GL_EXTENSIONS) and parsing it yourself, you can use #include #include osg::isGLExtensionSupported(contextID, extensionNam
Re: [osg-users] openGL extensions
Thank you Jean and Gordon. I put those functions in my draw callback and now I get some information. However, the behavior is very strange. It only works the first time through. The rest of the time, they return null. Even weirder is that if I click on another window, they work again for one iteration, then go back to being null. Every time I click off and on again of my OSG application, the info appears. Why is this? FYI: OSG 2.6.0 on Debian Etch with an NVidia 7300 card. Thanks, -Ben -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-Sébastien Guay Sent: Monday, September 22, 2008 8:12 PM To: OpenSceneGraph Users Subject: Re: [osg-users] openGL extensions Hi Ben, > I would like to detect if the user has the appropriate openGL extensions > in order to do shadowing. However, when I do: > > glGetString(GL_VERSION) > glGetString(GL_EXTENSIONS) > > They return null. How can I get a list of the available extensions? Is > there an easy way to get this info from OSG? For the first part of your question, they return NULL if they were called from a thread that does not have a graphics context. The safest way to do this is to create a camera predraw/postdraw/finaldraw callback or a node cull callback or a drawable draw callback. In each of these points you will have a graphics context. What I generally do is assume support is present and start the viewer with a detection callback attached (camera predraw callback on the main camera) which will check extensions and then remove itself from the camera. Then after the first frame, if I see that some feature is not supported, I disable the relevant options. There are other valid strategies of course. As for detecting actual extensions, instead of calling glGetString(GL_EXTENSIONS) and parsing it yourself, you can use #include #include osg::isGLExtensionSupported(contextID, extensionName) > Also, how do I know which extensions I need for the different shadow > techniques? I'm personally not sure which extensions are required for all of them, perhaps someone else will know (it might be good to add that info to the osgShadow page on the wiki). I can tell you what I test for in the case of osgShadow::ShadowMap: _shadowsSupported = osg::isGLExtensionSupported(contextID, "GL_EXT_framebuffer_object") && (osg::isGLExtensionSupported(contextID, "GL_ARB_fragment_program") || osg::isGLExtensionSupported(contextID, "GL_EXT_fragment_program")) && (osg::isGLExtensionSupported(contextID, "GL_ARB_fragment_program_shadow") || osg::isGLExtensionSupported(contextID, "GL_EXT_fragment_program_shadow")); Not sure if that's totally correct, but in most cases where shadow maps were not supported (they fell back to software and so were extremely slow) it was the first (GL_EXT_framebuffer_object) which was not supported. Hope this helps, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ 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] loading vrml segfault
This page indicates that OpenInventor only supports VRML 1.0 files. (http://www.openscenegraph.org/projects/osg/wiki/Support/UserGuides/Plugins) And from my own experience, OpenVRML only supports VRML 2.0 files. Can OSG handle both of these libraries at the same time? I am a little doubtful since the VRML file must be parsed before it can be determined if it is VRML 1.0 or VRML 2.0. And OpenVRML segfaults when trying to load a VRML 1.0 file. Does anyone have any experience supporting both VRML 1.0 and VRML 2.0 file types? Thanks, -Ben -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Huebert Sent: Thursday, September 18, 2008 6:20 PM To: OpenSceneGraph Users Subject: Re: [osg-users] loading vrml segfault Hi Ben, I tried your wrl files using osg with the coin3d plugin (alternate for some of what openvrml does) and got predictable results, given your post. When bombing on the Bad.wrl file, coin kindly provided the following: % osgviewer Bad.wrl Coin read error: Unknown field "mesh" in "VRMLShape" Occurred at line 5 in Bad.wrl osgviewer: No data loaded Maybe this will help? -bob On Thu, 18 Sep 2008, Ben Axelrod wrote: > When I try to load a VRML 1.0 file in OpenSceneGraph, it segfaults. I am > using OpenSceneGraph 2.6, and OpenVRML 0.14.3. I have attached the file that > causes the segfault, as well as the same file with some minor changes to make > it run properly. > > The segfault happens inside: osgDB::readNodeFile(filename). It would be > great if OSG could detect the error, and return properly with an invalid > node. But I understand if the fault is inside of OpenVRML. > > Thanks, > -Ben > ___ 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
[osg-users] openGL extensions
I would like to detect if the user has the appropriate openGL extensions in order to do shadowing. However, when I do: glGetString(GL_VERSION) glGetString(GL_EXTENSIONS) They return null. How can I get a list of the available extensions? Is there an easy way to get this info from OSG? Also, how do I know which extensions I need for the different shadow techniques? Thanks, -Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] strange ShadowMap behavior
I am seeing strange shadow artifacts on my model when I use a ShadowMap. The artifacts get worse as I increase the size of my ground plane. You can see the artifacts get progressively worse in these images: http://www.benaxelrod.com/temp/3x3.png http://www.benaxelrod.com/temp/5x5.png http://www.benaxelrod.com/temp/7x7.png http://www.benaxelrod.com/temp/10x10.png <- this is the desired size of ground plane http://www.benaxelrod.com/temp/12x12.png You can see strange gradients on the humanoid's hands and feet. And the shadow gets more and more pixilated. I am using OSG 2.6 on Debian Etch with a NVidia 7300 LE graphics card. This is how I configure the ShadowMap: shadowmap->setTextureSize(osg::Vec2s(1024, 1024)); shadowmap->setPolygonOffset(osg::Vec2(1.1f, 4.0f)); Do I need to tune these parameters? If so, how? Are there more parameters I need? And what do these parameters control exactly? Thanks, -Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] loading vrml segfault
When I try to load a VRML 1.0 file in OpenSceneGraph, it segfaults. I am using OpenSceneGraph 2.6, and OpenVRML 0.14.3. I have attached the file that causes the segfault, as well as the same file with some minor changes to make it run properly. The segfault happens inside: osgDB::readNodeFile(filename). It would be great if OSG could detect the error, and return properly with an invalid node. But I understand if the fault is inside of OpenVRML. Thanks, -Ben vrmltest.tar.bz2 Description: vrmltest.tar.bz2 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] vrml plugin problems
Thank you for the tip. That environment variable flag helped me see that OSG found the osgdb_vrml.so plugin, but then failed when loading the openvrml.so library. I added that dir to my LD_LIBRARY_PATH and all is well! (I don't seem to have the osgdb_wrl.so plugin by the way, but it does not look like I need it). Thanks, -Ben -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-Sébastien Guay Sent: Wednesday, September 17, 2008 4:34 PM To: OpenSceneGraph Users Subject: Re: [osg-users] vrml plugin problems Hi Ben, > I am trying to load a VRML file, but I get the error message: > > Warning: Could not find plugin to read objects from file "foo.wrl". [...] > I compiled OSG 2.6.0 from src on Debian Etch. I am using OpenVRML > version 0.14.3. Do I need a newer version of OpenVRML? (I set the path > to the OpenVRML includes as well as libopenvrml.so during the CMake > configuration). Did you verify that the osgdb_wrl.so plugin was compiled and can be found? You can enable verbose debugging messages by setting OSG_NOTIFY_LEVEL=DEBUG before running osgviewer, and that might show if something is wrong there. It will print out where it looks for the plugin, whether it finds it, and whether it loads it correctly or not. If the plugin is there, is loaded (as printed in the debug messages) but it still says that it can't find a plugin, it might mean that the plugin depends on some other dynamic library which isn't being found at runtime. This might depend on where OpenVRML is installed and whether your LD_LIBRARY_PATH includes the right directory to find its dynamic libraries (if any) - note I'm on Windows most of the time so I can't really help more than that. > I had VRML files working with OSG 2.4 a long time ago. Back then I also > set up the Inventor library during the install. But I forgot what that > library does, why it's needed, and even where to get it. Do I need it > here too? The Inventor plugin can also read VRML files, so if OSG was using that one to read your VRML files before, it might mean that the OpenVRML plugin never worked for you but you never knew it... :-) Hope this helps, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ 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
[osg-users] vrml plugin problems
I am trying to load a VRML file, but I get the error message: Warning: Could not find plugin to read objects from file "foo.wrl". I tried this in OSG code, as well as with osgconv and osgviewer. I have the OSG lib and osgPlugins directories in my LD_LIBRARY_PATH. I compiled OSG 2.6.0 from src on Debian Etch. I am using OpenVRML version 0.14.3. Do I need a newer version of OpenVRML? (I set the path to the OpenVRML includes as well as libopenvrml.so during the CMake configuration). I had VRML files working with OSG 2.4 a long time ago. Back then I also set up the Inventor library during the install. But I forgot what that library does, why it's needed, and even where to get it. Do I need it here too? Thanks, -Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] TriangleMesh color
Hi, I am trying to use a triangle mesh. And for some reason, it always shows up black. Here is a snipit of code: osg::ref_ptr _geode; _geode = new osg::Geode(); osg::ref_ptr _trimesh; _trimesh = new osg::TriangleMesh(); osg::ref_ptr _SD; _SD = new osg::ShapeDrawable(_trimesh.get()); _SD->setColor(osg::Vec4f(1.0f, 1.0f, 1.0f, 1.0f)); _geode->addDrawable(_SD.get()); osg::Vec3Array* vecs = new osg::Vec3Array(); vecs->push_back(osg::Vec3d(0, 0, 0)); vecs->push_back(osg::Vec3d(1, 0, 0)); vecs->push_back(osg::Vec3d(0, 0, 1)); _trimesh->setVertices(vecs); osg::TemplateIndexArray* ind = new osg::TemplateIndexArray(); ind->push_back(0); ind->push_back(1); ind->push_back(2); _trimesh->setIndices(ind); As you can see, the TriangleMesh is a child of a ShapeDrawable node, which should set its color to white. This technique has worked great for the other shape primitives. Is there another way to set the color for a TriangleMesh? Or is there another way I should construct my tree? Or is it a bug? Thanks, -Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] VRML Normals
I noticed that OSG 2.2 does not properly calculate the normals of VRML files. It seems like it points all the normals at (0, -1, 0). This is only when the normals are not explicitly specified in the file. If you open a VRML file like this in osgviewer, you can see that the coloration of the mesh is only accurate when looking at the top of the object. If the normals are specified in the VRML file, then the mesh coloration looks correct in osgviewer. I can supply an example VRML files that demonstrate this bug, and also how to fix it. Has this bug been fixed in version 2.4? Thanks, -Ben ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
