[osg-users] Possible bug in osg::State::applyShaderCompositionUniform
Hi Robert, A few month ago, you solved one of my issues : http://forum.openscenegraph.org/viewtopic.php?t=11769postdays=0postorder=ascstart=14 Today I've discovered some problems with this approach (I use it for materials, as you suggested in your post) : the shader composition uniforms seems to not been inherited correctly. I've spotted the problem source : in void State::apply(const StateSet* dstate), there is this line : _currentShaderCompositionUniformList.clear(); So all shader composition uniforms are cleared at each StateSet apply. I've tried to comment this line and everything seems to work. Since I don't really understand the shader cmoposition uniforms system, can you give me some advices on this issue ? Thank you! Cheers, Aurelien -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=56433#56433 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] graphics context capabilities in cull phase
Hi Robert and Mathias, back after the weekend. I do also wonder about formalizing the extension set up. In essence we are initializing bool relating to feature supported yes/no, and the function pointers. Currently it's all rather adhoc how this is all done. The whole area could do with a major refactor to make things more coherent. For refactoring, three ideas are coming to my mind (please, append yours): 1. I would like to have GL_FEATURE(...) macro that would register me a bool that would be set to a yes/no depending on some evaluation (extension support, GL version, GLSL version, number of texture samplers, etc.). I should be able to get its value on per-contextID basis. and GL_FUNCTION() macro that would register me a function that would be automatically initialized (per-context) during realize. But I am worrying about performance hit as looking-up the function by contextID might take some time. Thus, I would prefer another approach. 2. I would like to have a class, say GraphicsContextMediator, and I would append members by macros named, say, GL_FEATURE(...) (for an auto-detected bool) and GL_FUNCTION(...) (for an auto-binded OpenGL function). They would automatically initialize their content on the GraphicsContextMediator construction. The construction would be triggered by a proxy during GraphicsContext::realize(). GraphicsContextMediator could be a private class, if we want. It can be inside any .cpp file, providing GL informations wherever programmer puts it, including StatsHandler. This way, StatsHandler might stop out-source OpenGL function pointers from Drawable::Extensions, but they might be moved to its own code, possibly improving the code quality. 3. Still one more option - to use existing osg::isExtensionOrVersionSupported() and similar functions and make them work properly even outside active graphics context. However, this functionality would probably not serve for advanced things like getting number of texture samplers or max uniforms, etc. Just extensions and OpenGL version and nothing more. Still more ideas by anyone? For a registry of objects to initialize my inclination would be to have a registry of all OpenGL objects types, which is essentially osg::Drawable and osg::StateAttribute's, perhaps one could just have a registry of osg::Object and then cast these to Drawable or StateAttribute then call a function to do the initialize. I would also be inclined to have a initializeExtensions(State) method that Drawable and StateAttribute have that is called. This approach would mean you wouldn't need to worry about the specifics of the various extension classes. However, this might not be ideal subdivision for this feature. I agree, just I do not understand - what do you mean by registry of OpenGL object types? Object type is not an instance, thus it does not have a pointer that could be registered in a list. Could you clarify for me how it would work? Thanks, John On Friday 20 of September 2013 14:16:36 Robert Osfield wrote: Hi John and Mathias, I haven't discounted or approve of any one option yet, but have done a little more thinking. Mathias's suggestion of a flag whether the realize should invoke all the initialization steps or leave it to lazy initialization would be sensible if we wish to avoid the cost of initializing all extensions sounds reasonable compromise. Although this might leave application developers need to support both lazy and realize initializations in their applications yet in case. For a registry of objects to initialize my inclination would be to have a registry of all OpenGL objects types, which is essentially osg::Drawable and osg::StateAttribute's, perhaps one could just have a registry of osg::Object and then cast these to Drawable or StateAttribute then call a function to do the initialize. I would also be inclined to have a initializeExtensions(State) method that Drawable and StateAttribute have that is called. This approach would mean you wouldn't need to worry about the specifics of the various extension classes. However, this might not be ideal subdivision for this feature. I do also wonder about formalizing the extension set up. In essence we are initializing bool relating to feature supported yes/no, and the function pointers. Currently it's all rather adhoc how this is all done. The whole area could do with a major refactor to make things more coherent. More widely I do also wonder whether we should split up the scene graph data from the OpenGL implementation, so that the scene graph data object would have a list of implementations, these implementations might contain handles to extensions or OpenGL object id's a handle to the extension. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Compute Intersections with GL_POINT drawable
Hello,
I am trying to do some hit tests on a geode that only has one drawable of a
GL_POINT.
It seems my hit test only picks up the very center of the point, no matter how
large I draw the point. Could I get some guidance on how to pick the object
using the actual size?
Here is the picking code:
Code:
osg::Node *hitObj = NULL;
osg::ref_ptrosgUtil::PolytopeIntersector picker = pick(x,y,view);
if (!picker-containsIntersections())
{
return false;
}
osgUtil::PolytopeIntersector::Intersections::const_iterator it;
for (it = picker-getIntersections().begin();
it!=picker-getIntersections().end(); ++it)
{
const osg::NodePath nodePath = it-nodePath;
unsigned int idx = nodePath.size();
while (idx--)
{
hitObj = nodePath[idx];
switch (m_state)
{
case DEFAULT:
if (dynamic_castShape*(hitObj) !plan-locked())
{
return true;
}
.
osg::ref_ptrosgUtil::PolytopeIntersector Picker::pick(float x, float y,
osgViewer::View *view)
{
float win = 1;
osg::ref_ptrosgUtil::PolytopeIntersector picker = new
osgUtil::PolytopeIntersector(osgUtil::Intersector::WINDOW,
x-win,y-win,x+win,y+win);
osgUtil::IntersectionVisitor iv(picker.get());
view-getCamera()-accept(iv);
return picker.get();
}
And here is the geode:
Code:
Geometry* geom = new Geometry;
Vec3Array* vert = new Vec3Array;
vert-push_back(Vec3(0,0,0));
geom-setVertexArray(vert);
geom-addPrimitiveSet(new DrawArrays(osg::PrimitiveSet::POINTS,0,1));
StateSet* state = geom-getOrCreateStateSet();
state-setMode(GL_LIGHTING, StateAttribute::OFF |
StateAttribute::PROTECTED);
state-setAttribute(new Point(20), StateAttribute::ON);
state-setMode(GL_POINT_SMOOTH, StateAttribute::ON);
Geode* geode = new Geode;
geode-addDrawable(geom);
geode-setCullingActive(false);
ColorSetterVisitor color(Vec4(1,1,1,1));
geode-accept(color);
addChild(geode);
[/code]
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=56436#56436
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG 3.2 Linux + Eclipse debugging problem
Hi,
I'm having problems putting to work eclipse c++ project with osg. I have no
problems compiling the code
Code:
int main (int argc, char* argv[])
{
osgViewer::Viewer viewer;
osg::Node* grp =
osgDB::readNodeFile(./workspace/AvatarPlatform_/data/Models/scene.fbx);
viewer.setSceneData( grp );
return viewer.run();
}
but if I debug or lauch it I get a error.
Eclipse debug error when osgDB::readNodeFile is called:
Can't find a source file at
/home/aitorard/OpenSceneGraph-3.2.0/include/osgDB/Registry
Locate the file or edit the source lookup path to include its location.
I have incorrectly installed OSG? If I use osgviewer I can load a fbx models...
Thank you!
Cheers,
Aitor
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=56437#56437
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] graphics context capabilities in cull phase
Hi John, My brain is rather full with thoughts about scripting integration right now so not much space to ponder other issues so can't provide an in-depth reply yet, but one question you had was quick to answer so I'll do so below, then come back to the topic more widely later. On 23 September 2013 12:04, PCJohn pec...@fit.vutbr.cz wrote: I agree, just I do not understand - what do you mean by registry of OpenGL object types? Object type is not an instance, thus it does not have a pointer that could be registered in a list. Could you clarify for me how it would work? Simply one would register an instance of each of the osg::StateAttribute and osg::Drawable subclasses, this then serves as a prototype list than can be invoked later for things like setting up extensions. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] MatrixTransforms and MatrixD
Hi, thank you for your quick answer. In fact, my project is part of a GIS and these big transforms are are actually part of such a local origin approach. However, I still have not understood where the inaccuracies that I see come from. I have, however, reduced the critical part of my scene graph construction to just a few lines of code: // let bigMatrix1 and 2 be my transforms with numbers in the order of magnitude of a million // let scene be the subgraph that contains visible geometry // let root be the top of my scene graph // approach #1 (working fine) ref_ptrMatrixTransform bigTransform1 = new MatrixTransform(bigMatrix1); ref_ptrMatrixTransform bigTransform2 = new MatrixTransform(bigMatrix2); bigTransform1-addChild( scene ); bigTransform2-addChild(bigTransform1); root = bigTransform2; // approach #2 (visible inaccuracies) ref_ptrMatrixTransform singleTransform = new MatrixTransform(bigMatrix1 * bigMatrix2); singleTransform-addChild( scene ); root = singleTransform; I have searched my entire project for Vecf's and Matrixf's. I use none of them. The matrix I set in my subclass of CameraManipulator is also a Matrixf. As another experiment, I have casted the big matrices down to Matrixf once, and multiplied them with test vectors. The floating point errors that came out of this where pretty much in the order of magnitude of the inaccuracies that I witness when using the above approach #2 (with doubles). So, it really looks as if OSG was using float when doing my transforms in 2 steps. I am somewhat desperate for an answer to this... Do you have any ideas what could go wrong here, or how I could investigate the problem any deeper? Is it possible to apply a MatrixTransform node to a Vec3 'by hand'? Greets, Simon PS: All of this is targeting iOS. Just in case this is important. Von: osg-users-boun...@lists.openscenegraph.org [osg-users-boun...@lists.openscenegraph.org] im Auftrag von Robert Osfield [robert.osfi...@gmail.com] Gesendet: Montag, 16. September 2013 19:52 An: OpenSceneGraph Users Betreff: Re: [osg-users] MatrixTransforms and MatrixD Hi Simon, The OSG by default uses double Matrices (osg::Matrix is typedef'd to osg::Matrixd) for all internal transforms and camera matrices. The matrices are all accumulated in doubles and passed to OpenGL as doubles. Most OpenGL drivers will then cast the matrices down to floats when passing down to the GPU, but as the OSG passes a fully accumulated modelview matrix the precision is at least the best you can get. To best handle scenes with large extents one breaks the scene into regional tiles, each of which has a local origin and then a MatrixTransform above the tile subgraph to place it in it's final world coordinates. The OSG is used widely in the GIS market with many users handling whole earth database without precision issues. So... for you as long as you haven't deliberately compiled the OSG to use osg::Matrix and a osg::Matrixf then you'll be uses doubles. How you manage your scene graph and internal transforms will be the key, get it right as I suggest above then you shouldn't have issues. Robert. On 16 September 2013 17:48, Voelcker, Simon simon.voelc...@student.hpi.uni-potsdam.demailto:simon.voelc...@student.hpi.uni-potsdam.de wrote: Hi, I am using MatrixTransform nodes with matrices that contain quite large numbers. When I stack two of these transforms, I notice severe floating point inaccuracies in the scene, although I use double precision matrices to set up my transform nodes. Is it possible that OSG uses only single precision here (internally), and if so, how can I force it to use double precision? I know I could multiply my matrices directly and use a single MatrixTransform node, but I want to avoid this since it breaks my architecture. Thanks in advance, Simon ___ 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
[osg-users] OSG web site guidelines
My client who drove the creation of the osgTransparencyToolkit has asked me to see about adding it to the OSG website so that new users can find and utilize it and it can grow. (I presume that it doesn't really belong in the core OSG distribution). What would be the recommended section of the OSG website to list the project in? -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Training • Consulting • Contracting 3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL Digital Imaging • GIS • GPS • osgEarth • Terrain • Telemetry • Cryptography • Digital Audio • LIDAR • Kinect • Embedded • Mobile • iPhone/iPad/iOS • Android @alphapixel https://twitter.com/alphapixel facebook.com/alphapixel (775) 623-PIXL [7495] ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG 3.2 Linux + Eclipse debugging problem
On Mon, Sep 23, 2013 at 3:55 PM, Aitor Ardanza aitoralt...@hotmail.com wrote: Eclipse debug error when osgDB::readNodeFile is called: Can't find a source file at /home/aitorard/OpenSceneGraph-3.2.0/include/osgDB/Registry Locate the file or edit the source lookup path to include its location. I have incorrectly installed OSG? If I use osgviewer I can load a fbx models... Thank you! That is not really anything to do with OSG, it is basic debugging setup. Do you have the OSG sources in the folder /home/aitorard/OpenSceneGraph-3.2.0 ? If not (you have moved or deleted them), you need to tell Eclipse/gdb where the sources are. That is set up in the debugging configuration settings. Otherwise you can debug only in assembly language, because the debugger won't be able to load the matching source file for you. The source code location is stored in the debug symbols of the libraries you have built, so if the source is in the original place, the debugger will find the right files automatically. If not, you must help it a bit and tell it where to find the files by specifying a path. Regards, Jan ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG web site guidelines
Hi Chris, You may want to add it here http://www.openscenegraph.org/index.php/community/projects Cheers El lunes, 23 de septiembre de 2013, Chris Hanson escribió: My client who drove the creation of the osgTransparencyToolkit has asked me to see about adding it to the OSG website so that new users can find and utilize it and it can grow. (I presume that it doesn't really belong in the core OSG distribution). What would be the recommended section of the OSG website to list the project in? -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Training • Consulting • Contracting 3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL Digital Imaging • GIS • GPS • osgEarth • Terrain • Telemetry • Cryptography • Digital Audio • LIDAR • Kinect • Embedded • Mobile • iPhone/iPad/iOS • Android @alphapixel https://twitter.com/alphapixel facebook.com/alphapixel (775) 623-PIXL [7495] -- Jordi Torres ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OSG web site guidelines
And maybe you want to post a community new as well. El lunes, 23 de septiembre de 2013, Jordi Torres escribió: Hi Chris, You may want to add it here http://www.openscenegraph.org/index.php/community/projects Cheers El lunes, 23 de septiembre de 2013, Chris Hanson escribió: My client who drove the creation of the osgTransparencyToolkit has asked me to see about adding it to the OSG website so that new users can find and utilize it and it can grow. (I presume that it doesn't really belong in the core OSG distribution). What would be the recommended section of the OSG website to list the project in? -- Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com http://www.alphapixel.com/ Training • Consulting • Contracting 3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL Digital Imaging • GIS • GPS • osgEarth • Terrain • Telemetry • Cryptography • Digital Audio • LIDAR • Kinect • Embedded • Mobile • iPhone/iPad/iOS • Android @alphapixel https://twitter.com/alphapixel facebook.com/alphapixel (775) 623-PIXL [7495] -- Jordi Torres -- Jordi Torres ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Possible bug in osg::State::applyShaderCompositionUniform
On 23.9.2013 12:51, Aurelien Albert wrote: I've spotted the problem source : in void State::apply(const StateSet* dstate), there is this line : _currentShaderCompositionUniformList.clear(); So all shader composition uniforms are cleared at each StateSet apply. I've tried to comment this line and everything seems to work. Since I don't really understand the shader cmoposition uniforms system, can you give me some advices on this issue ? Hi Aurelien, I'm almost done with my experimental shader composition project. So far I was able to port 3/4 of FFP attributes to the shader compositor. I've designed ShaderComposerVisitor that will populate graph with shader attributes, either by replacing existing FFP attributes (for core profile and ES 2.0) or add them to coexist with existing FFP attributes to provide fallback for old hardware. I wasn't able to pull it through with osg::ShaderAttribute or with composition uniforms (having current state-set's local scope), instead I had to roll my own ShaderComponentAttribute based on osg::ShaderAttribute that is able to manage standard uniforms and ShaderComponent and apply standard osg matrices if requested. I've also made a few nonintrusive changes to the osg core to support RenderStage scope uniforms to be able to handle position state attributes properly. If there is some interest I could send all the stuff to the submissions at the end of this week to at least hang in there until somone else find a better solution. Robert Milharcic ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] MatrixTransforms and MatrixD
Hi Simon, I'm afraid I can't spot what might be amiss from your code snippets and description. All I can say is the local origin scheme used by VPB and other tools like osgEarth works extremely well. I've explain how it's structured so don't know what more to add. Perhaps others can provide some advice. Robert. On 23 September 2013 16:13, Voelcker, Simon simon.voelc...@student.hpi.uni-potsdam.de wrote: Hi, thank you for your quick answer. In fact, my project is part of a GIS and these big transforms are are actually part of such a local origin approach. However, I still have not understood where the inaccuracies that I see come from. I have, however, reduced the critical part of my scene graph construction to just a few lines of code: // let bigMatrix1 and 2 be my transforms with numbers in the order of magnitude of a million // let scene be the subgraph that contains visible geometry // let root be the top of my scene graph // approach #1 (working fine) ref_ptrMatrixTransform bigTransform1 = new MatrixTransform(bigMatrix1); ref_ptrMatrixTransform bigTransform2 = new MatrixTransform(bigMatrix2); bigTransform1-addChild( scene ); bigTransform2-addChild(bigTransform1); root = bigTransform2; // approach #2 (visible inaccuracies) ref_ptrMatrixTransform singleTransform = new MatrixTransform(bigMatrix1 * bigMatrix2); singleTransform-addChild( scene ); root = singleTransform; I have searched my entire project for Vecf's and Matrixf's. I use none of them. The matrix I set in my subclass of CameraManipulator is also a Matrixf. As another experiment, I have casted the big matrices down to Matrixf once, and multiplied them with test vectors. The floating point errors that came out of this where pretty much in the order of magnitude of the inaccuracies that I witness when using the above approach #2 (with doubles). So, it really looks as if OSG was using float when doing my transforms in 2 steps. I am somewhat desperate for an answer to this... Do you have any ideas what could go wrong here, or how I could investigate the problem any deeper? Is it possible to apply a MatrixTransform node to a Vec3 'by hand'? Greets, Simon PS: All of this is targeting iOS. Just in case this is important. Von: osg-users-boun...@lists.openscenegraph.org [ osg-users-boun...@lists.openscenegraph.org] im Auftrag von Robert Osfield [robert.osfi...@gmail.com] Gesendet: Montag, 16. September 2013 19:52 An: OpenSceneGraph Users Betreff: Re: [osg-users] MatrixTransforms and MatrixD Hi Simon, The OSG by default uses double Matrices (osg::Matrix is typedef'd to osg::Matrixd) for all internal transforms and camera matrices. The matrices are all accumulated in doubles and passed to OpenGL as doubles. Most OpenGL drivers will then cast the matrices down to floats when passing down to the GPU, but as the OSG passes a fully accumulated modelview matrix the precision is at least the best you can get. To best handle scenes with large extents one breaks the scene into regional tiles, each of which has a local origin and then a MatrixTransform above the tile subgraph to place it in it's final world coordinates. The OSG is used widely in the GIS market with many users handling whole earth database without precision issues. So... for you as long as you haven't deliberately compiled the OSG to use osg::Matrix and a osg::Matrixf then you'll be uses doubles. How you manage your scene graph and internal transforms will be the key, get it right as I suggest above then you shouldn't have issues. Robert. On 16 September 2013 17:48, Voelcker, Simon simon.voelc...@student.hpi.uni-potsdam.demailto: simon.voelc...@student.hpi.uni-potsdam.de wrote: Hi, I am using MatrixTransform nodes with matrices that contain quite large numbers. When I stack two of these transforms, I notice severe floating point inaccuracies in the scene, although I use double precision matrices to set up my transform nodes. Is it possible that OSG uses only single precision here (internally), and if so, how can I force it to use double precision? I know I could multiply my matrices directly and use a single MatrixTransform node, but I want to avoid this since it breaks my architecture. Thanks in advance, Simon ___ 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Possible bug in osg::State::applyShaderCompositionUniform
Hi rmilh, If there is some interest I could send all the stuff to the submissions at the end of this week Thanks for the sharing offer, I'm interested ! I think I've made some progress in the analysis of my problem, could you just test the following inside your experimental shader composition project ? (I would like to know if you have any side effects.) in osg/State.cpp : in the method : State::apply(const StateSet* dstate) comment the following line : _currentShaderCompositionUniformList.clear(); Thank you! Cheers, Aurelien -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=56446#56446 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
