Re: [osg-users] Oldie, but goodie... Aero themes and OpenGL/MFC

[Andrew Cunningham]

I am using a double-buffered window as per the OSG MFC example. 
traits->doubleBuffer = true;  The MFC example shows a nice overlay HUD of 
rendering statistics.

This just seems such a typical 3D UI interaction - to show a rectangular area 
on the screen under mouse control for selection or zooming that it surprises me 
there is not a canned solution. I suppose I could grab the pixel buffer and 
make that a static background while I draw the rectangle. It is crucial the 
full 3D scene be not continuously redrawn while drawing this zoom box.

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=56474#56474





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Olide, but goodie... Aero themes and OpenGL/MFC

[Chris Hanson]

I think in order to do XORed drawing, you'd need to be in a single-buffered
situation. Are you?

If you are, you should be able to setup a HUD-like transform and draw using
pixel coordinates.


On Tue, Sep 24, 2013 at 1:57 PM, Andrew Cunningham  wrote:

> Hi,
> This is an old one, that seemingly no-one has a solution for
>
> I am having problems on W7/W8 when "aero" is active in our MFC/OGL(OSG)
> based CAE style application.
>
> 1) MFC CSplitterWnd resizing leaves 'window garbage' behind
> 2) How to draw an rubber-banding zoom box (using XOR operations) on the
> OpenGL window - we were using GDI, of course this is a no-no now.
>
> We have to advise the user to revert to Windows 7/8 basic theme. Of course
> they never read the release notes, so support gets the call
>
> I was wondering how to resolve 2) using OSG. I suppose it's a HUD type
> problem. I want to draw over the existing rendered scene without requiring
> the underlying scene to be re-rendered. It quite simple to do a XOR'd
> rectangle using gl* calls in screen coordinates, but I'm at a loss how to
> integrate that into an OSG scene.
>
> Thank you!
>
> Cheers,
> Andrew
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=56471#56471
>
>
>
>
>
> ___
> 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  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] Proposal for uniforms applied from within a StateAttribute

[Aurelien Albert]

Hi Robert,

No problem, script support in OSG will be great !

I'll try to make an optimized implementation and submit it.

Thank you!

Cheers,
Aurelien

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=56472#56472





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Olide, but goodie... Aero themes and OpenGL/MFC

[Andrew Cunningham]

Hi,
This is an old one, that seemingly no-one has a solution for

I am having problems on W7/W8 when "aero" is active in our MFC/OGL(OSG) based 
CAE style application.

1) MFC CSplitterWnd resizing leaves 'window garbage' behind
2) How to draw an rubber-banding zoom box (using XOR operations) on the OpenGL 
window - we were using GDI, of course this is a no-no now.

We have to advise the user to revert to Windows 7/8 basic theme. Of course they 
never read the release notes, so support gets the call

I was wondering how to resolve 2) using OSG. I suppose it's a HUD type problem. 
I want to draw over the existing rendered scene without requiring the 
underlying scene to be re-rendered. It quite simple to do a XOR'd rectangle 
using gl* calls in screen coordinates, but I'm at a loss how to integrate that 
into an OSG scene.

Thank you!

Cheers,
Andrew

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=56471#56471





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] osgarchive and PagedLOD

[Sebastian Messerschmidt]

Hi folks,

I found some problem which I'm not able to solve easily.
I try to pack a large number of files in to an osga archive. This works 
pretty well, but it will fail if I try to archive nodes which contain 
PagedLODs.
They get loaded by the DatabasePager, which is not what I want, as the 
paged nodes will be added to the archive as well.
First of all this doubles the amount of data in the archive, as all 
PagedLOD get loaded and the resulting graph is being saved to the archive.
Secondly this will applications which try to load the archive, as the 
saved paged nodes will contain the source path in the _databasePath member.
I didn't check but I guess same is true for images. (my original files 
contain no paths, as they files are all in one directory)
Is there a way to prevent osgDB::readNode from resolving PagedLODs 
without adding a custom NodeLoadCallback?


Also: will loading a file which is referenced inside the archive work 
without additional tricks?


cheers
Sebastian
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Proposal for uniforms applied from within a StateAttribute

[Robert Osfield]

HI Aurelien,

I'm currently deep into work on OSG scripting support and it's a complex
enough topic that I don't have any spare brain cells for thinking about
other topics, let alone once that are also complex.  I expect to start
crawling out from the most complex phase of my current work next week so
should be able to dive into other topics then.

Thanks for your patience,
Robert.


On 24 September 2013 15:56, Aurelien Albert wrote:

> Hi,
>
> As discuted multiple times with Robert and others, sometimes it's really
> usefull to have a StateAttribute which also provide its own uniforms. For
> example, I use it in a modified osg::Material class to apply maerial values
> as uniform or to handle specific "ObjectData" StateAttribute classes which
> apply one or several uniform.
>
> By now, I do this using state.applyShaderCompositionUniform(_myUniform);
> from the "apply" StateAttribute method.
>
> It perfectly fit my needs, but I discovered a bug : these uniforms are not
> part of the State uniform map, so they are not applied to osg::Programs
> below it.
>
> Here is a proposal to handle this properly :
>
> 1/ add a "getBuiltInUniformList()" in the StateAttribute class
> => this method is const, inline and should be very fast, and return an
> empty list by default
>
> 2/ Each StateAttribute subclass can populate this list with desired
> uniforms, and change their values when needed
>
> 3/ handle this list in osg::State when attributes are applied
> => something is really done only if the list is not empty, which should
> not happen really often
>
> 4/ Maybe add a compilation DEFINE to use this feature or not (very
> usefull, but very application-specific or if you want to handle standard
> osg StateAttributes in OpenGL > 3.2)
> 5/ Or add a test, like already done for the "_shaderCompositionEnabled"
> flag
>
>
> Here is a piece of code to show what I have in mind (code not tested...) :
>
>
> Code:
> /
> // New typedef :
> /
> typedef std::map< std::string,ref_ptr< Uniform > > BuiltInUniformList;
>
> /
> // New method on StateAttribute :
> /
> inline const BuiltInUniformList& getBuiltInUniformList() const
> {
> return _builtInUniformList;
> }
>
> /
> // Modified method on State :
> /
> inline void State::pushAttributeList(AttributeMap& attributeMap,const
> StateSet::AttributeList& attributeList)
> {
> for(StateSet::AttributeList::const_iterator aitr=attributeList.begin();
> aitr!=attributeList.end();
> ++aitr)
> {
> // get the attribute stack for incoming type {aitr->first}.
> AttributeStack& as = attributeMap[aitr->first];
> if (as.attributeVec.empty())
> {
> // first pair so simply push incoming pair to back.
> as.attributeVec.push_back(
>
> AttributePair(aitr->second.first.get(),aitr->second.second));
>
> // Push built-in uniforms from the StateAttribute
> pushUniformList(_uniformMap,
> aitr->second.first->getBuiltInUniformList(), aitr->second.second);
> }
> else if ((as.attributeVec.back().second &
> StateAttribute::OVERRIDE) && !(aitr->second.second &
> StateAttribute::PROTECTED)) // check the existing override flag
> {
> // push existing back since override keeps the previous value.
> as.attributeVec.push_back(as.attributeVec.back());
>
> // Push built-in uniforms from existing back since
> override keeps the previous value.
> pushUniformList(_uniformMap,
> as.attributeVec.back().first->getBuiltInUniformList(),
> as.attributeVec.back().second);
> }
> else
> {
> // no override on so simply push incoming pair to back.
> as.attributeVec.push_back(
>
> AttributePair(aitr->second.first.get(),aitr->second.second));
>
> // No override on so simply push incoming built-in uniforms to
> back.
> pushUniformList(_uniformMap,
> aitr->second.first->getBuiltInUniformList(), aitr->second.second);
> }
> as.changed = true;
> }
> }
>
> /
> // New method on State :
> /
> inline void State::pushBuiltInUniformList(UniformMap& uniformMap,const
> StateSet::BuiltInUniformList& uniformList, StateAttribute::OverrideValue
> value)
> {
> for(StateSet::BuiltInUniformList::const_iterator
> aitr=uniformList.begin();
> aitr!=uniformList.end();
> ++aitr)
> {
> // get the uniform stack for incoming uniform {aitr->first}.
> UniformStack& us = uniformMap[aitr->first];
> if (us.uniformVec.empty())
> {
> // first pair so simply push incoming pair to back.
> us.uniformVec.push_back(
> UniformStack::UniformPair(aitr->get(),value));
> }
> else if ((us.uniformVec.back().second & StateAttribute::OVERRIDE)
> && !(value & StateAttribute::PROTECTED)) // check the existing override

[osg-users] Proposal for uniforms applied from within a StateAttribute

[Aurelien Albert]

Hi, 

As discuted multiple times with Robert and others, sometimes it's really 
usefull to have a StateAttribute which also provide its own uniforms. For 
example, I use it in a modified osg::Material class to apply maerial values as 
uniform or to handle specific "ObjectData" StateAttribute classes which apply 
one or several uniform.

By now, I do this using state.applyShaderCompositionUniform(_myUniform); from 
the "apply" StateAttribute method.

It perfectly fit my needs, but I discovered a bug : these uniforms are not part 
of the State uniform map, so they are not applied to osg::Programs below it. 

Here is a proposal to handle this properly :

1/ add a "getBuiltInUniformList()" in the StateAttribute class
=> this method is const, inline and should be very fast, and return an empty 
list by default

2/ Each StateAttribute subclass can populate this list with desired uniforms, 
and change their values when needed

3/ handle this list in osg::State when attributes are applied
=> something is really done only if the list is not empty, which should not 
happen really often

4/ Maybe add a compilation DEFINE to use this feature or not (very usefull, but 
very application-specific or if you want to handle standard osg StateAttributes 
in OpenGL > 3.2)
5/ Or add a test, like already done for the "_shaderCompositionEnabled" flag


Here is a piece of code to show what I have in mind (code not tested...) :


Code:
/
// New typedef :
/
typedef std::map< std::string,ref_ptr< Uniform > > BuiltInUniformList;

/
// New method on StateAttribute :
/
inline const BuiltInUniformList& getBuiltInUniformList() const
{
return _builtInUniformList;
}

/
// Modified method on State :
/
inline void State::pushAttributeList(AttributeMap& attributeMap,const 
StateSet::AttributeList& attributeList)
{
for(StateSet::AttributeList::const_iterator aitr=attributeList.begin();
aitr!=attributeList.end();
++aitr)
{
// get the attribute stack for incoming type {aitr->first}.
AttributeStack& as = attributeMap[aitr->first];
if (as.attributeVec.empty())
{
// first pair so simply push incoming pair to back.
as.attributeVec.push_back(
AttributePair(aitr->second.first.get(),aitr->second.second));

// Push built-in uniforms from the StateAttribute
pushUniformList(_uniformMap, 
aitr->second.first->getBuiltInUniformList(), aitr->second.second);
}
else if ((as.attributeVec.back().second & StateAttribute::OVERRIDE) && 
!(aitr->second.second & StateAttribute::PROTECTED)) // check the existing 
override flag
{
// push existing back since override keeps the previous value.
as.attributeVec.push_back(as.attributeVec.back());

// Push built-in uniforms from existing back since 
override keeps the previous value.
pushUniformList(_uniformMap, 
as.attributeVec.back().first->getBuiltInUniformList(), 
as.attributeVec.back().second);
}
else
{
// no override on so simply push incoming pair to back.
as.attributeVec.push_back(
AttributePair(aitr->second.first.get(),aitr->second.second));

// No override on so simply push incoming built-in uniforms to back.
pushUniformList(_uniformMap, 
aitr->second.first->getBuiltInUniformList(), aitr->second.second);
}
as.changed = true;
}
}

/
// New method on State :
/
inline void State::pushBuiltInUniformList(UniformMap& uniformMap,const 
StateSet::BuiltInUniformList& uniformList, StateAttribute::OverrideValue value)
{
for(StateSet::BuiltInUniformList::const_iterator aitr=uniformList.begin();
aitr!=uniformList.end();
++aitr)
{
// get the uniform stack for incoming uniform {aitr->first}.
UniformStack& us = uniformMap[aitr->first];
if (us.uniformVec.empty())
{
// first pair so simply push incoming pair to back.
us.uniformVec.push_back(
UniformStack::UniformPair(aitr->get(),value));
}
else if ((us.uniformVec.back().second & StateAttribute::OVERRIDE) && 
!(value & StateAttribute::PROTECTED)) // check the existing override flag
{
// push existing back since override keeps the previous value.
us.uniformVec.push_back(us.uniformVec.back());
}
else
{
// no override on so simply push incoming pair to back.
us.uniformVec.push_back(
UniformStack::UniformPair(aitr->get(),value));
}
}
}

/
// Modified method on State :
/
inline void State::popAttributeList(AttributeMap& attributeMap,const 
StateSet::AttributeList& attributeList)
{
for(StateSet::AttributeList::const_iterato

Re: [osg-users] Possible bug in osg::State::applyShaderCompositionUniform

[Aurelien Albert]

For example, push uniforms with ambient, diffuse, specular and shininess values 
from osg::Material, for OpenGL 3.3

It could also be used for application-specific StateAttribute classes, for 
example an "ObjectData" StateAttribute which push several uniforms on the state.

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=56465#56465





___
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

[Robert Milharcic]

On 24.9.2013 14:40, Aurelien Albert wrote:

Yes, and I think this is what I need :

- a standard uniform list, which contains uniforms setted from regular 
osg::Uniform instances
- a "comes-from-stateAttribute" uniform list, in the same way there is "associated 
modes" with some StateAttributes

In my opinion, theses uniforms are not really linked to the ShaderComposition system, but 
complementary : sometimes you just want to push some 
"StateAttribute-associated" uniforms in the state.


Hi,

I think I now understand what you are trying to do, but I don't 
understand to what purpose? What would be the benefit of having 
StateAttribute associated uniforms pushed into state?


Robert Milharcic

___
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

[Aurelien Albert]

Hi,


> If you do change the list to stack so you can push/pop uniforms you will end 
> up redoing standard uniform handling but this time with a parallel uniform 
> list.


Yes, and I think this is what I need :

- a standard uniform list, which contains uniforms setted from regular 
osg::Uniform instances
- a "comes-from-stateAttribute" uniform list, in the same way there is 
"associated modes" with some StateAttributes

In my opinion, theses uniforms are not really linked to the ShaderComposition 
system, but complementary : sometimes you just want to push some 
"StateAttribute-associated" uniforms in the state.

Cheers,
Aurelien

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=56461#56461





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Trying to add normal mapping shader to osgShadow::SoftShadowMap

[michael kapelko]

Hi.

I'm on my way to add normal mapping to SoftShadowMap.
As far as I understood, it only uses fragment shader.
I started by adding a very simple vertex shader into
SoftShadowMap::createShaders().
That's what createShaders() looks like by default:
https://bitbucket.org/openscenegraph/osg/src/default/src/osgShadow/SoftShadowMap.cpp?at=default#cl-225
That's what it looks like after I added the vertex shader:
http://pastie.org/pastes/8351289/text

The problem is that after I added the vertex shader, the screen is black.
Any idea what I'm doing wrong?

Thanks.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] question about getting RGB value(los point) of Terrain

[Robert Osfield]

Hi Kim,

You can't use the intersection point directly as this will be object
coordinates, not texture coordinates that the image is in.

What you will need to do is get the texture coordinates for the intersected
geometry.  In OSG-3.2 there is a convinience method that has been added to
LineSegmentIntersector::Intersection:

/** convinience function for mapping the intersection point to
any textures assigned to the objects intersected.
 *  Returns the Texture pointer and texture coords of object
hit when a texture is available on the object, returns NULL otherwise.*/
osg::Texture* getTextureLookUp(osg::Vec3& tc) const;

Robert.



On 24 September 2013 08:43, Kim JongBum  wrote:

> Hi,
>
> i am trying to get RGB value(los point) of Terrain
>
> i tried with below code.
>
> 
> osg::Drawable * drawable = intersection.drawable.get();
> if(drawable->getStateSet())
> {
> state_set = drawable->getStateSet();
> osg::Texture * texture = state_set->getTextureAttribute
> (0, osg::StateAttribute::TEXTURE)->asTexture();
>
>if(texture->getImage(osg::Material::FRONT))
> printf("%f  %f
>  
> %f\n",texture->getImage(osg::Material::FRONTFACE)->getColor(intersection.localIntersectionPoint).r()
>
> ,texture->getImage(osg::Material::FRONTFACE)->getColor(intersection.localIntersectionPoint).g()
>
> ,texture->getImage(osg::Material::FRONTFACE)->getColor(intersection.localIntersectionPoint).b());
> }
> ///
>
> But i only got RGB value as (1,1,1)
>
> Could u let me know why the value is always (1,1,1)
>
> Thank you in advance for any help
>
> Cheers,
> Kim
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=56456#56456
>
>
>
>
>
> ___
> 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

[Robert Milharcic]

On 24.9.2013 9:05, Aurelien Albert wrote:

I know this is more like a "workaround", but it is really usefull to be able to 
write StateAttributes classes which manage and apply their own uniforms.

To solve my problem described in this post, my guess is I have to replace the "_currentShaderCompositionUniformList" 
with a stack in which we can "push" and "pop" uniforms when StateAttributes are "pushed" and 
"poped".


Hi,

If you do change the list to stack so you can push/pop uniforms you will 
end up redoing standard uniform handling but this time with a parallel 
uniform list. In my opinion the usage scenario with osg::ShaderAttribute 
/ coposition uniforms is: Traverse graph, push and merge StateSets down 
to the Drawable where osg::ShaderAttribute(s) / coposition uniforms are 
to be set. It was my first attempt to do it like this but I later 
changed my aproach and rolled out my own custom shader attribute. I call 
it ShaderComponentAttribute, where I store a map of uniforms that were 
applied at parent (owning) StatSet. When ShaderComponentAttribute is 
removed, it also removes its managed uniforms.


Robert Milharcic
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] question about getting RGB value(los point) of Terrain

[Kim JongBum]

Hi,

i am trying to get RGB value(los point) of Terrain

i tried with below code.


osg::Drawable * drawable = intersection.drawable.get(); 
if(drawable->getStateSet()) 
{ 
state_set = drawable->getStateSet(); 
osg::Texture * texture = state_set->getTextureAttribute 
(0, osg::StateAttribute::TEXTURE)->asTexture(); 

   if(texture->getImage(osg::Material::FRONT))
printf("%f  %f  
%f\n",texture->getImage(osg::Material::FRONTFACE)->getColor(intersection.localIntersectionPoint).r()

,texture->getImage(osg::Material::FRONTFACE)->getColor(intersection.localIntersectionPoint).g()

,texture->getImage(osg::Material::FRONTFACE)->getColor(intersection.localIntersectionPoint).b());
} 
///

But i only got RGB value as (1,1,1)

Could u let me know why the value is always (1,1,1)

Thank you in advance for any help

Cheers,
Kim

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=56456#56456





___
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

[Aurelien Albert]

Hi,

Have a look here to see why I use this (on Robert's advice) : 

http://forum.openscenegraph.org/viewtopic.php?t=11769

I know this is more like a "workaround", but it is really usefull to be able to 
write StateAttributes classes which manage and apply their own uniforms.

To solve my problem described in this post, my guess is I have to replace the 
"_currentShaderCompositionUniformList" with a stack in which we can "push" and 
"pop" uniforms when StateAttributes are "pushed" and "poped".


Thank you!

Cheers,
Aurelien

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=56452#56452





___
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

[Robert Milharcic]

On 24.9.2013 8:40, Aurelien Albert wrote:

- Node A : Shader Program + Shader Composition Uniforms
 Child node B : nothing
 Child node C : Shader Program

In this case, Shader Composition Uniforms are properly applied on the Shader 
Program from node A, but not on shader program from node C


Hi,

I think you should simply call standar StateSet::AddUniform() at Node A 
so that every node below can inherit them. I think composition uniforms 
are good only if used in conjunction with osg::ShaderAttribute set to 
StateSet at leaf node.


Robert Milharcic
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org