Re: [osg-users] Question about osgShadow::ShadowedScene
Robert, All right, thanks a lot for your input! -- Alexandre Vaillancourt 2015-02-05 4:20 GMT-05:00 Robert Osfield robert.osfi...@gmail.com: HI Alexandre, It's a while since I touched the code, but I think with the ViewDependentShadowMap the casters also normally need to be a receiver as it'll self shadow, but there may also be the constraint that the actual rendering of objects is done via the shadow receivers pass. I vagually recall that there might have to been a lot of code and CPU cost associated with binning casters but not receivers. The bit you'd normally want to toggle off is the terrain being a shadow caster. Robert. On 4 February 2015 at 23:34, Alexandre Vaillancourt alexandre.vaillancourt.l...@gmail.com wrote: Thanks Robert, The shadow technique being used is ViewDependentShadowMap. I understand that trying to find where the issue comes from is like searching for a needle in a stack of hay. I'm trying to figure out myself how the system is being programmed as I'm not at all familiar with that aspect of OSG and the way we're using it regarding shaders/shadow, as I'm not the one who programmed it, so, don't worry, I'm not expecting exact reasons why stuff don't work. Checking the diff between 3.1.1 and 3.2.0 regarding shadows does not reveal anything that I would think of being a game changer, so this is why I'm confused. I'm under windows 8.1, visual studio 2013, GeForce GTX 780 Ti, driver version 347.09. In the mean time, I've been able to find a way to have the objects visible again by changing the node mask of the main node shadowed and the node mask of the nodes that were hidden. If anyone cares (that's not much of importance :P), here are the rough changes I did : with: unsigned int CAST_SHADOW_TRAVERSAL_MASK = 0x0002; unsigned int RECEIVE_SHADOW_TRAVERSAL_MASK = 0x0001; shadowSetting-setCastsShadowTraversalMask( CAST_SHADOW_TRAVERSAL_MASK ); shadowSetting-setReceivesShadowTraversalMask( RECEIVE_SHADOW_TRAVERSAL_MASK ); the ShadowedNode was set like this mEnvShadowedNode-setNodeMask( mEnvShadowedNode-getNodeMask() CAST_SHADOW_TRAVERSAL_MASK ); // Now set to 2... maybe nodes below were culled because of that, I could not figure it out. and the nodes in the ShadowedNode mobileObject-setNodeMask( CAST_SHADOW_TRAVERSAL_MASK ); // assume cast AND receive staticObject-setNodeMask( RECEIVE_SHADOW_TRAVERSAL_MASK ); // assume receive only So assuming that the CAST mask is no longer sufficient to have it receive as well, I removed the nodemask setting from the mEnvShadowedNode and the mobileObject (now using the default values of all 1) and I set the nodemask to the static object to something like: staticObject-setShadowMask( staticObject-getShadowMask() ! CAST_SHADOW_TRAVERSAL_MASK ); // This way we disable the shadow casting, while keeping the receiving and keeping the other parts of the mask. Now it displays as expected, but I'm not sure yet if there are other parts of the code that no longer behave appropriately. -- Alexandre Vaillancourt 2015-02-04 9:31 GMT-05:00 Robert Osfield robert.osfi...@gmail.com: HI Alexandre, On 4 February 2015 at 13:23, Alexandre Vaillancourt alexandre.vaillancourt.l...@gmail.com wrote: I've been told that objects that were casting shadow were automatically set to receive shadows as well, and that it was an implementation constraint that was not avoidable. Has this constraint been resolved, making it so that if we want an object to cast and receive shadows we have to set both mask explicitly (not only cast)? This will depend upon the ShadowTechnique being used. I don't recall the which ones have what constraints though, been a couple of years since I've worked on osgShadow. I'm trying to figure out issues that seemed to have appeared after from upgrading from 3.1.1 to 3.2.0 but I can't figure out what went wrong. (Some objects went missing from sight.) There are too few details for us to be able to guess what might be wrong. We don't know what shadow technique you are using, the data you are working with, what types of objects are going missing, what platform/hardware you are working on. 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 ___ 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] Offscreen rendering (e.g. pbuffer) and event processing
Hi Robert,
Thanks for spotting to typo. I hadn't noticed this before, and it hadn't
been reported either. I am fixing this and will get it checked in once my
clean build has completed.
My first major contribution to the OSG community ;-)
As for implementing an off screen viewer functionality using a pbuffer. I
haven't ever tried this on contemplated it. It should be possible to mimic
traditional window events by injecting them into the EventQueue, and you've
spotted passing on the appropriate window size will be required. I can't
provide any specific advice though as you are already further down the road
of trying something I haven't done yet :-)
OK, thanks for feedback.
For completeness, you'll also had to override
ViewerBase::checkEvents() if you want to leverage on viewer's
on-demand run scheme. Indeed, the Viewer and CompositeViewer
implementations only check for events from devices and windows. With
an off-screen viewer, you won't get any window, only views for which
you need to take care of setting a graphics contexts as I proposed
previously.
For a CompositeViewer-inherited off-screen viewer, checkEvents() looks like:
bool OffscreenViewer::checkEvents()
{
if (CompositeViewer::checkEvents())
return true;
Views views;
getViews(views);
// Check events from any views
for (Views::iterator vitr = views.begin();
vitr != views.end();
++vitr)
{
if ((*vitr)-getEventQueue()
!((*vitr)-getEventQueue()-empty()))
return true;
}
return false;
}
Hope this helps,
Émeric
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Question about bump mapping
HI Alexandre, There is no automagic thing to do what you are asking for. Why are you insisting on not adding an osg::Program here? Right now Robert is doing some work on a shader composition like approach, which might do the Program-injection automatically, but for now the preferred way to achieve what you are looking for would be the use of a visitor. The visitor in question would handle the nodes/Statesets with the properties you are describing (having 3 textures bound) and add an appropriate State / osg::Program. As for fixed function bump mapping there are some extensions, but they are really old and de-facto outdated. Shaders are the way to go here. Cheers Sebastian Hi All, I'm not too knowledgeable in the field of shaders and bump map, but lately I've had the task of fixing something related to it in our software. The issue is that some faces in our software are bumpmapped (I see the 3 different texture units used in the .osg file, as well as in the original .flt model), but the node itself does not seem to have an osg::Program (nor osg::VertexProgram or osg::FragmentProgram) part of its stateset's state attributes. The question is this: is it possible that there is a way that a chunk of code of OSG could set up bump mapping on a node by itsefl and NOT add an osg::Program to it? For instance, if it finds more than one texture units in the .osg file, it would find a way to add a shader to enable the bump maping..? I'm really wondering how that node could be bump mapped... Thanks -- Alexandre Vaillancourt ___ 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] Question about bump mapping
Robert, This appears to be exactly the situation. Is there a way to see where this feature is enabled and is there is a way to disable it? Thanks a lot! -- Alexandre Vaillancourt 2015-02-05 13:54 GMT-05:00 Robert Osfield robert.osfi...@gmail.com: Hi Alexandre, It sounds like might be talking about a pre-rendered shadow texture rather than a shadow map. The OSG by default handles multi-texturing by simply blending them - this is part of the OpenGL fixed function pipeline, so it's not a case of enabling shadow map, but simply blending a shadow texture on texture unit 1 with the base texture on texture unit 0. However, I'm just guessing, only you have the data and application in front of you. Robert. On 5 February 2015 at 18:28, Alexandre Vaillancourt alexandre.vaillancourt.l...@gmail.com wrote: Gentlemen, Thank you for your replies. It turns out that the node is not bumpmapped with a shader (I've used a nodevisitor to check if a program was loaded on a node's stateset and didn't see any). However, the node seems to be having a shadow map. In our model editor (Creator) there is an extended material on the node, and the material has, among other things a surface modifier that has shadow map on texture unit 1. Looking at the exported osg file, I don't see how this texture is used as shadow map (I would assume a shader could need to use it, but we're not adding any shader for now (I'm debugging)). Could it be that upon loading, the plugin for the .osg files assumes that texture unit 1 would be the shadow map and enables it right away or something like that? Thanks for your help! -- Alexandre Vaillancourt 2015-02-05 4:26 GMT-05:00 Robert Osfield robert.osfi...@gmail.com: Hi Alexandre, Does the scene graph code you have inherited contain use of osgFX::BumpMapping? osgFX::BumpingMapping It's a really ancient bit of the OSG so it's really how I'd tackle it these days but it provides the old style osg::VertexProgram and FragmentProgram. Have a look at the OpenSceneGraph/src/osgFX/BumpMapping.cpp so see what it's doing. Robert. On 4 February 2015 at 23:57, Alexandre Vaillancourt alexandre.vaillancourt.l...@gmail.com wrote: Hi All, I'm not too knowledgeable in the field of shaders and bump map, but lately I've had the task of fixing something related to it in our software. The issue is that some faces in our software are bumpmapped (I see the 3 different texture units used in the .osg file, as well as in the original .flt model), but the node itself does not seem to have an osg::Program (nor osg::VertexProgram or osg::FragmentProgram) part of its stateset's state attributes. The question is this: is it possible that there is a way that a chunk of code of OSG could set up bump mapping on a node by itsefl and NOT add an osg::Program to it? For instance, if it finds more than one texture units in the .osg file, it would find a way to add a shader to enable the bump maping..? I'm really wondering how that node could be bump mapped... Thanks -- Alexandre Vaillancourt ___ 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 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] Question about bump mapping
Hi Alexandre, if you want to disable the texture that is bound to unit 1, you have to write a NodeVisitor that will traverse the statesets of the nodes where the texture to unit 1 is set, and simply switch that attribute to StateAttribute::OFF Nick On Thu, Feb 5, 2015 at 8:03 PM, Alexandre Vaillancourt alexandre.vaillancourt.l...@gmail.com wrote: Robert, This appears to be exactly the situation. Is there a way to see where this feature is enabled and is there is a way to disable it? Thanks a lot! -- Alexandre Vaillancourt 2015-02-05 13:54 GMT-05:00 Robert Osfield robert.osfi...@gmail.com: Hi Alexandre, It sounds like might be talking about a pre-rendered shadow texture rather than a shadow map. The OSG by default handles multi-texturing by simply blending them - this is part of the OpenGL fixed function pipeline, so it's not a case of enabling shadow map, but simply blending a shadow texture on texture unit 1 with the base texture on texture unit 0. However, I'm just guessing, only you have the data and application in front of you. Robert. On 5 February 2015 at 18:28, Alexandre Vaillancourt alexandre.vaillancourt.l...@gmail.com wrote: Gentlemen, Thank you for your replies. It turns out that the node is not bumpmapped with a shader (I've used a nodevisitor to check if a program was loaded on a node's stateset and didn't see any). However, the node seems to be having a shadow map. In our model editor (Creator) there is an extended material on the node, and the material has, among other things a surface modifier that has shadow map on texture unit 1. Looking at the exported osg file, I don't see how this texture is used as shadow map (I would assume a shader could need to use it, but we're not adding any shader for now (I'm debugging)). Could it be that upon loading, the plugin for the .osg files assumes that texture unit 1 would be the shadow map and enables it right away or something like that? Thanks for your help! -- Alexandre Vaillancourt 2015-02-05 4:26 GMT-05:00 Robert Osfield robert.osfi...@gmail.com: Hi Alexandre, Does the scene graph code you have inherited contain use of osgFX::BumpMapping? osgFX::BumpingMapping It's a really ancient bit of the OSG so it's really how I'd tackle it these days but it provides the old style osg::VertexProgram and FragmentProgram. Have a look at the OpenSceneGraph/src/osgFX/BumpMapping.cpp so see what it's doing. Robert. On 4 February 2015 at 23:57, Alexandre Vaillancourt alexandre.vaillancourt.l...@gmail.com wrote: Hi All, I'm not too knowledgeable in the field of shaders and bump map, but lately I've had the task of fixing something related to it in our software. The issue is that some faces in our software are bumpmapped (I see the 3 different texture units used in the .osg file, as well as in the original .flt model), but the node itself does not seem to have an osg::Program (nor osg::VertexProgram or osg::FragmentProgram) part of its stateset's state attributes. The question is this: is it possible that there is a way that a chunk of code of OSG could set up bump mapping on a node by itsefl and NOT add an osg::Program to it? For instance, if it finds more than one texture units in the .osg file, it would find a way to add a shader to enable the bump maping..? I'm really wondering how that node could be bump mapped... Thanks -- Alexandre Vaillancourt ___ 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 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 -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Question about bump mapping
Hi Nick, Hi Alexandre, if you want to disable the texture that is bound to unit 1, you have to write a NodeVisitor that will traverse the statesets of the nodes where the texture to unit 1 is set, and simply switch that attribute to StateAttribute::OFF Nick I'm no expert but am I correct to assume that if I disable the texture unit like this, it will not be available to the shaders when I decide to add one to my node? Thanks for the input, it's greatly appreciated! -- Alexandre Vaillancourt On Thu, Feb 5, 2015 at 8:03 PM, Alexandre Vaillancourt alexandre.vaillancourt.l...@gmail.com wrote: Robert, This appears to be exactly the situation. Is there a way to see where this feature is enabled and is there is a way to disable it? Thanks a lot! -- Alexandre Vaillancourt 2015-02-05 13:54 GMT-05:00 Robert Osfield robert.osfi...@gmail.com: Hi Alexandre, It sounds like might be talking about a pre-rendered shadow texture rather than a shadow map. The OSG by default handles multi-texturing by simply blending them - this is part of the OpenGL fixed function pipeline, so it's not a case of enabling shadow map, but simply blending a shadow texture on texture unit 1 with the base texture on texture unit 0. However, I'm just guessing, only you have the data and application in front of you. Robert. On 5 February 2015 at 18:28, Alexandre Vaillancourt alexandre.vaillancourt.l...@gmail.com wrote: Gentlemen, Thank you for your replies. It turns out that the node is not bumpmapped with a shader (I've used a nodevisitor to check if a program was loaded on a node's stateset and didn't see any). However, the node seems to be having a shadow map. In our model editor (Creator) there is an extended material on the node, and the material has, among other things a surface modifier that has shadow map on texture unit 1. Looking at the exported osg file, I don't see how this texture is used as shadow map (I would assume a shader could need to use it, but we're not adding any shader for now (I'm debugging)). Could it be that upon loading, the plugin for the .osg files assumes that texture unit 1 would be the shadow map and enables it right away or something like that? Thanks for your help! -- Alexandre Vaillancourt 2015-02-05 4:26 GMT-05:00 Robert Osfield robert.osfi...@gmail.com: Hi Alexandre, Does the scene graph code you have inherited contain use of osgFX::BumpMapping? osgFX::BumpingMapping It's a really ancient bit of the OSG so it's really how I'd tackle it these days but it provides the old style osg::VertexProgram and FragmentProgram. Have a look at the OpenSceneGraph/src/osgFX/BumpMapping.cpp so see what it's doing. Robert. On 4 February 2015 at 23:57, Alexandre Vaillancourt alexandre.vaillancourt.l...@gmail.com wrote: Hi All, I'm not too knowledgeable in the field of shaders and bump map, but lately I've had the task of fixing something related to it in our software. The issue is that some faces in our software are bumpmapped (I see the 3 different texture units used in the .osg file, as well as in the original .flt model), but the node itself does not seem to have an osg::Program (nor osg::VertexProgram or osg::FragmentProgram) part of its stateset's state attributes. The question is this: is it possible that there is a way that a chunk of code of OSG could set up bump mapping on a node by itsefl and NOT add an osg::Program to it? For instance, if it finds more than one texture units in the .osg file, it would find a way to add a shader to enable the bump maping..? I'm really wondering how that node could be bump mapped... Thanks -- Alexandre Vaillancourt ___ 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 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 -- trajce nikolov nick ___ 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
Re: [osg-users] Question about bump mapping
You are correct. If you disable the texture for some unit it will not be available for your shaders. I am familiar a bit with Creator and OpenFlight, and with the OpenFlight loader. So you can have multitextures in your nodes, but it is up to the shaders to use them or not, and how to use them. After years I ended up with an xml file per model where I assign which textures goes where based on the shader logic, so it is not anymore depend on the modeller. I have code snippet for bump mapping I can share if you are interested, that suppose to work with any model along the mentioned xml file. Ping me on email if you want Nick On Thu, Feb 5, 2015 at 8:13 PM, Alexandre Vaillancourt alexandre.vaillancourt.l...@gmail.com wrote: Hi Nick, Hi Alexandre, if you want to disable the texture that is bound to unit 1, you have to write a NodeVisitor that will traverse the statesets of the nodes where the texture to unit 1 is set, and simply switch that attribute to StateAttribute::OFF Nick I'm no expert but am I correct to assume that if I disable the texture unit like this, it will not be available to the shaders when I decide to add one to my node? Thanks for the input, it's greatly appreciated! -- Alexandre Vaillancourt On Thu, Feb 5, 2015 at 8:03 PM, Alexandre Vaillancourt alexandre.vaillancourt.l...@gmail.com wrote: Robert, This appears to be exactly the situation. Is there a way to see where this feature is enabled and is there is a way to disable it? Thanks a lot! -- Alexandre Vaillancourt 2015-02-05 13:54 GMT-05:00 Robert Osfield robert.osfi...@gmail.com: Hi Alexandre, It sounds like might be talking about a pre-rendered shadow texture rather than a shadow map. The OSG by default handles multi-texturing by simply blending them - this is part of the OpenGL fixed function pipeline, so it's not a case of enabling shadow map, but simply blending a shadow texture on texture unit 1 with the base texture on texture unit 0. However, I'm just guessing, only you have the data and application in front of you. Robert. On 5 February 2015 at 18:28, Alexandre Vaillancourt alexandre.vaillancourt.l...@gmail.com wrote: Gentlemen, Thank you for your replies. It turns out that the node is not bumpmapped with a shader (I've used a nodevisitor to check if a program was loaded on a node's stateset and didn't see any). However, the node seems to be having a shadow map. In our model editor (Creator) there is an extended material on the node, and the material has, among other things a surface modifier that has shadow map on texture unit 1. Looking at the exported osg file, I don't see how this texture is used as shadow map (I would assume a shader could need to use it, but we're not adding any shader for now (I'm debugging)). Could it be that upon loading, the plugin for the .osg files assumes that texture unit 1 would be the shadow map and enables it right away or something like that? Thanks for your help! -- Alexandre Vaillancourt 2015-02-05 4:26 GMT-05:00 Robert Osfield robert.osfi...@gmail.com: Hi Alexandre, Does the scene graph code you have inherited contain use of osgFX::BumpMapping? osgFX::BumpingMapping It's a really ancient bit of the OSG so it's really how I'd tackle it these days but it provides the old style osg::VertexProgram and FragmentProgram. Have a look at the OpenSceneGraph/src/osgFX/BumpMapping.cpp so see what it's doing. Robert. On 4 February 2015 at 23:57, Alexandre Vaillancourt alexandre.vaillancourt.l...@gmail.com wrote: Hi All, I'm not too knowledgeable in the field of shaders and bump map, but lately I've had the task of fixing something related to it in our software. The issue is that some faces in our software are bumpmapped (I see the 3 different texture units used in the .osg file, as well as in the original .flt model), but the node itself does not seem to have an osg::Program (nor osg::VertexProgram or osg::FragmentProgram) part of its stateset's state attributes. The question is this: is it possible that there is a way that a chunk of code of OSG could set up bump mapping on a node by itsefl and NOT add an osg::Program to it? For instance, if it finds more than one texture units in the .osg file, it would find a way to add a shader to enable the bump maping..? I'm really wondering how that node could be bump mapped... Thanks -- Alexandre Vaillancourt ___ 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
[osg-users] osgEphemeris build on Linux
Hi All, this is not for this list, but I know some of you are using it. I downloaded the source from https://code.google.com/p/osgephemeris/source/checkout, run CMake (on Linux) and run make. or make all. It seam it is not set to be built on Linux even though CMake generated the Makefiles. What I am missing Thanks a bunch as allways p.s. the output is this ~/Dev/osgephemeris/osgEphemeris make all GNUmakefile:1: /makedefs: No such file or directory GNUmakefile:6: /makerules: No such file or directory make: *** No rule to make target '/makerules'. Stop. -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgEphemeris build on Linux
Trajce Nikolov NICK writes: ~/Dev/osgephemeris/osgEphemeris make all GNUmakefile:1: /makedefs: No such file or directory GNUmakefile:6: /makerules: No such file or directory ^^^ You are calling the provided GNUmakefile. Either change to an out-of-source build or call make with -f Makefile option. -- Alberto ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgEphemeris build on Linux
Seems like we rebuilt it a while ago and it needed a bunch of hacking but I can't recall what the deal was. On Thu, Feb 5, 2015 at 7:33 AM, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com wrote: Hi All, this is not for this list, but I know some of you are using it. I downloaded the source from https://code.google.com/p/osgephemeris/source/checkout, run CMake (on Linux) and run make. or make all. It seam it is not set to be built on Linux even though CMake generated the Makefiles. What I am missing Thanks a bunch as allways p.s. the output is this ~/Dev/osgephemeris/osgEphemeris make all GNUmakefile:1: /makedefs: No such file or directory GNUmakefile:6: /makerules: No such file or directory make: *** No rule to make target '/makerules'. Stop. -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- 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] osgEphemeris build on Linux
Thanks Chris, Alberto. Alberto, yeah, that did the build. Thanks again Nick On Thu, Feb 5, 2015 at 4:08 PM, Chris Hanson xe...@alphapixel.com wrote: Seems like we rebuilt it a while ago and it needed a bunch of hacking but I can't recall what the deal was. On Thu, Feb 5, 2015 at 7:33 AM, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com wrote: Hi All, this is not for this list, but I know some of you are using it. I downloaded the source from https://code.google.com/p/osgephemeris/source/checkout, run CMake (on Linux) and run make. or make all. It seam it is not set to be built on Linux even though CMake generated the Makefiles. What I am missing Thanks a bunch as allways p.s. the output is this ~/Dev/osgephemeris/osgEphemeris make all GNUmakefile:1: /makedefs: No such file or directory GNUmakefile:6: /makerules: No such file or directory make: *** No rule to make target '/makerules'. Stop. -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- 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 -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Bug in OSG? getMatrix() and setByMatrix() is not enough to transrer camera state
Hi Dan, It was never my intention that the osgGA::CameraManipualtor would become THE way to manage cameras in OSG users applications, just a convenient tool for most OSG examples and basic OSG applications. They have kinda taken on a bit of life of their own, beyond what really the merit they have. So... rather than trying to make a square peg fit a round hole and try to make the existing CameraManipualators fit your needs I'd suggest you consider what you needs are for your own application. How do you want to manage camera control and interaction? If the osgGA camera manipulators don't fit the bill then don't feel uneasy about just rolling your own camera management to do things exactly how you require of them. Cheers, Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Bug in OSG? getMatrix() and setByMatrix() is not enough to transrer camera state
For now, existing manipulators does fit. Well... almost :) I have an idea to write my own, but for quick-n-dirty concept existing will be ok. Cheers, Dan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=62623#62623 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Bug in OSG? getMatrix() and setByMatrix() is not enough to transrer camera state
Thanx, Robert! Get it. I suppose, the most convenient way then - is to subclass KeySwitchMatrixManipulator and override handle() method. My app knows, what manipulators will be added to KeySwitcher, and will perform all required additional settings during switch. Cheers, Dan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=62621#62621 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgEphemeris build on Linux
Thanks Chris. I know someone has hacked it to work nice. I hope these people can share it :-) . maybe update the base code on the repo as well Nick On Thu, Feb 5, 2015 at 5:29 PM, Chris Hanson xe...@alphapixel.com wrote: I haven't actually used it in about 2 years. I switched to using osgEarth for most stuff now, and it includes its own sky, though it doesn't have the same featureset as osgEphemeris. On Thu, Feb 5, 2015 at 9:25 AM, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com wrote: Me again, on this topic. I hope noone will be mad for using this list for 3rd party software. Alberto, Chris, did you made it work? For some reason I am setting the skyDomeCenter to be the eye point and it doesnt work. Also, setMoveWithEyePoint seam to not have an effect. Any hints? Thanks again Nick On Thu, Feb 5, 2015 at 4:12 PM, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com wrote: Thanks Chris, Alberto. Alberto, yeah, that did the build. Thanks again Nick On Thu, Feb 5, 2015 at 4:08 PM, Chris Hanson xe...@alphapixel.com wrote: Seems like we rebuilt it a while ago and it needed a bunch of hacking but I can't recall what the deal was. On Thu, Feb 5, 2015 at 7:33 AM, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com wrote: Hi All, this is not for this list, but I know some of you are using it. I downloaded the source from https://code.google.com/p/osgephemeris/source/checkout, run CMake (on Linux) and run make. or make all. It seam it is not set to be built on Linux even though CMake generated the Makefiles. What I am missing Thanks a bunch as allways p.s. the output is this ~/Dev/osgephemeris/osgEphemeris make all GNUmakefile:1: /makedefs: No such file or directory GNUmakefile:6: /makerules: No such file or directory make: *** No rule to make target '/makerules'. Stop. -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- 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 -- trajce nikolov nick -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- 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 -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osgEphemeris build on Linux
I haven't actually used it in about 2 years. I switched to using osgEarth for most stuff now, and it includes its own sky, though it doesn't have the same featureset as osgEphemeris. On Thu, Feb 5, 2015 at 9:25 AM, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com wrote: Me again, on this topic. I hope noone will be mad for using this list for 3rd party software. Alberto, Chris, did you made it work? For some reason I am setting the skyDomeCenter to be the eye point and it doesnt work. Also, setMoveWithEyePoint seam to not have an effect. Any hints? Thanks again Nick On Thu, Feb 5, 2015 at 4:12 PM, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com wrote: Thanks Chris, Alberto. Alberto, yeah, that did the build. Thanks again Nick On Thu, Feb 5, 2015 at 4:08 PM, Chris Hanson xe...@alphapixel.com wrote: Seems like we rebuilt it a while ago and it needed a bunch of hacking but I can't recall what the deal was. On Thu, Feb 5, 2015 at 7:33 AM, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com wrote: Hi All, this is not for this list, but I know some of you are using it. I downloaded the source from https://code.google.com/p/osgephemeris/source/checkout, run CMake (on Linux) and run make. or make all. It seam it is not set to be built on Linux even though CMake generated the Makefiles. What I am missing Thanks a bunch as allways p.s. the output is this ~/Dev/osgephemeris/osgEphemeris make all GNUmakefile:1: /makedefs: No such file or directory GNUmakefile:6: /makerules: No such file or directory make: *** No rule to make target '/makerules'. Stop. -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- 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 -- trajce nikolov nick -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- 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] osgEphemeris build on Linux
Me again, on this topic. I hope noone will be mad for using this list for 3rd party software. Alberto, Chris, did you made it work? For some reason I am setting the skyDomeCenter to be the eye point and it doesnt work. Also, setMoveWithEyePoint seam to not have an effect. Any hints? Thanks again Nick On Thu, Feb 5, 2015 at 4:12 PM, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com wrote: Thanks Chris, Alberto. Alberto, yeah, that did the build. Thanks again Nick On Thu, Feb 5, 2015 at 4:08 PM, Chris Hanson xe...@alphapixel.com wrote: Seems like we rebuilt it a while ago and it needed a bunch of hacking but I can't recall what the deal was. On Thu, Feb 5, 2015 at 7:33 AM, Trajce Nikolov NICK trajce.nikolov.n...@gmail.com wrote: Hi All, this is not for this list, but I know some of you are using it. I downloaded the source from https://code.google.com/p/osgephemeris/source/checkout, run CMake (on Linux) and run make. or make all. It seam it is not set to be built on Linux even though CMake generated the Makefiles. What I am missing Thanks a bunch as allways p.s. the output is this ~/Dev/osgephemeris/osgEphemeris make all GNUmakefile:1: /makedefs: No such file or directory GNUmakefile:6: /makerules: No such file or directory make: *** No rule to make target '/makerules'. Stop. -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- 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 -- trajce nikolov nick -- trajce nikolov nick ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to save camera position between manipulators switching?
Hi Dan, There is limit on how well you can two sync two very different camera manipulators as a straight forward matrix isn't always sufficient. Robert. On 5 February 2015 at 11:35, Dan Shebounin danil.shebou...@gmail.com wrote: I think, I have found a bug in OSG KeySwitchMatrixManipulator. I have checked example, provided with OSG, it have same troubles, when I switch between Trackball and NodeTracker manipulators. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=62608#62608 ___ 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] Bug in OSG? getMatrix() and setByMatrix() is not enough to transrer camera state
Hi Dan, The getMatrix/setByMatrix methods in the CamaraManipulators might be convinient and sufficient for switching between some manipulators but there are too many settings in some of the manipulators to be able to set it purely from a 4x4 matrix so the manipulator has to make a guess at what might be intended. For instance a manipulator that uses a look distance, centre of rotation and look vector direction isn't able to compute the look distance from a 4x4 matrix, there simply is too my unknowns for the constraints available. So it's not a bug but a mathematical limitation. Robert. On 5 February 2015 at 12:00, Dan Shebounin danil.shebou...@gmail.com wrote: I have discovered, that when working with manipulators, it is not enough to call getMatrix() and setByMatrix(), when switching between manipulators, say, with KeySwitchManipulator. You can try it: run osgsimulation example and try to switch between manipulators with '1' and '2' keys. The camera become crazy. I do not know the source code well, but suppose, that some mean should be created, that notifies manipulator, when it is switched in and out. Cheers, Dan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=62609#62609 ___ 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] Question about osgShadow::ShadowedScene
HI Alexandre, It's a while since I touched the code, but I think with the ViewDependentShadowMap the casters also normally need to be a receiver as it'll self shadow, but there may also be the constraint that the actual rendering of objects is done via the shadow receivers pass. I vagually recall that there might have to been a lot of code and CPU cost associated with binning casters but not receivers. The bit you'd normally want to toggle off is the terrain being a shadow caster. Robert. On 4 February 2015 at 23:34, Alexandre Vaillancourt alexandre.vaillancourt.l...@gmail.com wrote: Thanks Robert, The shadow technique being used is ViewDependentShadowMap. I understand that trying to find where the issue comes from is like searching for a needle in a stack of hay. I'm trying to figure out myself how the system is being programmed as I'm not at all familiar with that aspect of OSG and the way we're using it regarding shaders/shadow, as I'm not the one who programmed it, so, don't worry, I'm not expecting exact reasons why stuff don't work. Checking the diff between 3.1.1 and 3.2.0 regarding shadows does not reveal anything that I would think of being a game changer, so this is why I'm confused. I'm under windows 8.1, visual studio 2013, GeForce GTX 780 Ti, driver version 347.09. In the mean time, I've been able to find a way to have the objects visible again by changing the node mask of the main node shadowed and the node mask of the nodes that were hidden. If anyone cares (that's not much of importance :P), here are the rough changes I did : with: unsigned int CAST_SHADOW_TRAVERSAL_MASK = 0x0002; unsigned int RECEIVE_SHADOW_TRAVERSAL_MASK = 0x0001; shadowSetting-setCastsShadowTraversalMask( CAST_SHADOW_TRAVERSAL_MASK ); shadowSetting-setReceivesShadowTraversalMask( RECEIVE_SHADOW_TRAVERSAL_MASK ); the ShadowedNode was set like this mEnvShadowedNode-setNodeMask( mEnvShadowedNode-getNodeMask() CAST_SHADOW_TRAVERSAL_MASK ); // Now set to 2... maybe nodes below were culled because of that, I could not figure it out. and the nodes in the ShadowedNode mobileObject-setNodeMask( CAST_SHADOW_TRAVERSAL_MASK ); // assume cast AND receive staticObject-setNodeMask( RECEIVE_SHADOW_TRAVERSAL_MASK ); // assume receive only So assuming that the CAST mask is no longer sufficient to have it receive as well, I removed the nodemask setting from the mEnvShadowedNode and the mobileObject (now using the default values of all 1) and I set the nodemask to the static object to something like: staticObject-setShadowMask( staticObject-getShadowMask() ! CAST_SHADOW_TRAVERSAL_MASK ); // This way we disable the shadow casting, while keeping the receiving and keeping the other parts of the mask. Now it displays as expected, but I'm not sure yet if there are other parts of the code that no longer behave appropriately. -- Alexandre Vaillancourt 2015-02-04 9:31 GMT-05:00 Robert Osfield robert.osfi...@gmail.com: HI Alexandre, On 4 February 2015 at 13:23, Alexandre Vaillancourt alexandre.vaillancourt.l...@gmail.com wrote: I've been told that objects that were casting shadow were automatically set to receive shadows as well, and that it was an implementation constraint that was not avoidable. Has this constraint been resolved, making it so that if we want an object to cast and receive shadows we have to set both mask explicitly (not only cast)? This will depend upon the ShadowTechnique being used. I don't recall the which ones have what constraints though, been a couple of years since I've worked on osgShadow. I'm trying to figure out issues that seemed to have appeared after from upgrading from 3.1.1 to 3.2.0 but I can't figure out what went wrong. (Some objects went missing from sight.) There are too few details for us to be able to guess what might be wrong. We don't know what shadow technique you are using, the data you are working with, what types of objects are going missing, what platform/hardware you are working on. 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Node/Object Serialization
Hi Jeremy, On 5 February 2015 at 01:17, Jeremy jswig...@gmail.com wrote: Robert. Are there plans to expose more information through this interface? Currently It appears that it is largely exposing the properties that are serialized, and I was also hoping to expose read only access to informational data about the various object types as well. I extended the serializers interface to handle cases where there is only a get, and added a few wrappers to expose these methods but I haven't done it for the whole OSG, I only did it for the bits that I needed on the scripting work. Wrappers aren't free to implement or in memory cost so implementing on a need basis helps keep the work and costs down. If there are specific things that aren't exposed then let me know or add them yourself. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Bug in OSG? getMatrix() and setByMatrix() is not enough to transrer camera state
I have discovered, that when working with manipulators, it is not enough to call getMatrix() and setByMatrix(), when switching between manipulators, say, with KeySwitchManipulator. You can try it: run osgsimulation example and try to switch between manipulators with '1' and '2' keys. The camera become crazy. I do not know the source code well, but suppose, that some mean should be created, that notifies manipulator, when it is switched in and out. Cheers, Dan -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=62609#62609 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Question about bump mapping
Hi Alexandre, It sounds like might be talking about a pre-rendered shadow texture rather than a shadow map. The OSG by default handles multi-texturing by simply blending them - this is part of the OpenGL fixed function pipeline, so it's not a case of enabling shadow map, but simply blending a shadow texture on texture unit 1 with the base texture on texture unit 0. However, I'm just guessing, only you have the data and application in front of you. Robert. On 5 February 2015 at 18:28, Alexandre Vaillancourt alexandre.vaillancourt.l...@gmail.com wrote: Gentlemen, Thank you for your replies. It turns out that the node is not bumpmapped with a shader (I've used a nodevisitor to check if a program was loaded on a node's stateset and didn't see any). However, the node seems to be having a shadow map. In our model editor (Creator) there is an extended material on the node, and the material has, among other things a surface modifier that has shadow map on texture unit 1. Looking at the exported osg file, I don't see how this texture is used as shadow map (I would assume a shader could need to use it, but we're not adding any shader for now (I'm debugging)). Could it be that upon loading, the plugin for the .osg files assumes that texture unit 1 would be the shadow map and enables it right away or something like that? Thanks for your help! -- Alexandre Vaillancourt 2015-02-05 4:26 GMT-05:00 Robert Osfield robert.osfi...@gmail.com: Hi Alexandre, Does the scene graph code you have inherited contain use of osgFX::BumpMapping? osgFX::BumpingMapping It's a really ancient bit of the OSG so it's really how I'd tackle it these days but it provides the old style osg::VertexProgram and FragmentProgram. Have a look at the OpenSceneGraph/src/osgFX/BumpMapping.cpp so see what it's doing. Robert. On 4 February 2015 at 23:57, Alexandre Vaillancourt alexandre.vaillancourt.l...@gmail.com wrote: Hi All, I'm not too knowledgeable in the field of shaders and bump map, but lately I've had the task of fixing something related to it in our software. The issue is that some faces in our software are bumpmapped (I see the 3 different texture units used in the .osg file, as well as in the original .flt model), but the node itself does not seem to have an osg::Program (nor osg::VertexProgram or osg::FragmentProgram) part of its stateset's state attributes. The question is this: is it possible that there is a way that a chunk of code of OSG could set up bump mapping on a node by itsefl and NOT add an osg::Program to it? For instance, if it finds more than one texture units in the .osg file, it would find a way to add a shader to enable the bump maping..? I'm really wondering how that node could be bump mapped... Thanks -- Alexandre Vaillancourt ___ 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 mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Question about bump mapping
Hi Alexandre, Does the scene graph code you have inherited contain use of osgFX::BumpMapping? osgFX::BumpingMapping It's a really ancient bit of the OSG so it's really how I'd tackle it these days but it provides the old style osg::VertexProgram and FragmentProgram. Have a look at the OpenSceneGraph/src/osgFX/BumpMapping.cpp so see what it's doing. Robert. On 4 February 2015 at 23:57, Alexandre Vaillancourt alexandre.vaillancourt.l...@gmail.com wrote: Hi All, I'm not too knowledgeable in the field of shaders and bump map, but lately I've had the task of fixing something related to it in our software. The issue is that some faces in our software are bumpmapped (I see the 3 different texture units used in the .osg file, as well as in the original .flt model), but the node itself does not seem to have an osg::Program (nor osg::VertexProgram or osg::FragmentProgram) part of its stateset's state attributes. The question is this: is it possible that there is a way that a chunk of code of OSG could set up bump mapping on a node by itsefl and NOT add an osg::Program to it? For instance, if it finds more than one texture units in the .osg file, it would find a way to add a shader to enable the bump maping..? I'm really wondering how that node could be bump mapped... Thanks -- Alexandre Vaillancourt ___ 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] How to save camera position between manipulators switching?
I think, I have found a bug in OSG KeySwitchMatrixManipulator. I have checked example, provided with OSG, it have same troubles, when I switch between Trackball and NodeTracker manipulators. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=62608#62608 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Question about bump mapping
Gentlemen, Thank you for your replies. It turns out that the node is not bumpmapped with a shader (I've used a nodevisitor to check if a program was loaded on a node's stateset and didn't see any). However, the node seems to be having a shadow map. In our model editor (Creator) there is an extended material on the node, and the material has, among other things a surface modifier that has shadow map on texture unit 1. Looking at the exported osg file, I don't see how this texture is used as shadow map (I would assume a shader could need to use it, but we're not adding any shader for now (I'm debugging)). Could it be that upon loading, the plugin for the .osg files assumes that texture unit 1 would be the shadow map and enables it right away or something like that? Thanks for your help! -- Alexandre Vaillancourt 2015-02-05 4:26 GMT-05:00 Robert Osfield robert.osfi...@gmail.com: Hi Alexandre, Does the scene graph code you have inherited contain use of osgFX::BumpMapping? osgFX::BumpingMapping It's a really ancient bit of the OSG so it's really how I'd tackle it these days but it provides the old style osg::VertexProgram and FragmentProgram. Have a look at the OpenSceneGraph/src/osgFX/BumpMapping.cpp so see what it's doing. Robert. On 4 February 2015 at 23:57, Alexandre Vaillancourt alexandre.vaillancourt.l...@gmail.com wrote: Hi All, I'm not too knowledgeable in the field of shaders and bump map, but lately I've had the task of fixing something related to it in our software. The issue is that some faces in our software are bumpmapped (I see the 3 different texture units used in the .osg file, as well as in the original .flt model), but the node itself does not seem to have an osg::Program (nor osg::VertexProgram or osg::FragmentProgram) part of its stateset's state attributes. The question is this: is it possible that there is a way that a chunk of code of OSG could set up bump mapping on a node by itsefl and NOT add an osg::Program to it? For instance, if it finds more than one texture units in the .osg file, it would find a way to add a shader to enable the bump maping..? I'm really wondering how that node could be bump mapped... Thanks -- Alexandre Vaillancourt ___ 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
