Re: [osg-users] create a OSG wiki: (it was OpenSceneGraph Oculus Rift integration )
gwaldron wrote: Robert, No, unfortunately RTD is not an alternative to doxygen. It only renders your RST files into HTML, PDF etc. Such an integration is a good idea though, and I've heard people ask for it. I'll have to see if anyone's working on that. There is a plugin to Sphinx (the generator backend of RTD) which is called Breathe. Breathe can read doxygen comments and output Sphinx formatted code: http://github.com/michaeljones/breathe /Björn -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=60900#60900 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] create a OSG wiki: (it was OpenSceneGraph Oculus Rift integration )
HI Bjorn, On 2 September 2014 07:57, Björn Blissing bjorn.bliss...@vti.se wrote: gwaldron wrote: Robert, No, unfortunately RTD is not an alternative to doxygen. It only renders your RST files into HTML, PDF etc. Such an integration is a good idea though, and I've heard people ask for it. I'll have to see if anyone's working on that. There is a plugin to Sphinx (the generator backend of RTD) which is called Breathe. Breathe can read doxygen comments and output Sphinx formatted code: http://github.com/michaeljones/breathe Thanks for the link. Having all these little titbits from different users in a discussion shows the value of community :-) -- In my idea world we'd have documentation inline with source (doxygen style) linking with a two way link with general discussion/higher level documentation so when is browsing the documentation one can jump between the two seamlessly. So for discussion could do something like mirror the structure of the OSG as it stands: OpenSceneGraph/include/osg etc. OpenSceneGraoh/src/osg etc. OpenSceneGraph/doc/osg etc. Then have a Cmake script generate the RST files and place them in the doc directories. We'd then want the hand written RST files to sit alongside these in some manner. Would the hand written ones sit alongside the automatically generated ones or in a separate directory? If you had them sitting alongside each other then naming would be the way to different and just have a naming convention that make it clear which is which. Obviously one would check in the hand written RST files, but would you check in the automatically generated ones as well? Currently we don't check in the doxygen generated docs. If one wanted to have RTD generate the HTML docs then one would need both together at the same time. Thoughts everyone? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] how to set the model view projection matrix for my own vertex shader
Hi all. First of all, sorry if mine is a silly question, I'm quite new to using shaders in OSG. My scenario is this: I have a vertex shader that gets as uniform in-variable the model view projection matrix, MVP_matrix is the name of that variable in my shader. The shader is written in GL4.3, so I cannot rely upon the deprecated built-in variable gl_ModelViewProjection matrix. Now, I have to attach such shader in a program that is set in a state set used to render my geometry (that state set is attached to the geode that contains my drawable, where the geometry is defined). So, I would like that OSG automatically passes the model view projection matrix to my shader during rendering traversal. I've seen in some OSG code that there is a predefined in-variable called osg_ModelViewProjectionMatrix that I think is filled by OSG during rendering traversal with the current model view projection matrix. Is that correct? So, should I rely upon it in my shader, basically replacing my MVP_matrix with osg_ModelViewProjectionMatrix? Further question: unfortunately the shader I have to use is shared among other applications in my company, and not all of them use OSG for rendering (some use pure OpenGL) :( So it's likely that I cannot modify it (otherwise I should ask all developers to change the name of the in-variable they pass directly to the shader to osg_ModelViewProjectionMatrix). Hence the question: if I'm forced to use MVP_matrix, is there a way I can tell OSG to set automatically the value of osg_ModelViewProjectionMatrix to MVP_matrix at run-time, i.e. during rendering traversal? Thanks, Gianluca ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Warped scene with two sets of Geodes
Hi Robert,
thanks for your reply. I'm kinda new in the OSG/OpenGL field, so I'm
thankful for all the help and advice I can get.
The goal of the project I'm working on is to develop algorithms for
street label positioning on an active route. So I have a street
network, a pointer that moves along a route in the network and a
camera that follows the pointer, and then I have a bunch of labels
that I position and move around. (I think I might have written
something in this mailing list two years ago.)
I never thought that it could be anything other than a mistake of my
own. The problem occurs on the following configurations:
Thinkpad T420 with i5 CPU/Graphics Card (Intel HD3000 I think)
Arch Linux 3.16.1
OSG version 3.2.1
OSG version 3.0.1
G++ version 4.9.1
Intel Video Driver version 2.99.914
Intel DRI Software version 10.2.6
Thinkpad T60 with Radeon Graphics Card
(I only did this quickly, so I don't have all the details)
Arch Linux 3.16.1
OSG version 3.2.1
G++ version 4.9.1
I tried another program that I knew was working two years ago on this
computer, and it has a similar issue (though different) now—the
pointer is just not there. Additionally, the osgText labels are not
showing up either.
The past few days since your response, I also worked on getting it to
compile on Windows 7, with Visual Studio 12. (FYI: I had to add an
#include algorithm to osgText/Glyph.cpp for it to compile, otherwise
it didn't see min/max.) I'll write again after I finish that.
Is there a better way to represent the street network? Should I have a
Group containing a bunch of street lines and then apply color and line
width at that level? Or do I store the street lines all in a single
Geode?
I updated (and simplified) the source code listing to include the
pointer drawing code—perhaps the problem lies there? (I also changed
the street network to contain a bunch of drawables inside a single
Geode. Is it better that way? Or am I going a completely wrong
direction with that?)
Thanks again for your help!
–Ben
PS: And here is the updated source code (also updated at StackOverflow):
// My libraries:
#include asl/util/color.h
using namespace asl;
#include straph/point.h
#include straph/straph.h
using namespace straph;
// Standard and OSG libraries:
#include utility
#include boost/tuple/tuple.hpp // tie
using namespace std;
#include osg/ref_ptr
#include osg/Array
#include osg/Geometry
#include osg/Geode
#include osg/Group
#include osg/LineWidth
using namespace osg;
#include osgUtil/Tessellator
#include osgViewer/Viewer
using namespace osgViewer;
/*
* Just FYI: A Polyline looks like this:
*
* typedef std::vectorPoint Polyline;
*
* And a Point basically is a simple struct:
*
* struct Point {
* double x;
* double y;
* };
*/
inline osg::Vec3d toVec3d(const straph::Point p, double elevation=0.0)
{
return osg::Vec3d(p.x, p.y, elevation);
}
Geometry* createStreet(const straph::Polyline path)
{
ref_ptrVec3dArray array (new Vec3dArray(path.size()));
for (unsigned i = 0; i path.size(); ++i) {
(*array)[i] = toVec3d(path[i]);
}
Geometry* geom = new Geometry;
geom-setVertexArray(array.get());
geom-addPrimitiveSet(new osg::DrawArrays(GL_LINE_STRIP, 0,
array-size()));
return geom;
}
Geode* load_streets()
{
unique_ptrStraph graph = read_shapefile(mexico/roads, 6);
Geode* root = new Geode();
boost::graph_traitsstraph::Straph::edge_iterator ei, ee;
for (boost::tie(ei, ee) = edges(*graph); ei != ee; ++ei) {
const straph::Segment s = (*graph)[*ei];
root-addDrawable(createStreet(s.polyline));
}
return root;
}
Geode* createPointer(double width, const Color body_color)
{
float f0 = 0.0f;
float f3 = 3.0f;
float f1 = 1.0f * width;
float f2 = 2.0f * width;
// Create vertex array
ref_ptrVec3Array vertices (new Vec3Array(4));
(*vertices)[0].set( f0 , f0, f0 );
(*vertices)[1].set( -f1/f3, -f1/f3 , f0 );
(*vertices)[2].set( f0 , f2/f3 , f0 );
(*vertices)[3].set( f1/f3, -f1/f3 , f0 );
// Build the geometry object
ref_ptrGeometry polygon (new Geometry);
polygon-setVertexArray( vertices.get() );
polygon-addPrimitiveSet( new DrawArrays(GL_POLYGON, 0, 4) );
// Set the colors
ref_ptrVec4Array body_colors (new Vec4Array(1));
(*body_colors)[0] = body_color.get();
polygon-setColorArray( body_colors.get() );
polygon-setColorBinding( Geometry::BIND_OVERALL );
// Create Geode object
Geode* geode = new Geode;
geode-addDrawable( polygon.get() );
return geode;
}
int
Re: [osg-users] create a OSG wiki: (it was OpenSceneGraph Oculus Rift integration )
Hi Robert, I would say that the hand written ones would best sit alongside the generated once, with some kind of suffix like 'discuss' or 'details'. It also seems to make sense to me to check in the generated docs as well, or else it could cause some confusion. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=60904#60904 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] First time render hiccup
Hi all, Another open-ended question I'm afraid, but maybe someone has seen this before: I sometimes see hiccups (rendering pauses) in my driving simulation, I noticed it only happens with some vehicles, and only when they appear in the frustum for the first time. I wonder how to minimize this effect. Clues: -Once the model has been displayed there is no more hiccup. -Differerent models produce different hiccup delays (consistently) -Hiccup problem does not scale with .ive size or nr of polygons -In bad cases I can see the osgstats cull part go to zero for about 1 sec. -Using ProxyNode makes no difference. Suggestions? Some caching options I can try? Anything nasty to look for in the .ive models? (Most are 3DS format made by 3rd party, converted with osgconv, sorry I can't share them) I'm using OSG 3.01, compositeviewer, linux, Nvidia (different cards, same problem.) Thanks! /Per ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] how to set the model view projection matrix for my own vertex shader
Hi Gianluca, osg_ModelViewProjectionMatrix is the OSG's equivilant to gl_ModelViewProjectMatrix, and there is a mechanism in osg::State that can replace gl_ModelViewMatrixProjectMatrix usage in shaders with the osg_ equivalent at runtime. There isn't however a general customizable support for setting and substituting your own uniforms in this role. In your own application I'd suggest when you set up your osg::Shader with the shader source you replace the MVP_matrix usage with gl_ or osg_ equivalent. Robert. On 2 September 2014 10:59, Gianluca Natale nat...@europe.altair.com wrote: Hi all. First of all, sorry if mine is a silly question, I'm quite new to using shaders in OSG. My scenario is this: I have a vertex shader that gets as uniform in-variable the model view projection matrix, MVP_matrix is the name of that variable in my shader. The shader is written in GL4.3, so I cannot rely upon the deprecated built-in variable gl_ModelViewProjection matrix. Now, I have to attach such shader in a program that is set in a state set used to render my geometry (that state set is attached to the geode that contains my drawable, where the geometry is defined). So, I would like that OSG automatically passes the model view projection matrix to my shader during rendering traversal. I've seen in some OSG code that there is a predefined in-variable called osg_ModelViewProjectionMatrix that I think is filled by OSG during rendering traversal with the current model view projection matrix. Is that correct? So, should I rely upon it in my shader, basically replacing my MVP_matrix with osg_ModelViewProjectionMatrix? Further question: unfortunately the shader I have to use is shared among other applications in my company, and not all of them use OSG for rendering (some use pure OpenGL) L So it's likely that I cannot modify it (otherwise I should ask all developers to change the name of the in-variable they pass directly to the shader to osg_ModelViewProjectionMatrix). Hence the question: if I'm forced to use MVP_matrix, is there a way I can tell OSG to set automatically the value of osg_ModelViewProjectionMatrix to MVP_matrix at run-time, i.e. during rendering traversal? Thanks, Gianluca ___ 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] First time render hiccup
Hi Per, Stalls like you describe are typically when the graphics driver has to compile new OpenGL objects. There are range of things that can cause compilation to be slow, I haven't to head off line right now so will have to leave you with that hint... Robert. On 2 September 2014 12:27, Per Nordqvist nordqv...@gmail.com wrote: Hi all, Another open-ended question I'm afraid, but maybe someone has seen this before: I sometimes see hiccups (rendering pauses) in my driving simulation, I noticed it only happens with some vehicles, and only when they appear in the frustum for the first time. I wonder how to minimize this effect. Clues: -Once the model has been displayed there is no more hiccup. -Differerent models produce different hiccup delays (consistently) -Hiccup problem does not scale with .ive size or nr of polygons -In bad cases I can see the osgstats cull part go to zero for about 1 sec. -Using ProxyNode makes no difference. Suggestions? Some caching options I can try? Anything nasty to look for in the .ive models? (Most are 3DS format made by 3rd party, converted with osgconv, sorry I can't share them) I'm using OSG 3.01, compositeviewer, linux, Nvidia (different cards, same problem.) Thanks! /Per ___ 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] First time render hiccup
We have been having the same issue and haven't found a solution yet either, though it hasn't been our main priority yet. I will be following any responses closely and will contribute if I can. -Original Message- From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Tuesday, September 02, 2014 8:01 AM To: OpenSceneGraph Users Subject: Re: [osg-users] First time render hiccup Hi Per, Stalls like you describe are typically when the graphics driver has to compile new OpenGL objects. There are range of things that can cause compilation to be slow, I haven't to head off line right now so will have to leave you with that hint... Robert. On 2 September 2014 12:27, Per Nordqvist nordqv...@gmail.com wrote: Hi all, Another open-ended question I'm afraid, but maybe someone has seen this before: I sometimes see hiccups (rendering pauses) in my driving simulation, I noticed it only happens with some vehicles, and only when they appear in the frustum for the first time. I wonder how to minimize this effect. Clues: -Once the model has been displayed there is no more hiccup. -Differerent models produce different hiccup delays (consistently) -Hiccup problem does not scale with .ive size or nr of polygons -In bad cases I can see the osgstats cull part go to zero for about 1 sec. -Using ProxyNode makes no difference. Suggestions? Some caching options I can try? Anything nasty to look for in the .ive models? (Most are 3DS format made by 3rd party, converted with osgconv, sorry I can't share them) I'm using OSG 3.01, compositeviewer, linux, Nvidia (different cards, same problem.) Thanks! /Per ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org smime.p7s Description: S/MIME cryptographic signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] First time render hiccup
Per, If you don't want to pre-compile your GL objects, the IncrementalCompileOperation might help too. But you might need a newer version of OSG. Glenn Waldron / @glennwaldron On Tue, Sep 2, 2014 at 7:27 AM, Per Nordqvist nordqv...@gmail.com wrote: Hi all, Another open-ended question I'm afraid, but maybe someone has seen this before: I sometimes see hiccups (rendering pauses) in my driving simulation, I noticed it only happens with some vehicles, and only when they appear in the frustum for the first time. I wonder how to minimize this effect. Clues: -Once the model has been displayed there is no more hiccup. -Differerent models produce different hiccup delays (consistently) -Hiccup problem does not scale with .ive size or nr of polygons -In bad cases I can see the osgstats cull part go to zero for about 1 sec. -Using ProxyNode makes no difference. Suggestions? Some caching options I can try? Anything nasty to look for in the .ive models? (Most are 3DS format made by 3rd party, converted with osgconv, sorry I can't share them) I'm using OSG 3.01, compositeviewer, linux, Nvidia (different cards, same problem.) Thanks! /Per ___ 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] Creating Geometry Manually
Dear All,
I'm trying to create arbitray shape by manually entering the vertices normals
and indices of object. For this I use the following pseudo algorithm for object
creation, but the resulting shape edges are not discernible as shown in the
attached snapshot (marked with purple ellipse).
Also manually created object is not recognized by the Intersectors while the
T shaped object is recognized.
osg::Node * CreatObject(){//VERTICESosg::Vec3Array* obj_vertices =
new osg::Vec3Array;obj_vertices-push_back(osg::Vec3d(-3., 4.,
-0.));.. /// NORMALSosg::Vec3d vec1, vec2, vec3;
osg::ref_ptrosg::Vec3Array normals = new osg::Vec3Array;vec1[0] = 0;
vec1[1] = 0; vec1[3] =-1;
normals-push_back(vec1);normals-push_back(vec1);normals-push_back(vec1);normals-push_back(vec1);
normals-push_back(vec1);normals-push_back(vec1);normals-push_back(vec1);normals-push_back(vec1);
normals-push_back(vec1);normals-push_back(vec1);normals-push_back(vec1);normals-push_back(vec1);
// INDICES osg::ref_ptrosg::Geometry geom = new osg::Geometry;
geom-setVertexArray( obj_vertices );geom-addPrimitiveSet( indices.get()
);geom-setNormalArray(normals.get());
geom-getOrCreateStateSet()-setMode(GL_RESCALE_NORMAL,osg::StateAttribute::ON);
geom-setNormalBinding(osg::Geometry::BIND_PER_VERTEX);
osgUtil::SmoothingVisitor::smooth( *geom );osg::ref_ptrosg::Geode
I_object = new osg::Geode;I_object-addDrawable( geom.get() );
scene_ALL-addChild(I_object);} ___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] First time render hiccup
I'll check it out. Thanks. -Original Message- From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Glenn Waldron Sent: Tuesday, September 02, 2014 8:21 AM To: OpenSceneGraph Users Subject: Re: [osg-users] First time render hiccup Per, If you don't want to pre-compile your GL objects, the IncrementalCompileOperation might help too. But you might need a newer version of OSG. Glenn Waldron / @glennwaldron On Tue, Sep 2, 2014 at 7:27 AM, Per Nordqvist nordqv...@gmail.com wrote: Hi all, Another open-ended question I'm afraid, but maybe someone has seen this before: I sometimes see hiccups (rendering pauses) in my driving simulation, I noticed it only happens with some vehicles, and only when they appear in the frustum for the first time. I wonder how to minimize this effect. Clues: -Once the model has been displayed there is no more hiccup. -Differerent models produce different hiccup delays (consistently) -Hiccup problem does not scale with .ive size or nr of polygons -In bad cases I can see the osgstats cull part go to zero for about 1 sec. -Using ProxyNode makes no difference. Suggestions? Some caching options I can try? Anything nasty to look for in the .ive models? (Most are 3DS format made by 3rd party, converted with osgconv, sorry I can't share them) I'm using OSG 3.01, compositeviewer, linux, Nvidia (different cards, same problem.) Thanks! /Per ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org smime.p7s Description: S/MIME cryptographic signature ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] First time render hiccup
Thanks guys for the answers! I guess it's OK to take a hit at the beginning if things run smoothly afterwards, so I don't think I need a incremental compilation. Based on your answers I found a similar question here http://forum.openscenegraph.org/viewtopic.php?t=4997 So I tried this: osgViewer::Renderer* renderer = dynamic_castosgViewer::Renderer*(viewer-getCamera()-getRenderer()); renderer-setCompileOnNextDraw(true); which is promising beacuse it creates exactly the same stall that I was seeing before. However, if I have hidden objects under a switch or if it's outside the frustum, I still see a recompilation triggered automatically once it is in the frustum and visible under the switch. So how to compile the _entire_ scene? /Per On 2 September 2014 14:21, Glenn Waldron gwald...@gmail.com wrote: Per, If you don't want to pre-compile your GL objects, the IncrementalCompileOperation might help too. But you might need a newer version of OSG. Glenn Waldron / @glennwaldron On Tue, Sep 2, 2014 at 7:27 AM, Per Nordqvist nordqv...@gmail.com wrote: Hi all, Another open-ended question I'm afraid, but maybe someone has seen this before: I sometimes see hiccups (rendering pauses) in my driving simulation, I noticed it only happens with some vehicles, and only when they appear in the frustum for the first time. I wonder how to minimize this effect. Clues: -Once the model has been displayed there is no more hiccup. -Differerent models produce different hiccup delays (consistently) -Hiccup problem does not scale with .ive size or nr of polygons -In bad cases I can see the osgstats cull part go to zero for about 1 sec. -Using ProxyNode makes no difference. Suggestions? Some caching options I can try? Anything nasty to look for in the .ive models? (Most are 3DS format made by 3rd party, converted with osgconv, sorry I can't share them) I'm using OSG 3.01, compositeviewer, linux, Nvidia (different cards, same problem.) Thanks! /Per ___ 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] R: how to set the model view projection matrix for my own vertex shader
Oh yes, Robert, that's the most obvious and quickest solution, sorry for the silly question! Once loaded my shader source code from the file, I'll replace all the occurrences of MVP_matrix with osg_ModelViewProjectionMatrix, and OSG will update it for me during rendering traversal. Thanks a lot! :) Gianluca Da: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] Per conto di Robert Osfield Inviato: martedì 2 settembre 2014 13:56 A: OpenSceneGraph Users Oggetto: Re: [osg-users] how to set the model view projection matrix for my own vertex shader Hi Gianluca, osg_ModelViewProjectionMatrix is the OSG's equivilant to gl_ModelViewProjectMatrix, and there is a mechanism in osg::State that can replace gl_ModelViewMatrixProjectMatrix usage in shaders with the osg_ equivalent at runtime. There isn't however a general customizable support for setting and substituting your own uniforms in this role. In your own application I'd suggest when you set up your osg::Shader with the shader source you replace the MVP_matrix usage with gl_ or osg_ equivalent. Robert. On 2 September 2014 10:59, Gianluca Natale nat...@europe.altair.commailto:nat...@europe.altair.com wrote: Hi all. First of all, sorry if mine is a silly question, I'm quite new to using shaders in OSG. My scenario is this: I have a vertex shader that gets as uniform in-variable the model view projection matrix, MVP_matrix is the name of that variable in my shader. The shader is written in GL4.3, so I cannot rely upon the deprecated built-in variable gl_ModelViewProjection matrix. Now, I have to attach such shader in a program that is set in a state set used to render my geometry (that state set is attached to the geode that contains my drawable, where the geometry is defined). So, I would like that OSG automatically passes the model view projection matrix to my shader during rendering traversal. I've seen in some OSG code that there is a predefined in-variable called osg_ModelViewProjectionMatrix that I think is filled by OSG during rendering traversal with the current model view projection matrix. Is that correct? So, should I rely upon it in my shader, basically replacing my MVP_matrix with osg_ModelViewProjectionMatrix? Further question: unfortunately the shader I have to use is shared among other applications in my company, and not all of them use OSG for rendering (some use pure OpenGL) :( So it's likely that I cannot modify it (otherwise I should ask all developers to change the name of the in-variable they pass directly to the shader to osg_ModelViewProjectionMatrix). Hence the question: if I'm forced to use MVP_matrix, is there a way I can tell OSG to set automatically the value of osg_ModelViewProjectionMatrix to MVP_matrix at run-time, i.e. during rendering traversal? Thanks, Gianluca ___ osg-users mailing list osg-users@lists.openscenegraph.orgmailto:osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Creating Geometry Manually
HI Sonya,
If you are using osgUtil::SmoothingVisitor you won't need to assign the
normals as the smoothing visitor will do this for. By default the
smoothing visitor will smooth edges as you have see in your picture, this
is a natural consequence of the vertices at the edges being adjacent to
several triangles each with their own orientation, but as there is only one
normal per vertex is direction is an average of all the normals that share
that vertex.
In recent versions of the OSG osgUtil::SmoothingVisitor has a new feature
setCreateAngle(double angle), which.. copying and pasting the inline docs:
/// set the maximum angle, in radians, at which angle between
adjacent triangles that normals are smoothed
/// for edges that greater the shared vertices are duplicated
void setCreaseAngle(double angle) { _creaseAngle = angle; }
So just add this and set an angle such as :
osgUtil::SmoothingVisitor sv;
sv.setCreateAngle(osg::inDegrees(90.0)); // note inDegrees converts a
angle in degrees in to radians.
sv.smooth(*geometry);
Robert.
On 2 September 2014 13:53, Sonya Blade sonyablade2...@hotmail.com wrote:
Dear All,
I'm trying to create arbitray shape by manually entering the vertices normals
and indices of object.
For this I use the following pseudo algorithm for object creation, but
the resulting shape edges are
not discernible as shown in the attached snapshot (marked with purple
ellipse).
Also manually created object is not recognized by the Intersectors while
the T shaped object is recognized.
osg::Node * CreatObject()
{
//VERTICES
osg::Vec3Array* obj_vertices = new osg::Vec3Array;
obj_vertices-push_back(osg::Vec3d(-3., 4., -0.));
..
/// NORMALS
osg::Vec3d vec1, vec2, vec3;
osg::ref_ptrosg::Vec3Array normals = new osg::Vec3Array;
vec1[0] = 0; vec1[1] = 0; vec1[3] =-1;
normals-push_back(vec1);normals-push_back(vec1);normals-push_back(vec1);normals-push_back(vec1);
normals-push_back(vec1);normals-push_back(vec1);normals-push_back(vec1);normals-push_back(vec1);
normals-push_back(vec1);normals-push_back(vec1);normals-push_back(vec1);normals-push_back(vec1);
// INDICES
osg::ref_ptrosg::Geometry geom = new osg::Geometry;
geom-setVertexArray( obj_vertices );
geom-addPrimitiveSet( indices.get() );
geom-setNormalArray(normals.get());
geom-getOrCreateStateSet()-setMode(GL_RESCALE_NORMAL,osg::StateAttribute::ON);
geom-setNormalBinding(osg::Geometry::BIND_PER_VERTEX);
osgUtil::SmoothingVisitor::smooth( *geom );
osg::ref_ptrosg::Geode I_object = new osg::Geode;
I_object-addDrawable( geom.get() );
scene_ALL-addChild(I_object);
}
___
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] First time render hiccup
Hi Per, On 2 September 2014 14:18, Per Nordqvist nordqv...@gmail.com wrote: Thanks guys for the answers! I guess it's OK to take a hit at the beginning if things run smoothly afterwards, so I don't think I need a incremental compilation. Based on your answers I found a similar question here http://forum.openscenegraph.org/viewtopic.php?t=4997 So I tried this: osgViewer::Renderer* renderer = dynamic_castosgViewer::Renderer*(viewer-getCamera()-getRenderer()); renderer-setCompileOnNextDraw(true); This simply runs the GLObjectVisitor on the next frame to run GL object compile on objects in scene graph, which, if you have lots of new GL objects to be compiled will result in a frame stall. which is promising beacuse it creates exactly the same stall that I was seeing before. Best case is setCompileOnNextDraw(true) will perform the same as just rendering it without if everything is on screen, if some elements would otherwise be culled the frame time will actually be longer as all the GL objects that need to be compiled will be compiled at the same time. The advantage comes in subsequent frames as no new objects will enter the view frustum and then have to be compiled. However, if I have hidden objects under a switch or if it's outside the frustum, I still see a recompilation triggered automatically once it is in the frustum and visible under the switch. So how to compile the _entire_ scene? You need to slow down and understand the basic mechanics of what is going on. The OSG has lots of features to help with these issues but it's an advanced topic with no magic wand so best take bit by bit. Part of the solution will be use of the ogUtil::IncrementalCompileOperation as it designed to load balance the number of GL compilations and deletes that happen each frame so that no one frame gets overload and causes a frame break. The OSG's DatabasePager utilizes the ogUtil::IncrementCompileOperation to avoid frame breaks, and osgViewer::Viewer/CompositeViewer have support for IncrementalCompileOperation built in, so the infrastructure is all there waiting to be utilized. When you incremental compile objects you have to submit a subgraph to be compiled and this is done by bit until all parts are compiled and when they are these subgraphs are placed in a ready to be merged list, you can also get a callback to get informed that a subgraph is ready. There are lots of controls in the IncrementalCompileOperation to tune how quickly GL objects get compiled - you can balance the speed of compilation vs the risk of breaking frame. Another part of the work to make this efficient is make sure that the GL objects in the scene graph are efficient to compile. Various drivers have different strengths and weakness so what might be slow on one driver/hardware might be fast on another. There are however general rules. For instance generating of texture mipmaps can be a bottleneck so precomputing mipmaps and storing them on disk can help, compressing imagery in an OpenGL native compression format can also be very helpful. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PositionAttitudeTransform operation order
HI Gianni, The definitive answer always comes from the code, so if you can learn to read C++ you'll often find the answer directly in the OSG code base, this is *exactly* what I have just done to provide an answer, the relevant code in src/osg/PositionAttitudeTransform.cpp is: matrix.preMultTranslate(_position); matrix.preMultRotate(_attitude); matrix.preMultScale(_scale); matrix.preMultTranslate(-_pivotPoint); As each is a pre multiple of the modelview matrix what you have in effect is: Transform by -_pivotPoint (the _pvitoPoint is the point in your subgraph you want to rotate/scale about) Sale by _scale Rotation by _attitude Translate by _posotion (set the final position of the _pivotPoint. The _pivotPoint is by default 0,0,0 is in effect by default PositionAttitudeTransform scales, rotate around a local origin then translates by the position you set. Robert. On 2 September 2014 15:11, Gianni Ambrosio g.ambrosio+...@gmail.com wrote: Hi All, sorry for the stupid question but I didn't find an explicit or clear answer on books, searching the forum or OSG code. Which is the operation order handled by PositionAttitudeTransform? Since I can set position, rotation and scale separately, is translation done before rotation? That seems so from my tests. Looking at PAT code it seems also scale is performed after translation and rotation. But looking at the code I wrote some times ago, where I added a PAT node as child of another PAT node to perform scaling without affecting translation and rotation, it seems the opposite. So, I'm a little confused. Thank you for clarifications Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=60920#60920 ___ 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] First time render hiccup
Thanks Robert for the detailed answer, I see the point of incremental compilation now but for my particular use case where I basically load everything at the beginning (but hide some things from the camera) I think my magic wand still is this Performer parading trick. I'm happy to break many frames as long as I can make it happen in the beginning, so compile time is not a major issue here. I just did some initial parade tests and I can confirm the stalls are gone now so it seems to work out great. Still this solution is a bit hacky, so if Carl or somebody else proceeds with the incremental path I'm curios to see an example of how complex it gets. /Per On 2 September 2014 16:02, Robert Osfield robert.osfi...@gmail.com wrote: Hi Per, On 2 September 2014 14:18, Per Nordqvist nordqv...@gmail.com wrote: Thanks guys for the answers! I guess it's OK to take a hit at the beginning if things run smoothly afterwards, so I don't think I need a incremental compilation. Based on your answers I found a similar question here http://forum.openscenegraph.org/viewtopic.php?t=4997 So I tried this: osgViewer::Renderer* renderer = dynamic_castosgViewer::Renderer*(viewer-getCamera()-getRenderer()); renderer-setCompileOnNextDraw(true); This simply runs the GLObjectVisitor on the next frame to run GL object compile on objects in scene graph, which, if you have lots of new GL objects to be compiled will result in a frame stall. which is promising beacuse it creates exactly the same stall that I was seeing before. Best case is setCompileOnNextDraw(true) will perform the same as just rendering it without if everything is on screen, if some elements would otherwise be culled the frame time will actually be longer as all the GL objects that need to be compiled will be compiled at the same time. The advantage comes in subsequent frames as no new objects will enter the view frustum and then have to be compiled. However, if I have hidden objects under a switch or if it's outside the frustum, I still see a recompilation triggered automatically once it is in the frustum and visible under the switch. So how to compile the _entire_ scene? You need to slow down and understand the basic mechanics of what is going on. The OSG has lots of features to help with these issues but it's an advanced topic with no magic wand so best take bit by bit. Part of the solution will be use of the ogUtil::IncrementalCompileOperation as it designed to load balance the number of GL compilations and deletes that happen each frame so that no one frame gets overload and causes a frame break. The OSG's DatabasePager utilizes the ogUtil::IncrementCompileOperation to avoid frame breaks, and osgViewer::Viewer/CompositeViewer have support for IncrementalCompileOperation built in, so the infrastructure is all there waiting to be utilized. When you incremental compile objects you have to submit a subgraph to be compiled and this is done by bit until all parts are compiled and when they are these subgraphs are placed in a ready to be merged list, you can also get a callback to get informed that a subgraph is ready. There are lots of controls in the IncrementalCompileOperation to tune how quickly GL objects get compiled - you can balance the speed of compilation vs the risk of breaking frame. Another part of the work to make this efficient is make sure that the GL objects in the scene graph are efficient to compile. Various drivers have different strengths and weakness so what might be slow on one driver/hardware might be fast on another. There are however general rules. For instance generating of texture mipmaps can be a bottleneck so precomputing mipmaps and storing them on disk can help, compressing imagery in an OpenGL native compression format can also be very helpful. 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] First time render hiccup
Hi Per, On 2 September 2014 15:32, Per Nordqvist nordqv...@gmail.com wrote: Thanks Robert for the detailed answer, I see the point of incremental compilation now but for my particular use case where I basically load everything at the beginning (but hide some things from the camera) I think my magic wand still is this Performer parading trick. I'm happy to break many frames as long as I can make it happen in the beginning, so compile time is not a major issue here. I just did some initial parade tests and I can confirm the stalls are gone now so it seems to work out great. Still this solution is a bit hacky, so if Carl or somebody else proceeds with the incremental path I'm curios to see an example of how complex it gets. If you need make things are compiled then the CompileOnNextDraw is what almost all of what you need. There is only one caveat this this in that the driver can compile GL objects but leave only in main memory (but managed by the driver rather than the application) without downloading the objects to the GPU. Forcing a render of objects forces the objects to become resident which is where the parade tests used in Performer can be useful, you don't actually have to render on screen though. The IncrementCompileOperation actually has an option for forcing a dummy render that doesn't effect the actual final rendering result. The GLObjectsVisitor doesn't have this option though. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Creating Geometry Manually
Thank You Robert,
That SetCreaseAngle solves the problem, secondly and more important why
manually created object is not recognized by the PolytopeInteresctor ? Is there
any preliminary settings that I'm missing to configure?
Regards,Date: Tue, 2 Sep 2014 14:47:33 +0100
From: robert.osfi...@gmail.com
To: osg-users@lists.openscenegraph.org
Subject: Re: [osg-users] Creating Geometry Manually
HI Sonya,
If you are using osgUtil::SmoothingVisitor you won't need to assign the normals
as the smoothing visitor will do this for. By default the smoothing visitor
will smooth edges as you have see in your picture, this is a natural
consequence of the vertices at the edges being adjacent to several triangles
each with their own orientation, but as there is only one normal per vertex is
direction is an average of all the normals that share that vertex.
In recent versions of the OSG osgUtil::SmoothingVisitor has a new feature
setCreateAngle(double angle), which.. copying and pasting the inline docs:
/// set the maximum angle, in radians, at which angle between adjacent
triangles that normals are smoothed
/// for edges that greater the shared vertices are duplicated
void setCreaseAngle(double angle) { _creaseAngle = angle; }
So just add this and set an angle such as :
osgUtil::SmoothingVisitor sv;
sv.setCreateAngle(osg::inDegrees(90.0)); // note inDegrees converts a angle
in degrees in to radians.
sv.smooth(*geometry);
Robert.
On 2 September 2014 13:53, Sonya Blade sonyablade2...@hotmail.com wrote:
Dear All,
I'm trying to create arbitray shape by manually entering the vertices normals
and indices of object.
For this I use the following pseudo algorithm for object creation, but the
resulting shape edges are
not discernible as shown in the attached snapshot (marked with purple ellipse).
Also manually created object is not recognized by the Intersectors while the
T shaped object is recognized.
osg::Node * CreatObject()
{//VERTICESosg::Vec3Array* obj_vertices = new osg::Vec3Array;
obj_vertices-push_back(osg::Vec3d(-3., 4., -0.));
.. /// NORMALSosg::Vec3d vec1, vec2, vec3;
osg::ref_ptrosg::Vec3Array normals = new osg::Vec3Array;vec1[0] = 0;
vec1[1] = 0; vec1[3] =-1;
normals-push_back(vec1);normals-push_back(vec1);normals-push_back(vec1);normals-push_back(vec1);
normals-push_back(vec1);normals-push_back(vec1);normals-push_back(vec1);normals-push_back(vec1);
normals-push_back(vec1);normals-push_back(vec1);normals-push_back(vec1);normals-push_back(vec1);
// INDICES osg::ref_ptrosg::Geometry geom = new osg::Geometry;
geom-setVertexArray( obj_vertices );geom-addPrimitiveSet( indices.get() );
geom-setNormalArray(normals.get());
geom-getOrCreateStateSet()-setMode(GL_RESCALE_NORMAL,osg::StateAttribute::ON);
geom-setNormalBinding(osg::Geometry::BIND_PER_VERTEX);
osgUtil::SmoothingVisitor::smooth( *geom );osg::ref_ptrosg::Geode
I_object = new osg::Geode;I_object-addDrawable( geom.get() );
scene_ALL-addChild(I_object);}
___
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] Creating Geometry Manually
On 2 September 2014 21:07, Sonya Blade sonyablade2...@hotmail.com wrote: Thank You Robert, That SetCreaseAngle solves the problem, secondly and more important why manually created object is not recognized by the PolytopeInteresctor ? Is there any preliminary settings that I'm missing to configure? I don't have any idea what might be amiss, you should need to do anything to the scene graph to utilize the PolytopeIntersector. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Creating Geometry Manually
On 2 September 2014 21:36, Robert Osfield robert.osfi...@gmail.com wrote: I don't have any idea what might be amiss, you should need to do anything to the scene graph to utilize the PolytopeIntersector. Oopps typo should read you *shouldn't* need to do anything :-) Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [ANN] Autostereoscopic Displays Available - Glasses Free 3D
Glasses Free Displays with real-time conversion of left-right stereo pair video or interactive graphics input are now available. These displays allow you to see 3d depth in your graphics without 3d glasses. We have 4k resolution displays available that can combine 2 HD (1920x1080) input streams to build the final 'multi-image' for display. The input is a standardized Full HD 3D (FHD3D) stream in over-under format as specified by the HDMI 1.4 specification and is easily achievable with OSG. We have example code for guidance. Please visit our website or contact us for more information. Thank you. Brett Weichers bre...@markresources.com Mark Resources, LLC San Francisco, CA www.markresources.com Tel: 319,404.1015 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Proper way to display a HUD
Hi Chris,
I suppose I could use something other than an OSG::Image to bind to the
BYTE property of my struct.
whatever you bind, the way you copy rendered results to layered window (
see your
memcpy which is exactly copying via system memory ) will move video
memory to system memory and this is a bottleneck
the suggestion was to avoid this step and perform whatever you want in
video memory ( even if a copy will occur- the copy between video memory is
much faster than a copy to system memory.
You might remember, I already sent you three approaches to avoid working
via system memory ( maybe others will find this tip useful too in case of
such an attempt ).
1) use windows DWM trick as in http://www.youtube.com/watch?v=4qWKSYWIqdk
the code to look at how it is achived is here
https://github.com/sphair/ClanLib/tree/master/Examples/GUI/GUI_Layered
the idea is here is that you render using DWM system calls and then
compose layered windows without old layered windows api which you try to
use to achive result. Here layering is achieved by exploiting the fact
that in new windows ( since Vista ) all windows first are rendered to
offscreen surface, but then are composed to produce final screen result -
you will be limited here to any windows operation system above windows xp (
but it is already retired and Vista is also not widely used - so limiting
yourself just to Win7+ will make all coding much easier ). BTW on linux the
same result possibly could be achieved via wayland compositor.
You might compile ClanLib and see how that achieved - it is fairly easy and
takes just few lines of code during creation of window and the complete
code to achive what you need is provided, so you will need just add the
same code to osg window creation function ( and use appropriate flags
elsewhere to use DWM hack, but still, as in this example it is fairly easy
to achive ).
2) use http://msdn.microsoft.com/en-us/magazine/ee819134.aspx approach and
then https://sites.google.com/site/snippetsanddriblits/OpenglDxInterop to
copy opengl rendered result to Direct2D layered window in video memory (
currently NV_DX_interop
http://www.opengl.org/registry/specs/NV/DX_interop2.txt and NV_DX_interop2
http://www.opengl.org/registry/specs/NV/DX_interop2.txt are supported on
almost all video cards ), that might not work, due to possible problems
with very difficult path via Direct3D/Direct2D texture, but still it is
possible that it will work and will give you better results than now
3) you might use rendering with OpenGL ES with osg ( though you would need
to have your own model loader ) via ANGLE to use
http://msdn.microsoft.com/en-us/magazine/ee819134.aspx trick, as final
rendered result in ANGLE might be a direct3d texture, which you could apply
to Direct2D layered window.
all approaches are not easy to implement to novice, but still - in case you
want to significantly improve fps - you should avoid working via system
memory, maybe someone else can offer some other insights - but I think that
there are hardly any more, so you still will have to implement one of
suggested approaches. And looks like the first suggested approach is most
simple one and also can be possibly ported to linux, at least ClanLib team
tries to have that example to run on linux too ,to significantly improve
fps for the task you wish to solve.
Regards
Sergey
On Mon, Sep 1, 2014 at 7:27 PM, Chris Hidden ch...@erghis.com wrote:
Hey Robert
Thanks for the more detailed explanation. From what I can make out you
are able to render the 3 models to a pbuffer than render this with
transparency over the desktop OK, this part if functioning as intended. Is
this correct?
Yes this is correct!
As for the HUD Ill try getting it working in a standard OSG graphics
context first as you said. Probably the best idea.
As far as your suggestions for optimization. I think I understand.
However I was under the impression that the osg::Image was the pbuffer.
In order to to my transparent screen trick I have a struct:
Code:
typedef struct
{
int width;
int height;
int pitch;
HDC hdc;
HBITMAP hBitmap;
BITMAPINFO info;
BYTE*pPixels;
} Scene;
Then I initiate the struct with some init values. Then the I do a memcpy
from the pbuffer/image to the struct:
Code:
for (int i = 0; i g_image-t(); ++i)
{
memcpy(g_scene.pPixels[g_scene.pitch * i],
g_image-data()[((sHeight - 1) - i) * (sWidth *
4)],
sWidth * 4);
}
Here g_image is my osg::image and g_scene is my struct. Once I have
copied the data I redraw to my layered window . This method takes care
of applying the necessary actions using BLENDFUNCTION and
UpdateLayeredWindow.
Code:
void RedrawLayeredWindow()
{
//
