[osg-users] particle system FIX
The problem with the system of particles:
in hiding the particle system and their subsequent screening creates a huge
number of particles (splash). But more than the big time difference between
concealment and display. The drawings depicted such a situation.
http://i35.tinypic.com/ridkhu.jpg
http://i33.tinypic.com/2nulhfd.jpg
The first figure shows the correct image, the second figure shows the
erroneous operation of the system of particles.
In addition, when a large number of particles occurs following warning:
Warning: State:: drawQuads (0, 72588) too large handle in remapping to
ushort glDrawElements.
Warning: State:: drawQuads (0, 72592) too large handle in remapping to
ushort glDrawElements.
Warning: State:: drawQuads (0, 72592) too large handle in remapping to
ushort glDrawElements.
Warning: State:: drawQuads (0, 72596) too large handle in remapping to
ushort glDrawElements.
fix this problem :
inline int RandomRateCounter::numParticlesToCreate(double dt) const
{
_np += dt * getRateRange().get_random();
int n = static_castint(_np);
_np -= n;
*if (n getRateRange().maximum) *
* **{*
* **n = getRateRange().get_random(); //or .get_random *
* **_np=0;*
* **}*
return n;
}
in attached file
--
Maxim Gammer
RandomRateCounter
Description: Binary data
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Issue with normal vectors
Thank you Paul for your response. Yes, you are right, the solution isn't perfect at all. But I'm integrating some external code which is just giving me a vertex array and a per triangle callback with vertex indexes and normal and texture coords. And further more I need some screenshots very urgently for a customer presentation. The performance improvement has to wait :-( So I try to analyse why it's not working. And I detected something I don't understand. In my opinion it should give the same result having: 1) one normal per triangle an binding PER_PRIMITIVE 2) 3 times the same normal and binding PER_PRIMITIVE_SET But it doesn't. So I'm confused. Thanks for further hints. - Werner - Am Mittwoch, 25. August 2010 22:41:14 schrieb Paul Martz: Werner Modenbach wrote: Maybe someone can give me some explanation on my stupid little problem. I have a geometry being composed of TRIANGLES. I have a vertex-array, a verted-index-array and a normal-array assigned to my geometry. Off-topic: Do you need to use the vertex-index-array? It is deprecated: /** deprecated - forces OpenGL slow path, just kept for backwards compatibility.*/ void setVertexIndices(IndexArray* array); 3 indexes and 3 normals per Triangle. Normal binding is set to BIND_PER_PRIMITIVE_SET. Unfortunately the rendering shows the geometry flat in curious dark colors and some unexpected light behaviour. For analysis purpose I set the normal binding to BIND_PER_PRIMITIVE and pushed just 1 normal per TRIANGLE. Everything looks good except I see the triangles and the geometry isn't smooth. The next test is pushing the same normal vector 3 times and setting the binding back to BIND_PER_PRIMITIVE_SET. In my understanding this should give the same optical result as before. Unfortunately it doesn't and everything is dark again. I guess, I misunderstand something with the normal bindings. Any hint is highly appreciated. Thanks in advance I'm not sure why you don't use BIND_PER_VERTEX, as you stated above that your normal array contains 3 normals per triangle, so you have one normal per vertex, right? BIND_PER_PRIMITIVE would result in flat shading (only one normal used for each triangle -- which, by the way, also forces OpenGL down the slow path), and BIND_PER_PRIMITIVE_SET would be even more granular: one normal used for each PrimitiveSet you add to the Geometry. This would make all triangles in the PrimitiveSet either uniformly dark or uniformly lit, depending on the direction of the one normal used for the whole group. For analysis purposes, I suggest using the normals pseudoloader: osgviewer dumptruck.osg.normals Hope that helps, -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- TEXION Software Solutions TEXION GmbH - Rotter Bruch 26a - D 52068 Aachen - HRB 14999 Aachen Fon: +49 241 475757-0, Fax: +49 241 475757-29, web: http://www.texion.eu Geschäftsführer/Managing Director: Werner Modenbach ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Issue with normal vectors
Hi Werner, BIND_PER_PRIMITIVE_SET will mean that you'll have one of the associated attribute (i.e. colour, normal) per osg::PrimitiveSet attached the osg::Geometry, so if you have one osg::DrawElementsUShort used for the triangles then you'll need just one of the associated attribute for it. BIND_PER_PRIMITIVE will apply the attribute per primitive in you case per triangle. Tex coords in the OSG are always bound per vertex, there isn't a control to alter this. If you have a vertex array and indices for your triangles the natural thing to do would be to use a osg::DrawElementsUShort(GL_TRIANGLES) then use push_back(tri.p1) for each index on each triangle. I would suggest binding the normals per vertex, you'll have to do this for the tex coords as well. If a single vertex will have multiple tex coords or multiple normals associated with it due to differences in the triangles then you'll need to duplicate the vertices and remap the indices on the triangles to fit this. Robert. On Thu, Aug 26, 2010 at 10:38 AM, Werner Modenbach werner.modenb...@texion.eu wrote: Thank you Paul for your response. Yes, you are right, the solution isn't perfect at all. But I'm integrating some external code which is just giving me a vertex array and a per triangle callback with vertex indexes and normal and texture coords. And further more I need some screenshots very urgently for a customer presentation. The performance improvement has to wait :-( So I try to analyse why it's not working. And I detected something I don't understand. In my opinion it should give the same result having: 1) one normal per triangle an binding PER_PRIMITIVE 2) 3 times the same normal and binding PER_PRIMITIVE_SET But it doesn't. So I'm confused. Thanks for further hints. - Werner - Am Mittwoch, 25. August 2010 22:41:14 schrieb Paul Martz: Werner Modenbach wrote: Maybe someone can give me some explanation on my stupid little problem. I have a geometry being composed of TRIANGLES. I have a vertex-array, a verted-index-array and a normal-array assigned to my geometry. Off-topic: Do you need to use the vertex-index-array? It is deprecated: /** deprecated - forces OpenGL slow path, just kept for backwards compatibility.*/ void setVertexIndices(IndexArray* array); 3 indexes and 3 normals per Triangle. Normal binding is set to BIND_PER_PRIMITIVE_SET. Unfortunately the rendering shows the geometry flat in curious dark colors and some unexpected light behaviour. For analysis purpose I set the normal binding to BIND_PER_PRIMITIVE and pushed just 1 normal per TRIANGLE. Everything looks good except I see the triangles and the geometry isn't smooth. The next test is pushing the same normal vector 3 times and setting the binding back to BIND_PER_PRIMITIVE_SET. In my understanding this should give the same optical result as before. Unfortunately it doesn't and everything is dark again. I guess, I misunderstand something with the normal bindings. Any hint is highly appreciated. Thanks in advance I'm not sure why you don't use BIND_PER_VERTEX, as you stated above that your normal array contains 3 normals per triangle, so you have one normal per vertex, right? BIND_PER_PRIMITIVE would result in flat shading (only one normal used for each triangle -- which, by the way, also forces OpenGL down the slow path), and BIND_PER_PRIMITIVE_SET would be even more granular: one normal used for each PrimitiveSet you add to the Geometry. This would make all triangles in the PrimitiveSet either uniformly dark or uniformly lit, depending on the direction of the one normal used for the whole group. For analysis purposes, I suggest using the normals pseudoloader: osgviewer dumptruck.osg.normals Hope that helps, -Paul ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- TEXION Software Solutions TEXION GmbH - Rotter Bruch 26a - D 52068 Aachen - HRB 14999 Aachen Fon: +49 241 475757-0, Fax: +49 241 475757-29, web: http://www.texion.eu Geschäftsführer/Managing Director: Werner Modenbach ___ 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] Can we used OSG for ES 2.0 project on linux??
Hi bouffa, Now its compiling .Thanks a lot. Regards, RK -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31065#31065 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Issue with normal vectors
Thanks Robert, I get closer to it. Just for verification: If I have i.e. 10 vertexes and I get 20 calls to the callback method each defining a triangle. Each call gives me 3 indexes, 3 normals and 3 texcoords. Right now I just push everything into the corresponding arrays and at the end I call: geometry-addPrimitiveSet(new osg::DrawArrays(osg::PrimitiveSet::TRIANGLES, 0, osgVertexIndices-size())); You say this will not work because: 1) geometry-setNormalBinding(osg::Geometry::BIND_PER_PRIMITIVE_SET); expects just 1 normal for the whole thing (?) 2) Texture coordinates are allways bound per vertex? In this case I have to: 1) initialize a normal array with Vec3(0.0, 0.0, 0.0) for each triangle callback I have to look on each vertex index , if the indexes normal is 0 if yes: just set it if no: duplicate the vertex at the end of the vertexes and push_back the normal 2) do something comparable on the texcoords Is that your recommendation? Is there any way to bind normals to the vertex indexes? Thanks in advance! - Werner - Am Donnerstag, 26. August 2010 12:06:34 schrieb Robert Osfield: Hi Werner, BIND_PER_PRIMITIVE_SET will mean that you'll have one of the associated attribute (i.e. colour, normal) per osg::PrimitiveSet attached the osg::Geometry, so if you have one osg::DrawElementsUShort used for the triangles then you'll need just one of the associated attribute for it. BIND_PER_PRIMITIVE will apply the attribute per primitive in you case per triangle. Tex coords in the OSG are always bound per vertex, there isn't a control to alter this. If you have a vertex array and indices for your triangles the natural thing to do would be to use a osg::DrawElementsUShort(GL_TRIANGLES) then use push_back(tri.p1) for each index on each triangle. I would suggest binding the normals per vertex, you'll have to do this for the tex coords as well. If a single vertex will have multiple tex coords or multiple normals associated with it due to differences in the triangles then you'll need to duplicate the vertices and remap the indices on the triangles to fit this. Robert. On Thu, Aug 26, 2010 at 10:38 AM, Werner Modenbach werner.modenb...@texion.eu wrote: Thank you Paul for your response. Yes, you are right, the solution isn't perfect at all. But I'm integrating some external code which is just giving me a vertex array and a per triangle callback with vertex indexes and normal and texture coords. And further more I need some screenshots very urgently for a customer presentation. The performance improvement has to wait :-( So I try to analyse why it's not working. And I detected something I don't understand. In my opinion it should give the same result having: 1) one normal per triangle an binding PER_PRIMITIVE 2) 3 times the same normal and binding PER_PRIMITIVE_SET But it doesn't. So I'm confused. Thanks for further hints. - Werner - Am Mittwoch, 25. August 2010 22:41:14 schrieb Paul Martz: Werner Modenbach wrote: Maybe someone can give me some explanation on my stupid little problem. I have a geometry being composed of TRIANGLES. I have a vertex-array, a verted-index-array and a normal-array assigned to my geometry. Off-topic: Do you need to use the vertex-index-array? It is deprecated: /** deprecated - forces OpenGL slow path, just kept for backwards compatibility.*/ void setVertexIndices(IndexArray* array); 3 indexes and 3 normals per Triangle. Normal binding is set to BIND_PER_PRIMITIVE_SET. Unfortunately the rendering shows the geometry flat in curious dark colors and some unexpected light behaviour. For analysis purpose I set the normal binding to BIND_PER_PRIMITIVE and pushed just 1 normal per TRIANGLE. Everything looks good except I see the triangles and the geometry isn't smooth. The next test is pushing the same normal vector 3 times and setting the binding back to BIND_PER_PRIMITIVE_SET. In my understanding this should give the same optical result as before. Unfortunately it doesn't and everything is dark again. I guess, I misunderstand something with the normal bindings. Any hint is highly appreciated. Thanks in advance I'm not sure why you don't use BIND_PER_VERTEX, as you stated above that your normal array contains 3 normals per triangle, so you have one normal per vertex, right? BIND_PER_PRIMITIVE would result in flat shading (only one normal used for each triangle -- which, by the way, also forces OpenGL down the slow path), and BIND_PER_PRIMITIVE_SET would be even more granular: one normal used for each PrimitiveSet you add to the Geometry. This would make all triangles in the PrimitiveSet either uniformly dark or uniformly lit, depending on the direction of the one normal used for the whole group. For
Re: [osg-users] Issue with normal vectors
Just try this and see how it works: geometry-setNormalBinding(osg::Geometry::BIND_PER_VERTEX); Brian This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. -osg-users-boun...@lists.openscenegraph.org wrote: - To: OpenSceneGraph Users osg-users@lists.openscenegraph.org From: Werner Modenbach werner.modenb...@texion.eu Sent by: osg-users-boun...@lists.openscenegraph.org Date: 08/26/2010 07:08AM Subject: Re: [osg-users] Issue with normal vectors Thanks Robert, I get closer to it. Just for verification: If I have i.e. 10 vertexes and I get 20 calls to the callback method each defining a triangle. Each call gives me 3 indexes, 3 normals and 3 texcoords. Right now I just push everything into the corresponding arrays and at the end I call: geometry-addPrimitiveSet(new osg::DrawArrays(osg::PrimitiveSet::TRIANGLES, 0, osgVertexIndices-size())); You say this will not work because: 1) geometry-setNormalBinding(osg::Geometry::BIND_PER_PRIMITIVE_SET); expects just 1 normal for the whole thing (?) 2) Texture coordinates are allways bound per vertex? In this case I have to: 1) initialize a normal array with Vec3(0.0, 0.0, 0.0) for each triangle callback I have to look on each vertex index , if the indexes normal is 0 if yes: just set it if no: duplicate the vertex at the end of the vertexes and push_back the normal 2) do something comparable on the texcoords Is that your recommendation? Is there any way to bind normals to the vertex indexes? Thanks in advance! - Werner - Am Donnerstag, 26. August 2010 12:06:34 schrieb Robert Osfield: Hi Werner, BIND_PER_PRIMITIVE_SET will mean that you'll have one of the associated attribute (i.e. colour, normal) per osg::PrimitiveSet attached the osg::Geometry, so if you have one osg::DrawElementsUShort used for the triangles then you'll need just one of the associated attribute for it. BIND_PER_PRIMITIVE will apply the attribute per primitive in you case per triangle. Tex coords in the OSG are always bound per vertex, there isn't a control to alter this. If you have a vertex array and indices for your triangles the natural thing to do would be to use a osg::DrawElementsUShort(GL_TRIANGLES) then use push_back(tri.p1) for each index on each triangle. I would suggest binding the normals per vertex, you'll have to do this for the tex coords as well. If a single vertex will have multiple tex coords or multiple normals associated with it due to differences in the triangles then you'll need to duplicate the vertices and remap the indices on the triangles to fit this. Robert. On Thu, Aug 26, 2010 at 10:38 AM, Werner Modenbach werner.modenb...@texion.eu wrote: Thank you Paul for your response. Yes, you are right, the solution isn't perfect at all. But I'm integrating some external code which is just giving me a vertex array and a per triangle callback with vertex indexes and normal and texture coords. And further more I need some screenshots very urgently for a customer presentation. The performance improvement has to wait :-( So I try to analyse why it's not working. And I detected something I don't understand. In my opinion it should give the same result having: 1) one normal per triangle an binding PER_PRIMITIVE 2) 3 times the same normal and binding PER_PRIMITIVE_SET But it doesn't. So I'm confused. Thanks for further hints. - Werner - Am Mittwoch, 25. August 2010 22:41:14 schrieb Paul Martz: Werner Modenbach wrote: Maybe someone can give me some explanation on my stupid little problem. I have a geometry being composed of TRIANGLES. I have a vertex-array, a verted-index-array and a normal-array assigned to my geometry. Off-topic: Do you need to use the vertex-index-array? It is deprecated: /** deprecated - forces OpenGL slow path, just kept for backwards compatibility.*/ void setVertexIndices(IndexArray* array); 3 indexes and 3 normals per Triangle. Normal binding is set to BIND_PER_PRIMITIVE_SET. Unfortunately the rendering shows the geometry flat in curious dark colors and some unexpected light behaviour. For analysis purpose I set the normal binding to BIND_PER_PRIMITIVE and pushed just 1 normal per TRIANGLE. Everything looks good except I see the triangles and the geometry isn't smooth. The next test is pushing the same normal vector 3 times and setting the binding back to BIND_PER_PRIMITIVE_SET. In my understanding this should give the same optical result as before. Unfortunately it doesn't
Re: [osg-users] Issue with normal vectors
Hi Werner, Possible the most simple and quickest way for you to set things up is to simple create a new vertex, normal and tex coords for every triangle corner, then use osg::DrawArrays(GL_TRIANGLES, total_no_of_new_vertices) for the PrimitiveSet, and BIND_PER_VERTEX for the binding of the normals. Note, you'll need to create a new Vec3Array for the vertices form the index and orignal vertex data. This won't be the most efficient route as it's likely to result in duplicate vertices but at least it should be very straight forward. You can make things more efficient later. Robert. On Thu, Aug 26, 2010 at 12:08 PM, Werner Modenbach werner.modenb...@texion.eu wrote: Thanks Robert, I get closer to it. Just for verification: If I have i.e. 10 vertexes and I get 20 calls to the callback method each defining a triangle. Each call gives me 3 indexes, 3 normals and 3 texcoords. Right now I just push everything into the corresponding arrays and at the end I call: geometry-addPrimitiveSet(new osg::DrawArrays(osg::PrimitiveSet::TRIANGLES, 0, osgVertexIndices-size())); You say this will not work because: 1) geometry-setNormalBinding(osg::Geometry::BIND_PER_PRIMITIVE_SET); expects just 1 normal for the whole thing (?) 2) Texture coordinates are allways bound per vertex? In this case I have to: 1) initialize a normal array with Vec3(0.0, 0.0, 0.0) for each triangle callback I have to look on each vertex index , if the indexes normal is 0 if yes: just set it if no: duplicate the vertex at the end of the vertexes and push_back the normal 2) do something comparable on the texcoords Is that your recommendation? Is there any way to bind normals to the vertex indexes? Thanks in advance! - Werner - Am Donnerstag, 26. August 2010 12:06:34 schrieb Robert Osfield: Hi Werner, BIND_PER_PRIMITIVE_SET will mean that you'll have one of the associated attribute (i.e. colour, normal) per osg::PrimitiveSet attached the osg::Geometry, so if you have one osg::DrawElementsUShort used for the triangles then you'll need just one of the associated attribute for it. BIND_PER_PRIMITIVE will apply the attribute per primitive in you case per triangle. Tex coords in the OSG are always bound per vertex, there isn't a control to alter this. If you have a vertex array and indices for your triangles the natural thing to do would be to use a osg::DrawElementsUShort(GL_TRIANGLES) then use push_back(tri.p1) for each index on each triangle. I would suggest binding the normals per vertex, you'll have to do this for the tex coords as well. If a single vertex will have multiple tex coords or multiple normals associated with it due to differences in the triangles then you'll need to duplicate the vertices and remap the indices on the triangles to fit this. Robert. On Thu, Aug 26, 2010 at 10:38 AM, Werner Modenbach werner.modenb...@texion.eu wrote: Thank you Paul for your response. Yes, you are right, the solution isn't perfect at all. But I'm integrating some external code which is just giving me a vertex array and a per triangle callback with vertex indexes and normal and texture coords. And further more I need some screenshots very urgently for a customer presentation. The performance improvement has to wait :-( So I try to analyse why it's not working. And I detected something I don't understand. In my opinion it should give the same result having: 1) one normal per triangle an binding PER_PRIMITIVE 2) 3 times the same normal and binding PER_PRIMITIVE_SET But it doesn't. So I'm confused. Thanks for further hints. - Werner - Am Mittwoch, 25. August 2010 22:41:14 schrieb Paul Martz: Werner Modenbach wrote: Maybe someone can give me some explanation on my stupid little problem. I have a geometry being composed of TRIANGLES. I have a vertex-array, a verted-index-array and a normal-array assigned to my geometry. Off-topic: Do you need to use the vertex-index-array? It is deprecated: /** deprecated - forces OpenGL slow path, just kept for backwards compatibility.*/ void setVertexIndices(IndexArray* array); 3 indexes and 3 normals per Triangle. Normal binding is set to BIND_PER_PRIMITIVE_SET. Unfortunately the rendering shows the geometry flat in curious dark colors and some unexpected light behaviour. For analysis purpose I set the normal binding to BIND_PER_PRIMITIVE and pushed just 1 normal per TRIANGLE. Everything looks good except I see the triangles and the geometry isn't smooth. The next test is pushing the same normal vector 3 times and setting the binding back to BIND_PER_PRIMITIVE_SET. In my understanding this should give the same optical result as before. Unfortunately it doesn't and everything is dark again. I guess, I misunderstand something with the normal bindings. Any hint is highly
Re: [osg-users] Issue with normal vectors
Thanks Robert, I'll follow this way. You are right, this is the way to get the quickest results. - Werner - Am Donnerstag, 26. August 2010 14:19:48 schrieb Robert Osfield: Hi Werner, Possible the most simple and quickest way for you to set things up is to simple create a new vertex, normal and tex coords for every triangle corner, then use osg::DrawArrays(GL_TRIANGLES, total_no_of_new_vertices) for the PrimitiveSet, and BIND_PER_VERTEX for the binding of the normals. Note, you'll need to create a new Vec3Array for the vertices form the index and orignal vertex data. This won't be the most efficient route as it's likely to result in duplicate vertices but at least it should be very straight forward. You can make things more efficient later. Robert. On Thu, Aug 26, 2010 at 12:08 PM, Werner Modenbach werner.modenb...@texion.eu wrote: Thanks Robert, I get closer to it. Just for verification: If I have i.e. 10 vertexes and I get 20 calls to the callback method each defining a triangle. Each call gives me 3 indexes, 3 normals and 3 texcoords. Right now I just push everything into the corresponding arrays and at the end I call: geometry-addPrimitiveSet(new osg::DrawArrays(osg::PrimitiveSet::TRIANGLES, 0, osgVertexIndices-size())); You say this will not work because: 1) geometry-setNormalBinding(osg::Geometry::BIND_PER_PRIMITIVE_SET); expects just 1 normal for the whole thing (?) 2) Texture coordinates are allways bound per vertex? In this case I have to: 1) initialize a normal array with Vec3(0.0, 0.0, 0.0) for each triangle callback I have to look on each vertex index , if the indexes normal is 0 if yes: just set it if no: duplicate the vertex at the end of the vertexes and push_back the normal 2) do something comparable on the texcoords Is that your recommendation? Is there any way to bind normals to the vertex indexes? Thanks in advance! - Werner - Am Donnerstag, 26. August 2010 12:06:34 schrieb Robert Osfield: Hi Werner, BIND_PER_PRIMITIVE_SET will mean that you'll have one of the associated attribute (i.e. colour, normal) per osg::PrimitiveSet attached the osg::Geometry, so if you have one osg::DrawElementsUShort used for the triangles then you'll need just one of the associated attribute for it. BIND_PER_PRIMITIVE will apply the attribute per primitive in you case per triangle. Tex coords in the OSG are always bound per vertex, there isn't a control to alter this. If you have a vertex array and indices for your triangles the natural thing to do would be to use a osg::DrawElementsUShort(GL_TRIANGLES) then use push_back(tri.p1) for each index on each triangle. I would suggest binding the normals per vertex, you'll have to do this for the tex coords as well. If a single vertex will have multiple tex coords or multiple normals associated with it due to differences in the triangles then you'll need to duplicate the vertices and remap the indices on the triangles to fit this. Robert. On Thu, Aug 26, 2010 at 10:38 AM, Werner Modenbach werner.modenb...@texion.eu wrote: Thank you Paul for your response. Yes, you are right, the solution isn't perfect at all. But I'm integrating some external code which is just giving me a vertex array and a per triangle callback with vertex indexes and normal and texture coords. And further more I need some screenshots very urgently for a customer presentation. The performance improvement has to wait :-( So I try to analyse why it's not working. And I detected something I don't understand. In my opinion it should give the same result having: 1) one normal per triangle an binding PER_PRIMITIVE 2) 3 times the same normal and binding PER_PRIMITIVE_SET But it doesn't. So I'm confused. Thanks for further hints. - Werner - Am Mittwoch, 25. August 2010 22:41:14 schrieb Paul Martz: Werner Modenbach wrote: Maybe someone can give me some explanation on my stupid little problem. I have a geometry being composed of TRIANGLES. I have a vertex-array, a verted-index-array and a normal-array assigned to my geometry. Off-topic: Do you need to use the vertex-index-array? It is deprecated: /** deprecated - forces OpenGL slow path, just kept for backwards compatibility.*/ void setVertexIndices(IndexArray* array); 3 indexes and 3 normals per Triangle. Normal binding is set to BIND_PER_PRIMITIVE_SET. Unfortunately the rendering shows the geometry flat in curious dark colors and some unexpected light behaviour. For analysis purpose I set the normal binding to BIND_PER_PRIMITIVE and pushed just 1 normal per TRIANGLE. Everything looks good except I see the triangles and the geometry isn't smooth. The next test is pushing the
Re: [osg-users] Issue with normal vectors
Thanks, works great for the quick solution :-) Am Donnerstag, 26. August 2010 14:32:19 schrieb Werner Modenbach: Thanks Robert, I'll follow this way. You are right, this is the way to get the quickest results. - Werner - Am Donnerstag, 26. August 2010 14:19:48 schrieb Robert Osfield: Hi Werner, Possible the most simple and quickest way for you to set things up is to simple create a new vertex, normal and tex coords for every triangle corner, then use osg::DrawArrays(GL_TRIANGLES, total_no_of_new_vertices) for the PrimitiveSet, and BIND_PER_VERTEX for the binding of the normals. Note, you'll need to create a new Vec3Array for the vertices form the index and orignal vertex data. This won't be the most efficient route as it's likely to result in duplicate vertices but at least it should be very straight forward. You can make things more efficient later. Robert. On Thu, Aug 26, 2010 at 12:08 PM, Werner Modenbach werner.modenb...@texion.eu wrote: Thanks Robert, I get closer to it. Just for verification: If I have i.e. 10 vertexes and I get 20 calls to the callback method each defining a triangle. Each call gives me 3 indexes, 3 normals and 3 texcoords. Right now I just push everything into the corresponding arrays and at the end I call: geometry-addPrimitiveSet(new osg::DrawArrays(osg::PrimitiveSet::TRIANGLES, 0, osgVertexIndices-size())); You say this will not work because: 1) geometry-setNormalBinding(osg::Geometry::BIND_PER_PRIMITIVE_SET); expects just 1 normal for the whole thing (?) 2) Texture coordinates are allways bound per vertex? In this case I have to: 1) initialize a normal array with Vec3(0.0, 0.0, 0.0) for each triangle callback I have to look on each vertex index , if the indexes normal is 0 if yes: just set it if no: duplicate the vertex at the end of the vertexes and push_back the normal 2) do something comparable on the texcoords Is that your recommendation? Is there any way to bind normals to the vertex indexes? Thanks in advance! - Werner - Am Donnerstag, 26. August 2010 12:06:34 schrieb Robert Osfield: Hi Werner, BIND_PER_PRIMITIVE_SET will mean that you'll have one of the associated attribute (i.e. colour, normal) per osg::PrimitiveSet attached the osg::Geometry, so if you have one osg::DrawElementsUShort used for the triangles then you'll need just one of the associated attribute for it. BIND_PER_PRIMITIVE will apply the attribute per primitive in you case per triangle. Tex coords in the OSG are always bound per vertex, there isn't a control to alter this. If you have a vertex array and indices for your triangles the natural thing to do would be to use a osg::DrawElementsUShort(GL_TRIANGLES) then use push_back(tri.p1) for each index on each triangle. I would suggest binding the normals per vertex, you'll have to do this for the tex coords as well. If a single vertex will have multiple tex coords or multiple normals associated with it due to differences in the triangles then you'll need to duplicate the vertices and remap the indices on the triangles to fit this. Robert. On Thu, Aug 26, 2010 at 10:38 AM, Werner Modenbach werner.modenb...@texion.eu wrote: Thank you Paul for your response. Yes, you are right, the solution isn't perfect at all. But I'm integrating some external code which is just giving me a vertex array and a per triangle callback with vertex indexes and normal and texture coords. And further more I need some screenshots very urgently for a customer presentation. The performance improvement has to wait :-( So I try to analyse why it's not working. And I detected something I don't understand. In my opinion it should give the same result having: 1) one normal per triangle an binding PER_PRIMITIVE 2) 3 times the same normal and binding PER_PRIMITIVE_SET But it doesn't. So I'm confused. Thanks for further hints. - Werner - Am Mittwoch, 25. August 2010 22:41:14 schrieb Paul Martz: Werner Modenbach wrote: Maybe someone can give me some explanation on my stupid little problem. I have a geometry being composed of TRIANGLES. I have a vertex-array, a verted-index-array and a normal-array assigned to my geometry. Off-topic: Do you need to use the vertex-index-array? It is deprecated: /** deprecated - forces OpenGL slow path, just kept for backwards compatibility.*/ void setVertexIndices(IndexArray* array); 3 indexes and 3 normals per Triangle. Normal binding is set to BIND_PER_PRIMITIVE_SET. Unfortunately the rendering shows the geometry flat in curious
[osg-users] precompiled binaries
Hi, I want to contribute precompiled binaries of Inventor/Coin plugin to https://osgtoy.svn.sourceforge.net/svnroot/osgtoy/3rdParty/branches/3rdParty_win32binaries_vs80sp1 and https://osgtoy.svn.sourceforge.net/svnroot/osgtoy/3rdParty/branches/3rdParty_win32binaries_vs90sp1 . Is there a standard procedure to proceed? I am willing to maintain and updates the binaries by the new releases of Inventor/Coin if I get write access (Do not worry about svn - I am not beginner). Otherwise, I can just deliver the binaries. At least one person asked me about the binaries, so I think, osgtoy would be a natural place to put it. John ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG using OpenGL ES 2.0 on IPhone
Hello,
In this post I want to report my progress on using OSG with OpenGL ES 2.0 on
the IPhone.
I am using OSG for my master thesis at the HPI. I needed a cross platform
rendering system which supports OpenGL ES 2.0 (to have shader support on iOS).
OSG was the only mature rendering system offering OpenGL ES 2.0 support and
having some progress on running it on the IPhone.
Building and setting up OSG on Mac and Windows was pretty easy. Luckily, there
is an OSG fork on GitHub which has an IPhone branch (stmh/osg/tree/iphone).
Using that branch, I managed to get an OSG sample running on the IPhone
Simulator.
I am using Version 4 of the iOS SDK, so I adjusted the Xcode project
(IPhone_Project/OSGIPhone.xcodeproj) to use version 4 as the base SDK and
changed the target to version 4 for the simulator.
The only code change I had to make it get it running was:
Code:
diff --git a/src/osgDB/FileUtils.cpp b/src/osgDB/FileUtils.cpp
index 573886a..073beb8 100644
--- a/src/osgDB/FileUtils.cpp
+++ b/src/osgDB/FileUtils.cpp
@@ -51,7 +51,7 @@ typedef char TCHAR;
//OSG_IPHONE
//IPhone includes
#include TargetConditionals.h
- #if (TARGET_OS_IPHONE) !(TARGET_IPHONE_SIMULATOR) //only when on device
+ #if (TARGET_OS_IPHONE)
#define stat64 stat
#endif
//OSG_IPHONE
The sample was running, but only using OpenGL ES 1.x...
Ok. So I started changing OSG's build config (IPhone_Project/config/osg/Config):
Code:
#ifndef OSG_CONFIG
#define OSG_CONFIG 1
//static link needed on IPhone
#define OSG_LIBRARY_STATIC
#define OSG_USE_FLOAT_MATRIX
/* #undef OSG_USE_FLOAT_PLANE */
#define OSG_USE_FLOAT_BOUNDINGSPHERE
#define OSG_USE_FLOAT_BOUNDINGBOX
#define OSG_USE_REF_PTR_IMPLICIT_OUTPUT_CONVERSION
/* #undef OSG_USE_UTF8_FILENAME */
#define OSG_DISABLE_MSVC_WARNINGS
/* #undef OSG_GLU_AVAILABLE */
/* #undef OSG_GL1_AVAILABLE */
/* #undef OSG_GL2_AVAILABLE */
/* #undef OSG_GL3_AVAILABLE */
/* #undef OSG_GLES1_AVAILABLE */
#define OSG_GLES2_AVAILABLE
/* #undef OSG_GL_DISPLAYLISTS_AVAILABLE */
/* #undef OSG_GL_MATRICES_AVAILABLE */
/* #undef OSG_GL_VERTEX_FUNCS_AVAILABLE */
/* #undef OSG_GL_VERTEX_ARRAY_FUNCS_AVAILABLE */
/* #undef OSG_GL_FIXED_FUNCTION_AVAILABLE */
#endif
Next location for adjustments was the GraphicsWindowIPhone
(src/osgViewer/GraphicsWindowIPhone.mm). GL functions which were suffixed with
OES for OpenGL ES 1 do not have this suffix in OpenGL ES 2. So I changed the
following:
Code:
diff --git a/src/osgViewer/GraphicsWindowIPhone.mm
b/src/osgViewer/GraphicsWindowIPhone.mm
index 9dab961..36cf916 100755
--- a/src/osgViewer/GraphicsWindowIPhone.mm
+++ b/src/osgViewer/GraphicsWindowIPhone.mm
@@ -11,6 +11,28 @@
#import OpenGLES/ES1/glext.h
#else
#import OpenGLES/ES2/glext.h
+// in GLES2, the OES suffix if dropped from function names
+#define glGenFramebuffersOES glGenFramebuffers
+#define glGenRenderbuffersOES glGenRenderbuffers
+#define glBindFramebufferOES glBindFramebuffer
+#define glBindRenderbufferOES glBindRenderbuffer
+#define glFramebufferRenderbufferOES glFramebufferRenderbuffer
+#define glGetRenderbufferParameterivOES glGetRenderbufferParameteriv
+#define glRenderbufferStorageOES glRenderbufferStorage
+#define glDeleteRenderbuffersOES glDeleteRenderbuffers
+#define glDeleteFramebuffersOES glDeleteFramebuffers
+#define glCheckFramebufferStatusOES glCheckFramebufferStatus
+
+#define GL_FRAMEBUFFER_OES GL_FRAMEBUFFER
+#define GL_RENDERBUFFER_OES GL_RENDERBUFFER
+#define GL_RENDERBUFFER_WIDTH_OES GL_RENDERBUFFER_WIDTH
+#define GL_RENDERBUFFER_HEIGHT_OES GL_RENDERBUFFER_HEIGHT
+#define GL_COLOR_ATTACHMENT0_OES GL_COLOR_ATTACHMENT0
+#define GL_DEPTH_ATTACHMENT_OES GL_DEPTH_ATTACHMENT
+#define GL_DEPTH_COMPONENT16_OES GL_DEPTH_COMPONENT16
+#define GL_STENCIL_INDEX8_OES GL_STENCIL_INDEX8
+#define GL_FRAMEBUFFER_COMPLETE_OES GL_FRAMEBUFFER_COMPLETE
+#define GL_STENCIL_ATTACHMENT_OES GL_STENCIL_ATTACHMENT
#endif
#include IPhoneUtils.h
Ok. Now OSG builds completely with the OpenGL ES 2 config. But running the
sample application provided with the IPhone branch
(IPhone_Project/iphoneExamples/simple/) fails while compiling the shaders. This
happens due to quite hard restrictions in GLSL ES. This issue seems similar to
thread #6120 (ShaderGen and OpenGL ES2). I started hacking around in
src/osgUtil/ShaderGen.cpp, but I think the cleaner solution is to provide
custom shaders.
So finally, the OSG application code I am currently running on the IPhone
(OpenGL ES 2), Windows (OpenGL 2) and Mac OS X (OpenGL 2) looks like this (only
the essential parts shown):
Code:
#define SHADER_COMPAT \
#ifndef GL_ES\n \
#if (__VERSION__ = 110)\n \
#define lowp\n \
#define mediump\n \
#define highp\n \
#endif\n \
#endif\n
static const char* vertSource = {
SHADER_COMPAT
// colors a fragment based on its position\n
varying mediump vec4 color;\n
void main(void) {\n
color = gl_Vertex;\n
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;\n
}\n
};
static const char* fragSource = {
SHADER_COMPAT
varying
Re: [osg-users] Saving the result of an IntersectVisitor
Ooh, that could work! Thanks, Terry, I will try that. -Todd On 08/25/2010 05:58 PM, Terry Welsh wrote: How about just a vector of vector of integers? Each integer would represent the nth child of the previous node, and each vector of integers would represent a whole nodepath. So 4 6 7 would mean the 7th child of the 6th child of the 4th child of the root node. -- Terry Welsh mogumbo 'at' gmail.com www.reallyslick.com Message: 14 Date: Wed, 25 Aug 2010 08:44:05 -0400 From: Todd J. Furlongt...@inv3rsion.com To: osg-users@lists.openscenegraph.org Subject: [osg-users] Saving the result of an IntersectVisitor Message-ID:4c751015.3010...@inv3rsion.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi all, I use an IntersectVisitor to select nodes in a viewer application. It works fine, and the first Geode in the hit list is the node I want to select. Now I need to record that hit as part of saving the state of our application in a metadata file that we save alongside a model file or files. This is where I've run into a problem. 1. Many of the nodes in our model files are unnamed (lost in translation, most likely), so I can't store the name of a Geode. 2. NodePaths are vectors of pointers, so they can't help me here. 3. I *could* save intersection rays play them back after loading. That would work, but it would be both slower and not quite in the spirit of saving the application state. So, I am throwing this problem out to the folks in the group. Am I unaware of an already-existing solution to this? Or does somebody out there have a clever idea to help me out? Thanks in advance, Todd ___ 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] backface and picking
Hi all,
I'm writing a piece of code to know, when a picking occurred, if the picked
face is orientated backward or forward... because if I understand well, there
is no simple way to avoid picking results on culled backfaces :
Code:
osgUtil::LineSegmentIntersector::Intersections intersections;
float x = ea.getX();
float y = ea.getY();
osg::ref_ptr osgUtil::LineSegmentIntersector picker = new
osgUtil::LineSegmentIntersector(osgUtil::Intersector::WINDOW, x, y);
osgUtil::IntersectionVisitor iv(picker.get());
iv.setTraversalMask(IS_PICKABLE_MASK);
view-getCamera()-accept(iv);
if (picker-containsIntersections())
{
intersections = picker-getIntersections();
for(osgUtil::LineSegmentIntersector::Intersections::iterator hitr =
intersections.begin();hitr != intersections.end();++hitr)
{
osg::Vec3 n = hitr-getLocalIntersectNormal();
osg::Vec3 eye = iv.getEyePoint();
osg::Vec3 inter = hitr-getLocalIntersectPoint();
n.normalize();
osg::Vec3 eyeVec = inter-eye;
eyeVec.normalize();
if (eyeVec*n0)
{
/*do something */
}
}
}
but the results are not what I thought... is there something wrong in my dot
product computed in local coords just to know if the normal is looking to the
camera or not ?
Thanks for your help
Eric[/code]
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=31073#31073
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OT: VS2010 LNK2005 problem related to ostringstream
Hi all. This is not related to OSG in any way, but as there so many experts on the list, I thought I should take the opportunity to ask this... I have a problem related to linking in VS2010. Im using VS2010 under Windows 7 (64). Im building a large source package which is divided into two separate libraries (dynamic linking: .lib, .dll). in the first library, a.lib we are using both std::stringstream and std::ostringstream. a.lib depends on other libraries, all built by myself using CMake and VS2010. CMake defaults to /MD code generation (MultiThreaded). Im using this consistently over all my libraries (just double checked to be sure). When I build the next library, b.lib, which depends on a.lib, I get the following linking errors: Linking of b.lib: 1a.lib(a.dll) : error LNK2005: public: void __thiscall std::basic_ostringstreamchar,struct std::char_traitschar,class std::allocatorchar ::`vbase destructor'(void) (??_d?$basic_ostringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@QAEXXZ) already defined in ImageCapture.obj 1a.lib(a.dll) : error LNK2005: public: class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar __thiscall std::basic_ostringstreamchar,struct std::char_traitschar,class std::allocatorchar ::str(void)const (?...@?$basic_ostringstream@DU ?$char_tra...@d@std@@v?$alloca...@d@2@@std@@qbe?av?$basic_str...@du ?$char_tra...@d@std@@v?$alloca...@d@2@@2...@xz) already defined in ImageCapture.obj 1a.lib(a.dll) : error LNK2005: public: __thiscall std::basic_ostringstreamchar,struct std::char_traitschar,class std::allocatorchar ::basic_ostringstreamchar,struct std::char_traitschar,class std::allocatorchar (int) (??0?$basic_ostringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@ @q...@h@Z) already defined in ImageCapture.obj Ok, I go into the sourcecode of ImageCapture.cpp and remove the use of std::ostringstream. And everything builds. Next, I try to use std::ostringstream in some other cpp file of the b.lib, so I just copy the code from ImageCapture.cpp into another .cpp file in b.lib, including the #include directives... It links just fine. One important thing to mention, all of this works just fine in VS2008. Next, I tried to change from std::ostringstream to std::stringstream in both a.lib AND b.lib. Now I get the same error, but instead its std::stringstream mentioned in the error message: 2a.lib(a.dll) : error LNK2005: public: void __thiscall std::basic_stringstreamchar,struct std::char_traitschar,class std::allocatorchar ::`vbase destructor'(void) (??_d?$basic_stringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@QAEXXZ) already defined in ImageCapture.obj 2a.lib(a.dll) : error LNK2005: public: class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar __thiscall std::basic_stringstreamchar,struct std::char_traitschar,class std::allocatorchar ::str(void)const (?...@?$basic_stringstream@DU ?$char_tra...@d@std@@v?$alloca...@d@2@@std@@qbe?av?$basic_str...@du ?$char_tra...@d@std@@v?$alloca...@d@2@@2...@xz) already defined in ImageCapture.obj 2a.lib(a.dll) : error LNK2005: public: __thiscall std::basic_stringstreamchar,struct std::char_traitschar,class std::allocatorchar ::basic_stringstreamchar,struct std::char_traitschar,class std::allocatorchar (int) (??0?$basic_stringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@q...@h@Z) already defined in ImageCapture.obj So, the situation is exactly the same, its just changed from std::ostringstream to std::stringstream. If I have just the right balance between stringstream and ostringstream, it builds. Then the problem occurs when I want to build a third library, depending on both a.lib AND b.lib... Then it starts all over. The next thing I did was to generate project files for vs2008, build with vs2008 (using dependencies built with vs2010), compiles/links just fine. Except it does not run (incompatible STL, crash in deque). Ok, so it builds in VS2008. Next was to build everything in vs2010 using the same project files. Then I get the above linking error. Im more and more leaning towards a bug in VS2010, but its really hard to verify... Anyone experienced this in VS2010? - ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OT: VS2010 LNK2005 problem related to ostringstream
Anders, It is somewhat relevant to OSG too, in that linking against osgDB and other code that uses fstream will cause similar 'multiple-defined' linker errors. This problem seems to be only with MSVC2010, the OS doesn't seem to matter (I use XP). osgDB is affected because of osgDB::fstream, which subclasses from std::fstream. The current workaround is to allow multiple symbols when linking. I would be interested in finding a better solution to this problem... Chuck On Aug 26, 2010, at 9:35 AM, Anders Backman wrote: Hi all. This is not related to OSG in any way, but as there so many experts on the list, I thought I should take the opportunity to ask this... I have a problem related to linking in VS2010. Im using VS2010 under Windows 7 (64). Im building a large source package which is divided into two separate libraries (dynamic linking: .lib, .dll). in the first library, a.lib we are using both std::stringstream and std::ostringstream. a.lib depends on other libraries, all built by myself using CMake and VS2010. CMake defaults to /MD code generation (MultiThreaded). Im using this consistently over all my libraries (just double checked to be sure). When I build the next library, b.lib, which depends on a.lib, I get the following linking errors: Linking of b.lib: 1a.lib(a.dll) : error LNK2005: public: void __thiscall std::basic_ostringstreamchar,struct std::char_traitschar,class std::allocatorchar ::`vbase destructor'(void) (??_d?$basic_ostringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@QAEXXZ) already defined in ImageCapture.obj 1a.lib(a.dll) : error LNK2005: public: class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar __thiscall std::basic_ostringstreamchar,struct std::char_traitschar,class std::allocatorchar ::str(void)const (?...@?$basic_ostringstream@du?$char_tra...@d@std@@v?$alloca...@d@2@@std@@qbe?av?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@2...@xz) already defined in ImageCapture.obj 1a.lib(a.dll) : error LNK2005: public: __thiscall std::basic_ostringstreamchar,struct std::char_traitschar,class std::allocatorchar ::basic_ostringstreamchar,struct std::char_traitschar,class std::allocatorchar (int) (??0?$basic_ostringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@q...@h@Z) already defined in ImageCapture.obj Ok, I go into the sourcecode of ImageCapture.cpp and remove the use of std::ostringstream. And everything builds. Next, I try to use std::ostringstream in some other cpp file of the b.lib, so I just copy the code from ImageCapture.cpp into another .cpp file in b.lib, including the #include directives... It links just fine. One important thing to mention, all of this works just fine in VS2008. Next, I tried to change from std::ostringstream to std::stringstream in both a.lib AND b.lib. Now I get the same error, but instead its std::stringstream mentioned in the error message: 2a.lib(a.dll) : error LNK2005: public: void __thiscall std::basic_stringstreamchar,struct std::char_traitschar,class std::allocatorchar ::`vbase destructor'(void) (??_d?$basic_stringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@QAEXXZ) already defined in ImageCapture.obj 2a.lib(a.dll) : error LNK2005: public: class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar __thiscall std::basic_stringstreamchar,struct std::char_traitschar,class std::allocatorchar ::str(void)const (?...@?$basic_stringstream@du?$char_tra...@d@std@@v?$alloca...@d@2@@std@@qbe?av?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@2...@xz) already defined in ImageCapture.obj 2a.lib(a.dll) : error LNK2005: public: __thiscall std::basic_stringstreamchar,struct std::char_traitschar,class std::allocatorchar ::basic_stringstreamchar,struct std::char_traitschar,class std::allocatorchar (int) (??0?$basic_stringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@q...@h@Z) already defined in ImageCapture.obj So, the situation is exactly the same, its just changed from std::ostringstream to std::stringstream. If I have just the right balance between stringstream and ostringstream, it builds. Then the problem occurs when I want to build a third library, depending on both a.lib AND b.lib... Then it starts all over. The next thing I did was to generate project files for vs2008, build with vs2008 (using dependencies built with vs2010), compiles/links just fine. Except it does not run (incompatible STL, crash in deque). Ok, so it builds in VS2008. Next was to build everything in vs2010 using the same project files. Then I get the above linking error. Im more and more leaning towards a bug in VS2010, but its really hard to verify... Anyone experienced this in VS2010? - ___ osg-users
Re: [osg-users] OT: VS2010 LNK2005 problem related to ostringstream
How do you allow multiple symbols in VisualStudio? /A On Thu, Aug 26, 2010 at 6:51 PM, Chuck Seberino seber...@energid.orgwrote: Anders, It is somewhat relevant to OSG too, in that linking against osgDB and other code that uses fstream will cause similar 'multiple-defined' linker errors. This problem seems to be only with MSVC2010, the OS doesn't seem to matter (I use XP). osgDB is affected because of osgDB::fstream, which subclasses from std::fstream. The current workaround is to allow multiple symbols when linking. I would be interested in finding a better solution to this problem... Chuck On Aug 26, 2010, at 9:35 AM, Anders Backman wrote: Hi all. This is not related to OSG in any way, but as there so many experts on the list, I thought I should take the opportunity to ask this... I have a problem related to linking in VS2010. Im using VS2010 under Windows 7 (64). Im building a large source package which is divided into two separate libraries (dynamic linking: .lib, .dll). in the first library, a.lib we are using both std::stringstream and std::ostringstream. a.lib depends on other libraries, all built by myself using CMake and VS2010. CMake defaults to /MD code generation (MultiThreaded). Im using this consistently over all my libraries (just double checked to be sure). When I build the next library, b.lib, which depends on a.lib, I get the following linking errors: Linking of b.lib: 1a.lib(a.dll) : error LNK2005: public: void __thiscall std::basic_ostringstreamchar,struct std::char_traitschar,class std::allocatorchar ::`vbase destructor'(void) (??_d?$basic_ostringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@QAEXXZ) already defined in ImageCapture.obj 1a.lib(a.dll) : error LNK2005: public: class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar __thiscall std::basic_ostringstreamchar,struct std::char_traitschar,class std::allocatorchar ::str(void)const (?str@ ?$basic_ostringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@ @qbe?av?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@2...@xz) already defined in ImageCapture.obj 1a.lib(a.dll) : error LNK2005: public: __thiscall std::basic_ostringstreamchar,struct std::char_traitschar,class std::allocatorchar ::basic_ostringstreamchar,struct std::char_traitschar,class std::allocatorchar (int) (??0?$basic_ostringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@ @q...@h@Z) already defined in ImageCapture.obj Ok, I go into the sourcecode of ImageCapture.cpp and remove the use of std::ostringstream. And everything builds. Next, I try to use std::ostringstream in some other cpp file of the b.lib, so I just copy the code from ImageCapture.cpp into another .cpp file in b.lib, including the #include directives... It links just fine. One important thing to mention, all of this works just fine in VS2008. Next, I tried to change from std::ostringstream to std::stringstream in both a.lib AND b.lib. Now I get the same error, but instead its std::stringstream mentioned in the error message: 2a.lib(a.dll) : error LNK2005: public: void __thiscall std::basic_stringstreamchar,struct std::char_traitschar,class std::allocatorchar ::`vbase destructor'(void) (??_d?$basic_stringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@QAEXXZ) already defined in ImageCapture.obj 2a.lib(a.dll) : error LNK2005: public: class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar __thiscall std::basic_stringstreamchar,struct std::char_traitschar,class std::allocatorchar ::str(void)const (?str@ ?$basic_stringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@ @qbe?av?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@2...@xz) already defined in ImageCapture.obj 2a.lib(a.dll) : error LNK2005: public: __thiscall std::basic_stringstreamchar,struct std::char_traitschar,class std::allocatorchar ::basic_stringstreamchar,struct std::char_traitschar,class std::allocatorchar (int) (??0?$basic_stringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@ @q...@h@Z) already defined in ImageCapture.obj So, the situation is exactly the same, its just changed from std::ostringstream to std::stringstream. If I have just the right balance between stringstream and ostringstream, it builds. Then the problem occurs when I want to build a third library, depending on both a.lib AND b.lib... Then it starts all over. The next thing I did was to generate project files for vs2008, build with vs2008 (using dependencies built with vs2010), compiles/links just fine. Except it does not run (incompatible STL, crash in deque). Ok, so it builds in VS2008. Next was to build everything in vs2010 using the same project files. Then I get the above linking error. Im more and more leaning towards a bug in VS2010, but its really hard to verify... Anyone experienced this in VS2010? -
Re: [osg-users] OT: VS2010 LNK2005 problem related to ostringstream
In the application properties: Configuration Properties - Linker - General - Force File Output - Multiply Defined Symbol Only (/FORCE:MULTIPLE) Chuck On Aug 26, 2010, at 10:11 AM, Anders Backman wrote: How do you allow multiple symbols in VisualStudio? /A On Thu, Aug 26, 2010 at 6:51 PM, Chuck Seberino seber...@energid.org wrote: Anders, It is somewhat relevant to OSG too, in that linking against osgDB and other code that uses fstream will cause similar 'multiple-defined' linker errors. This problem seems to be only with MSVC2010, the OS doesn't seem to matter (I use XP). osgDB is affected because of osgDB::fstream, which subclasses from std::fstream. The current workaround is to allow multiple symbols when linking. I would be interested in finding a better solution to this problem... Chuck On Aug 26, 2010, at 9:35 AM, Anders Backman wrote: Hi all. This is not related to OSG in any way, but as there so many experts on the list, I thought I should take the opportunity to ask this... I have a problem related to linking in VS2010. Im using VS2010 under Windows 7 (64). Im building a large source package which is divided into two separate libraries (dynamic linking: .lib, .dll). in the first library, a.lib we are using both std::stringstream and std::ostringstream. a.lib depends on other libraries, all built by myself using CMake and VS2010. CMake defaults to /MD code generation (MultiThreaded). Im using this consistently over all my libraries (just double checked to be sure). When I build the next library, b.lib, which depends on a.lib, I get the following linking errors: Linking of b.lib: 1a.lib(a.dll) : error LNK2005: public: void __thiscall std::basic_ostringstreamchar,struct std::char_traitschar,class std::allocatorchar ::`vbase destructor'(void) (??_d?$basic_ostringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@QAEXXZ) already defined in ImageCapture.obj 1a.lib(a.dll) : error LNK2005: public: class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar __thiscall std::basic_ostringstreamchar,struct std::char_traitschar,class std::allocatorchar ::str(void)const (?...@?$basic_ostringstream@du?$char_tra...@d@std@@v?$alloca...@d@2@@std@@qbe?av?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@2...@xz) already defined in ImageCapture.obj 1a.lib(a.dll) : error LNK2005: public: __thiscall std::basic_ostringstreamchar,struct std::char_traitschar,class std::allocatorchar ::basic_ostringstreamchar,struct std::char_traitschar,class std::allocatorchar (int) (??0?$basic_ostringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@q...@h@Z) already defined in ImageCapture.obj Ok, I go into the sourcecode of ImageCapture.cpp and remove the use of std::ostringstream. And everything builds. Next, I try to use std::ostringstream in some other cpp file of the b.lib, so I just copy the code from ImageCapture.cpp into another .cpp file in b.lib, including the #include directives... It links just fine. One important thing to mention, all of this works just fine in VS2008. Next, I tried to change from std::ostringstream to std::stringstream in both a.lib AND b.lib. Now I get the same error, but instead its std::stringstream mentioned in the error message: 2a.lib(a.dll) : error LNK2005: public: void __thiscall std::basic_stringstreamchar,struct std::char_traitschar,class std::allocatorchar ::`vbase destructor'(void) (??_d?$basic_stringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@QAEXXZ) already defined in ImageCapture.obj 2a.lib(a.dll) : error LNK2005: public: class std::basic_stringchar,struct std::char_traitschar,class std::allocatorchar __thiscall std::basic_stringstreamchar,struct std::char_traitschar,class std::allocatorchar ::str(void)const (?...@?$basic_stringstream@du?$char_tra...@d@std@@v?$alloca...@d@2@@std@@qbe?av?$basic_str...@du?$char_traits@d...@std@@v?$alloca...@d@2@@2...@xz) already defined in ImageCapture.obj 2a.lib(a.dll) : error LNK2005: public: __thiscall std::basic_stringstreamchar,struct std::char_traitschar,class std::allocatorchar ::basic_stringstreamchar,struct std::char_traitschar,class std::allocatorchar (int) (??0?$basic_stringstr...@du?$char_traits@d...@std@@v?$alloca...@d@2@@std@@q...@h@Z) already defined in ImageCapture.obj So, the situation is exactly the same, its just changed from std::ostringstream to std::stringstream. If I have just the right balance between stringstream and ostringstream, it builds. Then the problem occurs when I want to build a third library, depending on both a.lib AND b.lib... Then it starts all over. The next thing I did was to generate project files for vs2008, build with vs2008 (using dependencies built with vs2010), compiles/links just fine. Except it does not run (incompatible STL,
Re: [osg-users] OT: VS2010 LNK2005 problem related to ostringstream
On 26 August 2010 17:35, Anders Backman ande...@cs.umu.se wrote: snip CMake defaults to /MD code generation (MultiThreaded). Im using this consistently over all my libraries (just double checked to be sure). Never use that setting unless you know what you are doing. Change every project to Multi-threaded Debug DLL (/MDd) for Debug builds and Multi-threaded DLL (/MD) for Release builds And it will all start working. Those Runtime library settings are the number one 'gotch-ya' for Visual studio, and Cmake defaulting to them is daft. -- http://www.ssTk.co.uk ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OT: VS2010 LNK2005 problem related to ostringstream
Well, I have verified that ALL the dependencies Im using are all built with /MD and NOT debug. Im building all of the dependencies for osg and our lib myself, so I got full control. Also, as I wrote before, I have even tried to build our libs using project files generated from cmake vs2008, build with vs2008 - works ok. Open same project files in vs2010 - problem occurs. Im using buildscripts to build dependencies, and it all works for vs2008... No external libraries, everything is built from code. For VS2010, all the dependencies (including osg 2.8.3) builds/links fine. But for my libs, I get the linking errors. Allowing multiple symbols sounds dangerous, and it did not resolve my problem... /A On Thu, Aug 26, 2010 at 7:26 PM, Simon Hammett s.d.hamm...@googlemail.comwrote: On 26 August 2010 17:35, Anders Backman ande...@cs.umu.se wrote: snip CMake defaults to /MD code generation (MultiThreaded). Im using this consistently over all my libraries (just double checked to be sure). Never use that setting unless you know what you are doing. Change every project to Multi-threaded Debug DLL (/MDd) for Debug builds and Multi-threaded DLL (/MD) for Release builds And it will all start working. Those Runtime library settings are the number one 'gotch-ya' for Visual studio, and Cmake defaulting to them is daft. -- http://www.ssTk.co.uk ___ 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] Bones Animation
Hi, I'm kind a new in OSG context. I would like to know if someone know or has an sample of how can i move the bones of an .FBX model. I'm trying to develop a virtual hand that you can translate and move your fingers trough some sensors in your real hand. I'm already rendering de .fbx model and translating it in the scene but i'm stucked in the finger bones moving. The .fbx hand sure has bones. If somebody could help me i would appreciate a lot! ... Thank you! Cheers, Bruno -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31076#31076 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Bones Animation
Bruno Dias wrote: Hi, I'm kind a new in OSG context. I would like to know if someone know or has an sample of how can i move the bones of an .FBX model. I'm trying to develop a virtual hand that you can translate and move your fingers trough some sensors in your real hand. I'm already rendering de .fbx model and translating it in the scene but i'm stucked in the finger bones moving. The .fbx hand sure has bones. If somebody could help me i would appreciate a lot! Hi, Bruno, There are a few examples that deal with skinning and animation (they all have osganimation in their name). You might want to start there. --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Bones Animation
I picked up a copy of Game Engine Architecture by Jason Gregory at SIGGRAPH. Appears that he covers a huge breadth of the genre, where's he's focused. There's an animation chapter in there that includes skeletons and skinning. I'm about a 3rd the way thru so far and can't comment on that particular chapter. However, I'm betting it's a viable resource - at that level. Probably not good for detailed implementation. Bob -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jason Daly Sent: Thursday, August 26, 2010 12:00 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] Bones Animation Bruno Dias wrote: Hi, I'm kind a new in OSG context. I would like to know if someone know or has an sample of how can i move the bones of an .FBX model. I'm trying to develop a virtual hand that you can translate and move your fingers trough some sensors in your real hand. I'm already rendering de .fbx model and translating it in the scene but i'm stucked in the finger bones moving. The .fbx hand sure has bones. If somebody could help me i would appreciate a lot! Hi, Bruno, There are a few examples that deal with skinning and animation (they all have osganimation in their name). You might want to start there. --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] OT: VS2010 LNK2005 problem related to ostringstream
Ah ok, then next things to check: Make absolutely sure you aren't mixing up objects libraries from the different builds. For my projects I include a vc version number in the name, so .vc7.lib/vc7.dll .vc9.lib/.vc9.dll and I also use the vc version in the name of output intermediate directory Then check all the code for any use of #pragma comment(lib, libname) and make sure any preprocessor guards that select different versions have been updated to know about vc2010. On 26 August 2010 18:37, Anders Backman ande...@cs.umu.se wrote: Well, I have verified that ALL the dependencies Im using are all built with /MD and NOT debug. Im building all of the dependencies for osg and our lib myself, so I got full control. Also, as I wrote before, I have even tried to build our libs using project files generated from cmake vs2008, build with vs2008 - works ok. Open same project files in vs2010 - problem occurs. Im using buildscripts to build dependencies, and it all works for vs2008... No external libraries, everything is built from code. For VS2010, all the dependencies (including osg 2.8.3) builds/links fine. But for my libs, I get the linking errors. Allowing multiple symbols sounds dangerous, and it did not resolve my problem... /A On Thu, Aug 26, 2010 at 7:26 PM, Simon Hammett s.d.hamm...@googlemail.com wrote: On 26 August 2010 17:35, Anders Backman ande...@cs.umu.se wrote: snip CMake defaults to /MD code generation (MultiThreaded). Im using this consistently over all my libraries (just double checked to be sure). Never use that setting unless you know what you are doing. Change every project to Multi-threaded Debug DLL (/MDd) for Debug builds and Multi-threaded DLL (/MD) for Release builds And it will all start working. Those Runtime library settings are the number one 'gotch-ya' for Visual studio, and Cmake defaulting to them is daft. -- http://www.ssTk.co.uk ___ 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 -- http://www.ssTk.co.uk ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Bones Animation
Bruno Dias wrote: Hi, I'm kind a new in OSG context. I would like to know if someone know or has an sample of how can i move the bones of an .FBX model. I'm trying to develop a virtual hand that you can translate and move your fingers trough some sensors in your real hand. I'm already rendering de .fbx model and translating it in the scene but i'm stucked in the finger bones moving. The .fbx hand sure has bones. If somebody could help me i would appreciate a lot! ... I already have something similar working, just using MatrixTransforms at the knuckle joints. What additional functionality do you hope to achieve by using FBX bones? Hardware skinning? -- -Paul Martz Skew Matrix Software http://www.skew-matrix.com/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
