Re: [osg-users] Bug with applying global default attributes?

[OpenSceneGraph Users]

I have determined that the problem is exercised if the first node sets the 
blend for FBO 1:

stateset->setAttribute(new osg::Enablei(GL_BLEND, 1));
osg::BlendEquationi* blendEq = new osg::BlendEquationi(1,
 osg::BlendEquation::RGBA_MAX);
osg::BlendFunci* blendFunc = new osg::BlendFunci(1,
 osg::BlendFunci::ONE, osg::BlendFunci::ONE);
stateset->setAttributeAndModes(blendEq, osg::StateAttribute::ON);
stateset->setAttributeAndModes(blendFunc, osg::StateAttribute::ON);


Removing this prevents the FBO 0 blending problem on the second node.

Rob

On Sunday, February 2, 2020 at 9:22:22 AM UTC-8, Rob Spearman wrote:
>
> I can confirm the bug also exists on 3.6.5-rc3 branch.  I don't know if it 
> pre-existed that.
>
> I have too many dependencies to be able to share a model.  Simplistic 
> models do not seem to exhibit the same behavior.
>
> I'll keep trying to debug.  When is applyGlobalDefaultAttribute supposed 
> to be called?  What sets these defaults?
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/3526e168-887b-4b63-bdb4-e8687da4c861%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Bug with applying global default attributes?

[OpenSceneGraph Users]

I can confirm the bug also exists on 3.6.5-rc3 branch.  I don't know if it 
pre-existed that.

I have too many dependencies to be able to share a model.  Simplistic 
models do not seem to exhibit the same behavior.

I'll keep trying to debug.  When is applyGlobalDefaultAttribute supposed to 
be called?  What sets these defaults?

In building rc3 I found some other issues:

There is a regression on rc3 where the install lib prefix is not set to 
64.  This is on CentOS 8 with cmake 3.11.4.  I had to set LIB_POSTFIX=64 on 
the cmake command line to install to the normal /usr/lib64.

There is also a pre-existing oddity in the sdl examples cmake, where 
SDLMAIN_LIBRARY is not found.  Shouldn't this be requiring SDL_LIBRARY 
instead?

Thanks,
Rob

On Thursday, January 30, 2020 at 12:09:39 AM UTC-8, OpenSceneGraph Users 
wrote:
>
> Hi Rob,
>
> Have you tried the 3.6 branch?  Is the issue a regression?
>
> Could you provide a test model and screenshot of the results your are 
> getting vs expecting if possible.  
>
> Cheers,
> Robert.
>
> On Wed, 29 Jan 2020 at 19:41, OpenSceneGraph Users <
> osg-...@lists.openscenegraph.org > wrote:
>
>>
>> I have been testing with trunk and have only come across one problem so 
>> far (this might not be a new issue).
>>
>> I have a simple viewer set up with two nodes.  The first is loaded from 
>> an osgb.  Internally it sets the glBlendFunci(0, GL_MAX) via 
>> osg::BlendFunci.
>>
>> The second node also sets glBlendFunci(0, GL_MAX).  This is a geode with 
>> a geometry node under it.  I am setting the blend attributes on the 
>> geometry state set.
>>
>> At runtime the attribute on node two is set correctly but then 
>> immediately changed again by State::ApplyGlobalDefaultAttribute to 
>> GL_FUNC_ADD.  The blend equation is also stepped on in a similar way.  I 
>> am using apitrace to see the GL calls.
>>
>> GL_FUNC_ADD is not part of either node that I can see.  However, this 
>> problem does not occur with, for example, axes.osgt used as node one.
>>
>> I could use some advice on tracking down where this default value is 
>> coming from, and why it is overriding a specific node attribute like this.
>>
>> Thanks,
>>
>> Rob
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/2e65f641-820e-41f6-b1ca-f67df29c278b%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Bug with applying global default attributes?

[OpenSceneGraph Users]

Hi Rob,

Have you tried the 3.6 branch?  Is the issue a regression?

Could you provide a test model and screenshot of the results your are
getting vs expecting if possible.

Cheers,
Robert.

On Wed, 29 Jan 2020 at 19:41, OpenSceneGraph Users <
osg-users@lists.openscenegraph.org> wrote:

>
> I have been testing with trunk and have only come across one problem so
> far (this might not be a new issue).
>
> I have a simple viewer set up with two nodes.  The first is loaded from
> an osgb.  Internally it sets the glBlendFunci(0, GL_MAX) via
> osg::BlendFunci.
>
> The second node also sets glBlendFunci(0, GL_MAX).  This is a geode with
> a geometry node under it.  I am setting the blend attributes on the
> geometry state set.
>
> At runtime the attribute on node two is set correctly but then
> immediately changed again by State::ApplyGlobalDefaultAttribute to
> GL_FUNC_ADD.  The blend equation is also stepped on in a similar way.  I
> am using apitrace to see the GL calls.
>
> GL_FUNC_ADD is not part of either node that I can see.  However, this
> problem does not occur with, for example, axes.osgt used as node one.
>
> I could use some advice on tracking down where this default value is
> coming from, and why it is overriding a specific node attribute like this.
>
> Thanks,
>
> Rob
>
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/mailman.67127.1580371768.7169.osg-users-openscenegraph.org%40lists.openscenegraph.org.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

-- 
You received this message because you are subscribed to the Google Groups 
"OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to osg-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/mailman.67127.1580371768.7169.osg-users-openscenegraph.org%40lists.openscenegraph.org.

[osg-users] Bug with applying global default attributes?

[OpenSceneGraph Users]

I have been testing with trunk and have only come across one problem so 
far (this might not be a new issue).


I have a simple viewer set up with two nodes.  The first is loaded from 
an osgb.  Internally it sets the glBlendFunci(0, GL_MAX) via 
osg::BlendFunci.


The second node also sets glBlendFunci(0, GL_MAX).  This is a geode with 
a geometry node under it.  I am setting the blend attributes on the 
geometry state set.


At runtime the attribute on node two is set correctly but then 
immediately changed again by State::ApplyGlobalDefaultAttribute to 
GL_FUNC_ADD.  The blend equation is also stepped on in a similar way.  I 
am using apitrace to see the GL calls.


GL_FUNC_ADD is not part of either node that I can see.  However, this 
problem does not occur with, for example, axes.osgt used as node one.


I could use some advice on tracking down where this default value is 
coming from, and why it is overriding a specific node attribute like this.


Thanks,

Rob






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

Re: [osg-users] Bug in Cull Visitor

[Robert Osfield]

On 13 May 2018 at 18:48, Robert Osfield  wrote:
> On 13 May 2018 at 17:01, Gedalia Pasternak  wrote:
>> Does that mean it’s used incorrectly in
>> OcclusionQueryNode::getPassed()? That was what I was basing my understanding
>> on.
>
> I'm not the author of OcclisionQueyNode so I have to look it up,
> jikes, yep it shouldn't be using TraversalNumber, it should be using
> nv->getFrameStamp()->getFrameNumber().
>
> I we amend the code and get it checked in, but it'll have to wait a
> little longer as it's dinner time!! :-)

I have done another review the CullVisitor and OcclusionQueryNode and
the use of FrameNumber,  The OSG's rendering backend does
automatically assign the FrameStampe::getFrameNumber() to the
CullVisitor::setTraversalNumber() so it "should" be safe for it to use
the NodeVisitor::getTraveralNumber() in place of
getFrameStamp()->getFrameNumber().

However, looking that the code in CullVisitor that increments the
_traversalNumber value, this is mis-using that value for a traversal
order number which isn't the same thing as traversal number.  I've
amended the CullVisitor and RenderLeaf/RenderBin so that they now use
_traversalOrderNumber.  This is checked into 3.6 branch and master.

I also checked in a small tweak to the precision of the some of the
local variables in OcclusionQueryNode.

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 Cull Visitor

[Robert Osfield]

Hi Gedalia,

On 13 May 2018 at 17:01, Gedalia Pasternak  wrote:
> Does that mean it’s used incorrectly in
> OcclusionQueryNode::getPassed()? That was what I was basing my understanding
> on.

I'm not the author of OcclisionQueyNode so I have to look it up,
jikes, yep it shouldn't be using TraversalNumber, it should be using
nv->getFrameStamp()->getFrameNumber().

I we amend the code and get it checked in, but it'll have to wait a
little longer as it's dinner time!! :-)

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 Cull Visitor

[Gedalia Pasternak]

Does that mean it’s used incorrectly in
OcclusionQueryNode::getPassed()? That was what I was basing my
understanding on.
Gedalia


On Sun, May 13, 2018 at 10:57 AM Robert Osfield 
wrote:

> Hi Gedalia,
>
> On 13 May 2018 at 15:27, Gedalia Pasternak  wrote:
> >But won’t just simply removing it mean that adding a render leaf will
> be
> > changing what the current frame is?
>
> TraversalNumber is local value to a visitor it isn't a the frame
> number, this is retrieved with the osg::FrameStamp::getFrameStamp().
>
> >  For occlusion nodes I’ve realized that it’s not currently possible to
> use
> > them within instanced hierarchy without tracking which traversal
> generated a
> > given query, the cull visitor traversal index (along with other changes)
> can
> > help disambiguate which draw query it was.
>
> The FrameStamp is probably what you should be using, it's attached the
> CullVisitor and the osg::State as well as the viewer.
>
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
-- 
DI-Guy Engineering Lead, VT MÄK
150 Cambridge Park Drive, 3rd Floor, Cambridge, MA 02140
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Bug in Cull Visitor

[Robert Osfield]

Hi Gedalia,

On 13 May 2018 at 15:27, Gedalia Pasternak  wrote:
>But won’t just simply removing it mean that adding a render leaf will be
> changing what the current frame is?

TraversalNumber is local value to a visitor it isn't a the frame
number, this is retrieved with the osg::FrameStamp::getFrameStamp().

>  For occlusion nodes I’ve realized that it’s not currently possible to use
> them within instanced hierarchy without tracking which traversal generated a
> given query, the cull visitor traversal index (along with other changes) can
> help disambiguate which draw query it was.

The FrameStamp is probably what you should be using, it's attached the
CullVisitor and the osg::State as well as the viewer.

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 Cull Visitor

[Gedalia Pasternak]

Thanks Robert,
   But won’t just simply removing it mean that adding a render leaf will be
changing what the current frame is?
 For occlusion nodes I’ve realized that it’s not currently possible to use
them within instanced hierarchy without tracking which traversal generated
a given query, the cull visitor traversal index (along with other changes)
can help disambiguate which draw query it was.
Gedalia

On Sun, May 13, 2018 at 6:55 AM Robert Osfield 
wrote:

> Hi Gedalia,
>
> Well spotted, this issue has been in the code for almost two decades
> without anyone noticing.  I've removed the duplicate from CullVisitor
> and checked this into OSG master and the 3.6 branch.
>
> Robert.
>
> On 12 May 2018 at 21:34, Gedalia Pasternak  wrote:
> > Both CullVisitor and it's base class NodeVisitor have members named
> > _traversalNumber. Yielding duplicate member variables with the same name,
> > and inconsistent behavior depending on how you access the class.
> > Cull visitor's should be renamed, maybe to _cullTraversalNumber or
> something
> > that wouldn't conflict with the base class. An accessor would be nice as
> > well. In the case of NodeVisitor it's what frame it's up to, for cull
> > visitor it's what accepted object it's up to (
> >// Otherwise need to create new renderleaf.
> > RenderLeaf* renderleaf = new
> > RenderLeaf(drawable,projection,matrix,depth,_traversalNumber++);
> > )
> >
> > -Gedalia
> >
> > ___
> > 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
>
-- 
DI-Guy Engineering Lead, VT MÄK
150 Cambridge Park Drive, 3rd Floor, Cambridge, MA 02140
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Bug in Cull Visitor

[Robert Osfield]

Hi Gedalia,

Well spotted, this issue has been in the code for almost two decades
without anyone noticing.  I've removed the duplicate from CullVisitor
and checked this into OSG master and the 3.6 branch.

Robert.

On 12 May 2018 at 21:34, Gedalia Pasternak  wrote:
> Both CullVisitor and it's base class NodeVisitor have members named
> _traversalNumber. Yielding duplicate member variables with the same name,
> and inconsistent behavior depending on how you access the class.
> Cull visitor's should be renamed, maybe to _cullTraversalNumber or something
> that wouldn't conflict with the base class. An accessor would be nice as
> well. In the case of NodeVisitor it's what frame it's up to, for cull
> visitor it's what accepted object it's up to (
>// Otherwise need to create new renderleaf.
> RenderLeaf* renderleaf = new
> RenderLeaf(drawable,projection,matrix,depth,_traversalNumber++);
> )
>
> -Gedalia
>
> ___
> 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] Bug in Cull Visitor

[Gedalia Pasternak]

Both CullVisitor and it's base class NodeVisitor have members named
_traversalNumber. Yielding duplicate member variables with the same name,
and inconsistent behavior depending on how you access the class.
Cull visitor's should be renamed, maybe to _cullTraversalNumber or
something that wouldn't conflict with the base class. An accessor would be
nice as well. In the case of NodeVisitor it's what frame it's up to, for
cull visitor it's what accepted object it's up to (
   // Otherwise need to create new renderleaf.
RenderLeaf* renderleaf = new
RenderLeaf(drawable,projection,matrix,depth,_traversalNumber++);
)

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

Re: [osg-users] Bug with new BaseUniform

[Julien Valentin]

trying to isolate min requirement to reproduce I ran in an other bug concerning 
removeTextureAttribute :
attribute->getTypeMemberPair() is not found for texture bound to other tu than 
0.
as TexAttrs are grouped by tu in ss , I believe that 
TextureAttribute::getMember should be removed(default 0 is good)...
Am I right?


robertosfield wrote:
> Hi Julien,
> 
> On 30 March 2018 at 13:10, Julien Valentin <> wrote:
> 
> > Since I merged with osg master the 03/22, I encountered a bug:
> > I don't understand it yet but it crashes in optimizer l614 comparing a 
> > baseUniform(which should be a uniform) with a uniform.
> > 
> > This silly baseuniform seams to be instanciated via  osgb file reading
> > 
> 
> Do you mean mean osg::UniformBase?  This is a new base class for
> uniforms as the old uniform class is a bit of mess of
> design/implemention, the UniformBase makes it possible to implement a
> range of properly typed uniforms, such as IntUniform, Vec2Uniform etc.
> 
> 
> > Will give more lead but Robert have an idea of what happens it could avoid 
> > an other bloody debug session for me
> > 
> 
> We'll the first thing you need to do if you want help is actually tell
> us how to reproduce the problem you are seeing.  Also please don't use
> the crude language when you do, it's just plain unpleasant to have to
> wade through this type of stuff.
> 
> Robert.
> ___
> osg-users mailing list
> 
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> 
>  --
> Post generated by Mail2Forum


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





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

Re: [osg-users] Bug with new BaseUniform

[Robert Osfield]

Hi Julien,

On 30 March 2018 at 13:10, Julien Valentin  wrote:
> Since I merged with osg master the 03/22, I encountered a bug:
> I don't understand it yet but it crashes in optimizer l614 comparing a 
> baseUniform(which should be a uniform) with a uniform.
>
> This silly baseuniform seams to be instanciated via  osgb file reading

Do you mean mean osg::UniformBase?  This is a new base class for
uniforms as the old uniform class is a bit of mess of
design/implemention, the UniformBase makes it possible to implement a
range of properly typed uniforms, such as IntUniform, Vec2Uniform etc.

> Will give more lead but Robert have an idea of what happens it could avoid an 
> other bloody debug session for me

We'll the first thing you need to do if you want help is actually tell
us how to reproduce the problem you are seeing.  Also please don't use
the crude language when you do, it's just plain unpleasant to have to
wade through this type of stuff.

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

[osg-users] Bug with new BaseUniform

[Julien Valentin]

Hi,

Since I merged with osg master the 03/22, I encountered a bug:
I don't understand it yet but it crashes in optimizer l614 comparing a 
baseUniform(which should be a uniform) with a uniform.

This silly baseuniform seams to be instanciated via  osgb file reading

Will give more lead but Robert have an idea of what happens it could avoid an 
other bloody debug session for me

Thank you!

Cheers,
Julien

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





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

Re: [osg-users] Bug in osgDB::findFileInDirectory

[Riccardo Corsi]

​Thanks Robert​

*Riccardo Corsi*  sw engineering & co-founder
*Kairos3D srl*  Via Agostino da Montefeltro 2, 10134 Torino Italy
*T* +390113157111  *M* +393288522785
*Check out our ground-breaking 3D CAD-to-VR toolchain: www.kairos3d.it
*

On Wed, Mar 28, 2018 at 12:50 PM, Robert Osfield 
wrote:

> Hi Ricardo,
>
> On 27 March 2018 at 19:42, Robert Osfield 
> wrote:
> > ./test --dir ~/OpenSceneGraph/include/osg/ --file version
> > Result with findFileInDirectory(): 0
> > Result with fileExists(): 0
> > concatenated=/home/robert/OpenSceneGraph/include/osg/version
> >
> > Which confirms your suggestion that the trailing slash isn't handled
> > by findFileInDirectory().
>
> I have checked in a catch for users passing in directories with a
> trailing / or \.  This fix is checked into OSG master and the 3.6
> branch.
>
> Robert
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Bug in osgDB::findFileInDirectory

[Robert Osfield]

Hi Ricardo,

On 27 March 2018 at 19:42, Robert Osfield  wrote:
> ./test --dir ~/OpenSceneGraph/include/osg/ --file version
> Result with findFileInDirectory(): 0
> Result with fileExists(): 0
> concatenated=/home/robert/OpenSceneGraph/include/osg/version
>
> Which confirms your suggestion that the trailing slash isn't handled
> by findFileInDirectory().

I have checked in a catch for users passing in directories with a
trailing / or \.  This fix is checked into OSG master and the 3.6
branch.

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 osgDB::findFileInDirectory

[Robert Osfield]

Hi Ricardo,

I have just tried with and wihtout the trailing slash and these are
the results I get under Linux,

./test --dir ~/OpenSceneGraph/include/osg --file version
Result with findFileInDirectory(): 1
/home/robert/OpenSceneGraph/include/osg/Version

./test --dir ~/OpenSceneGraph/include/osg/ --file version
Result with findFileInDirectory(): 0
Result with fileExists(): 0
concatenated=/home/robert/OpenSceneGraph/include/osg/version

Which confirms your suggestion that the trailing slash isn't handled
by findFileInDirectory().

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 osgDB::findFileInDirectory

[Riccardo Corsi]

Hi Robert,

thanks for the tests.
You're right I was not concatenating the paths correctly,
but the concatenation was ok in the default case,
as the directory path contains a final slash.

Now I've realised THAT is the case when the issue comes up:
if you use a directory path which has the final slash,
findFileInDirectory() fails to find the full path.
Remove the trailing slash and everything works fine.

This happens (at least on OSX) even if you run the example you sent me back
without arguments.

I'm re-attaching your example with the concatenation done the right way as
you suggested.

Thanks,
Riccardo


On Tue, Mar 27, 2018 at 6:38 PM, Robert Osfield 
wrote:

> I have just run the test case with a file with the wrong case to see
> what would happen, the results look 100% correct:
>
> $ ./test --dir ~/OpenSceneGraph/include/osg  --file version
> Result with findFileInDirectory(): 1
> /home/robert/OpenSceneGraph/include/osg/Version
> Result with fileExists(): 0
> concatenated=/home/robert/OpenSceneGraph/include/osgversion
> Result with fileExists(): 0
> proper_fileExsists=/home/robert/OpenSceneGraph/include/osg/version
>
> This test was run under Linux, so at least on the Linux side things
> are working correctly.  I have to defer to others to test under OSX.
>
> Robert.
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>


main.cpp
Description: Binary data
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Bug in osgDB::findFileInDirectory

[Robert Osfield]

I have just run the test case with a file with the wrong case to see
what would happen, the results look 100% correct:

$ ./test --dir ~/OpenSceneGraph/include/osg  --file version
Result with findFileInDirectory(): 1
/home/robert/OpenSceneGraph/include/osg/Version
Result with fileExists(): 0
concatenated=/home/robert/OpenSceneGraph/include/osgversion
Result with fileExists(): 0
proper_fileExsists=/home/robert/OpenSceneGraph/include/osg/version

This test was run under Linux, so at least on the Linux side things
are working correctly.  I have to defer to others to test under OSX.

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 osgDB::findFileInDirectory

[Robert Osfield]

Hi Riccardo,

On 27 March 2018 at 17:14, Riccardo Corsi  wrote:
> I found a bug in osgDB::findFileInDirectory() which does not return the
> expected result on MacOS (and I guess under Linux, but I cannot verify),
> while it works as expected under Windows.
>
> I'm attaching a modified osgversion.cpp which reproduces the issue.

I have just tried your code, with a few mods to see what the return
values are and there is bug in your code (this doens't mean there
isn't a bug on the OSG side, but first we need to get a reliable
test.), I modified the code to:

   std::string fullpath = osgDB::findFileInDirectory(file, dir,
osgDB::CASE_INSENSITIVE);
   bool result = !fullpath.empty();
   OSG_ALWAYS << "Result with findFileInDirectory(): " << result << "
"<[osg-users] Bug in osgDB::findFileInDirectory


2018-03-27

Thread
Riccardo Corsi

Hi Robert and all,

I found a bug in osgDB::findFileInDirectory() which does not return the
expected result on MacOS (and I guess under Linux, but I cannot verify),
while it works as expected under Windows.

I'm attaching a modified osgversion.cpp which reproduces the issue.

Tested with:
osg 3.6.0-rc2
Win10
MacOS 10.13

Thank you,
riccardo


osgversion.cpp
Description: Binary data
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org





Re: [osg-users] Bug in 3.4.0 when exporting .osgx file?


2017-03-21

Thread
Robert Osfield

Hi Werner,

As I explained in my previous post, the method should find the
wrappers if the plugin has been already loaded, so it shouldn't be
trying to reload a plugin as there would be no beneft - the code will
have already checked all the possible wrappers.

You haven't provided any guidance on how we might reproduce the issue
so I can't say what might be wrong.  The code you are looking at is
likely of symptom of a problem elsewhere.

Another avenue you could try is to look at the OSG master to see if
fixes elsewhere in the OSG have addressed this issue.

Robert.

On 21 March 2017 at 14:54, Werner Modenbach  wrote:
> Hi Robert,
>
> the problem is here:
>
> if
> (osgDB::Registry::instance()->loadLibrary(pluginLib)==osgDB::Registry::LOADED)
>
> return findWrapper(name);
>
> return NULL;
>
> The loadLibrary() returns PREVIOUSLY_LOADED and not LOADED.
> So NULL gets returned instead of a wrapper pointer and thus the node doesn't
> get exported.
> Or am I on the wrong search path?
>
> I try exporting my scene into an .osgx file by calling:
> osg::ref_ptr rw =
> osgDB::Registry::instance()->getReaderWriterForExtension(
>
> osgDB::getLowerCaseFileExtension(_filename.toStdString()));
> if (!rw.valid())
> return false;
> osgDB::ReaderWriter::WriteResult result = rw->writeNode(_node,
> _filename.toStdString());
>
> result.success() is true.
> It creates a file containing only the outer xml header and no scene data.
> node is of type osg::group
>
>
> Am 21.03.2017 um 14:42 schrieb Robert Osfield:
>
> Hi Werner,
>
> I can't work out what might be wrong form the description.
>
> In general the ObjectWrapperManager::findWrapper() checks wrappers
> that have been registered with it first, then if it fails to find one
> then attempts to load plugins that may be able to provide that
> wrapper. If the code is getting to the find return then it's an
> indication that the wrapper has been found.  Given this the
> ObjectWrapperManager::findWrapper() code looks correct.
>
> This review would suggest that the issue is likely elsewhere.  What
> might be wrong is not something I can say at this stage.  Would it be
> possible create a test case that reproduces the problem so others can
> look into it?
>
> Robert.
>
>
> On 21 March 2017 at 13:15, Werner Modenbach 
> wrote:
>
> Hi Robert,
>
> I think I catched another problem in version 3.4.0.
> I try exporting my scene as .osgx file.
> But except the xml header nothing is written.
> I debuged it and found the following sequence of calls:
>
>
> osg::ref_ptr rw =
> osgDB::Registry::instance()->getReaderWriterForExtension(
>
>
> osgDB::getLowerCaseFileExtension(_filename.toStdString()));
>
> if (!rw.valid())
>
> return false;
>
> osgDB::ReaderWriter::WriteResult result = rw->writeNode(_node,
> _filename.toStdString());
>
> -> ReaderWriterOSG2::writeNode(...)
>
> result = writeNode( node, fout, local_opt.get() );
>
> -> ReaderWriterOSG2::writeNode(...)
>
> os.writeObject(  ); CATCH_EXCEPTION(os);
>
> -> OutputStream::writeObject(...)
>
> if (newID)
> {
> writeObjectFields(obj);
> }
>
> -> OutputStream::writeObjectFields(...)
>
> ObjectWrapper* wrapper =
> Registry::instance()->getObjectWrapperManager()->findWrapper( name );
> if ( !wrapper )
> {
> OSG_WARN << "OutputStream::writeObject(): Unsupported wrapper class
> "
> << name << std::endl;
> return;
> }
>
> -> OutputStream::writeObjectFields(...)
>
> ObjectWrapper* wrapper =
> Registry::instance()->getObjectWrapperManager()->findWrapper( name );
> if ( !wrapper )
> {
> OSG_WARN << "OutputStream::writeObject(): Unsupported wrapper class
> "
> << name << std::endl;
> return;
> }
> -> ObjectWrapperManager::findWrapper(...)
>
> pluginLib =
> osgDB::Registry::instance()->createLibraryNameForExtension(libName);
> if (
> osgDB::Registry::instance()->loadLibrary(pluginLib)==osgDB::Registry::LOADED
> )
> return findWrapper(name);
> }
> return NULL;
>
> The loadLibrary(...) method returns "PREVIOUSLY_LOADED" and so NULL is
> returned and nothing gets written.
>
> I think that should be different. Am I right?
>
> - Werner -
>
>
>
> ___
> 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
>
>
> --
> TEXION Software Solutions, Rotter Bruch 26a, D-52068 Aachen
> Phone: +49 241 475757-0
> Fax: +49 241 475757-29
> Web: http://texion.eu
> eMail: i...@texion.eu
>
> ___
> osg-users mailing list
> 



Re: [osg-users] Bug in 3.4.0 when exporting .osgx file?


2017-03-21

Thread
Werner Modenbach


Hi Robert,

the problem is here:

if 
(osgDB::Registry::instance()->loadLibrary(pluginLib)==osgDB::Registry::LOADED)

return findWrapper(name);

return NULL;

The loadLibrary() returns PREVIOUSLY_LOADED and not LOADED.
So NULL gets returned instead of a wrapper pointer and thus the node doesn't 
get exported.
Or am I on the wrong search path?

I try exporting my scene into an .osgx file by calling:
osg::ref_ptrrw=osgDB::Registry::instance()->getReaderWriterForExtension( 
osgDB::getLowerCaseFileExtension(_filename.toStdString())); 
if(!rw.valid()) returnfalse; osgDB::ReaderWriter::WriteResultresult=rw->writeNode(_node,_filename.toStdString());


result.success() is true.
It creates a file containing only the outer xml header and no scene data. node 
is of type osg::group


Am 21.03.2017 um 14:42 schrieb Robert Osfield:

Hi Werner,

I can't work out what might be wrong form the description.

In general the ObjectWrapperManager::findWrapper() checks wrappers
that have been registered with it first, then if it fails to find one
then attempts to load plugins that may be able to provide that
wrapper. If the code is getting to the find return then it's an
indication that the wrapper has been found.  Given this the
ObjectWrapperManager::findWrapper() code looks correct.

This review would suggest that the issue is likely elsewhere.  What
might be wrong is not something I can say at this stage.  Would it be
possible create a test case that reproduces the problem so others can
look into it?

Robert.


On 21 March 2017 at 13:15, Werner Modenbach  wrote:

Hi Robert,

I think I catched another problem in version 3.4.0.
I try exporting my scene as .osgx file.
But except the xml header nothing is written.
I debuged it and found the following sequence of calls:


 osg::ref_ptr rw =
osgDB::Registry::instance()->getReaderWriterForExtension(


osgDB::getLowerCaseFileExtension(_filename.toStdString()));

 if (!rw.valid())

 return false;

 osgDB::ReaderWriter::WriteResult result = rw->writeNode(_node,
_filename.toStdString());

-> ReaderWriterOSG2::writeNode(...)

 result = writeNode( node, fout, local_opt.get() );

-> ReaderWriterOSG2::writeNode(...)

 os.writeObject(  ); CATCH_EXCEPTION(os);

-> OutputStream::writeObject(...)

 if (newID)
 {
 writeObjectFields(obj);
 }

-> OutputStream::writeObjectFields(...)

 ObjectWrapper* wrapper =
Registry::instance()->getObjectWrapperManager()->findWrapper( name );
 if ( !wrapper )
 {
 OSG_WARN << "OutputStream::writeObject(): Unsupported wrapper class
"
 << name << std::endl;
 return;
 }

-> OutputStream::writeObjectFields(...)

 ObjectWrapper* wrapper =
Registry::instance()->getObjectWrapperManager()->findWrapper( name );
 if ( !wrapper )
 {
 OSG_WARN << "OutputStream::writeObject(): Unsupported wrapper class
"
 << name << std::endl;
 return;
 }
-> ObjectWrapperManager::findWrapper(...)

 pluginLib =
osgDB::Registry::instance()->createLibraryNameForExtension(libName);
 if (
osgDB::Registry::instance()->loadLibrary(pluginLib)==osgDB::Registry::LOADED
)
 return findWrapper(name);
 }
 return NULL;

The loadLibrary(...) method returns "PREVIOUSLY_LOADED" and so NULL is
returned and nothing gets written.

I think that should be different. Am I right?

- Werner -



___
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


--
*TEXION Software Solutions, Rotter Bruch 26a, D-52068 Aachen*
Phone: +49 241 475757-0
Fax: +49 241 475757-29
Web: http://texion.eu
eMail: i...@texion.eu
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org





Re: [osg-users] Bug in 3.4.0 when exporting .osgx file?


2017-03-21

Thread
Robert Osfield

Hi Werner,

I can't work out what might be wrong form the description.

In general the ObjectWrapperManager::findWrapper() checks wrappers
that have been registered with it first, then if it fails to find one
then attempts to load plugins that may be able to provide that
wrapper. If the code is getting to the find return then it's an
indication that the wrapper has been found.  Given this the
ObjectWrapperManager::findWrapper() code looks correct.

This review would suggest that the issue is likely elsewhere.  What
might be wrong is not something I can say at this stage.  Would it be
possible create a test case that reproduces the problem so others can
look into it?

Robert.


On 21 March 2017 at 13:15, Werner Modenbach  wrote:
> Hi Robert,
>
> I think I catched another problem in version 3.4.0.
> I try exporting my scene as .osgx file.
> But except the xml header nothing is written.
> I debuged it and found the following sequence of calls:
>
>
> osg::ref_ptr rw =
> osgDB::Registry::instance()->getReaderWriterForExtension(
>
>
> osgDB::getLowerCaseFileExtension(_filename.toStdString()));
>
> if (!rw.valid())
>
> return false;
>
> osgDB::ReaderWriter::WriteResult result = rw->writeNode(_node,
> _filename.toStdString());
>
> -> ReaderWriterOSG2::writeNode(...)
>
> result = writeNode( node, fout, local_opt.get() );
>
> -> ReaderWriterOSG2::writeNode(...)
>
> os.writeObject(  ); CATCH_EXCEPTION(os);
>
> -> OutputStream::writeObject(...)
>
> if (newID)
> {
> writeObjectFields(obj);
> }
>
> -> OutputStream::writeObjectFields(...)
>
> ObjectWrapper* wrapper =
> Registry::instance()->getObjectWrapperManager()->findWrapper( name );
> if ( !wrapper )
> {
> OSG_WARN << "OutputStream::writeObject(): Unsupported wrapper class
> "
> << name << std::endl;
> return;
> }
>
> -> OutputStream::writeObjectFields(...)
>
> ObjectWrapper* wrapper =
> Registry::instance()->getObjectWrapperManager()->findWrapper( name );
> if ( !wrapper )
> {
> OSG_WARN << "OutputStream::writeObject(): Unsupported wrapper class
> "
> << name << std::endl;
> return;
> }
> -> ObjectWrapperManager::findWrapper(...)
>
> pluginLib =
> osgDB::Registry::instance()->createLibraryNameForExtension(libName);
> if (
> osgDB::Registry::instance()->loadLibrary(pluginLib)==osgDB::Registry::LOADED
> )
> return findWrapper(name);
> }
> return NULL;
>
> The loadLibrary(...) method returns "PREVIOUSLY_LOADED" and so NULL is
> returned and nothing gets written.
>
> I think that should be different. Am I right?
>
> - Werner -
>
>
>
> ___
> 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] Bug in 3.4.0 when exporting .osgx file?


2017-03-21

Thread
Werner Modenbach


Hi Robert,

I think I catched another problem in version 3.4.0.
I try exporting my scene as .osgx file.
But except the xml header nothing is written.
I debuged it and found the following sequence of calls:


osg::ref_ptrrw=osgDB::Registry::instance()->getReaderWriterForExtension( 



osgDB::getLowerCaseFileExtension(_filename.toStdString()));

if(!rw.valid())

returnfalse;

osgDB::ReaderWriter::WriteResultresult=rw->writeNode(_node,_filename.toStdString());

-> ReaderWriterOSG2::writeNode(...)
result=writeNode(node,fout,local_opt.get());

-> ReaderWriterOSG2::writeNode(...) os.writeObject();CATCH_EXCEPTION(os);

->OutputStream::writeObject(...)

if(newID)
{
writeObjectFields(obj);
}

->OutputStream::writeObjectFields(...)

ObjectWrapper*wrapper=Registry::instance()->getObjectWrapperManager()->findWrapper(name);
if(!wrapper)
{
OSG_WARN<<"OutputStream::writeObject():Unsupportedwrapperclass"
<OutputStream::writeObjectFields(...)

ObjectWrapper*wrapper=Registry::instance()->getObjectWrapperManager()->findWrapper(name);
if(!wrapper)
{
OSG_WARN<<"OutputStream::writeObject():Unsupportedwrapperclass"
<ObjectWrapperManager::findWrapper(...)

pluginLib=osgDB::Registry::instance()->createLibraryNameForExtension(libName);
if(osgDB::Registry::instance()->loadLibrary(pluginLib)==osgDB::Registry::LOADED)
returnfindWrapper(name);
}
returnNULL;

The loadLibrary(...) method returns "PREVIOUSLY_LOADED" and so NULL is returned 
and nothing gets written.

I think that should be different. Am I right?

- Werner -


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





Re: [osg-users] bug: osgText doesn't work on MacOSX GL4.x with VAO


2017-03-14

Thread
Robert Osfield

Hi Remo,

On 14 March 2017 at 18:16, Remo Eichenberger  wrote:
> The env variable doesn't help. I see such errors:
>
> With subloading enabled i see this:
>
> before Glyph::subload(): detected OpenGL error: invalid enumerant
> Glyph::subload(): texture sub-image width and/or height of 0, ignoring 
> operation.

I can't investigate these OSX specific issues.  There is a limit to
the amount of free support I can do on this, the rewrite of osgText
has already cost me three weeks work, all unpaid.  It's time that OSX
users stood up to the plate and started resolving OSX specific issues.
There are other pressing things I need to get on with.

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





Re: [osg-users] bug: osgText doesn't work on MacOSX GL4.x with VAO


2017-03-14

Thread
Remo Eichenberger

The env variable doesn't help. I see such errors:

With subloading enabled i see this:

before Glyph::subload(): detected OpenGL error: invalid enumerant
Glyph::subload(): texture sub-image width and/or height of 0, ignoring 
operation.

I've posted the log on the github issue.

Remo

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





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





Re: [osg-users] bug: osgText doesn't work on MacOSX GL4.x with VAO


2017-03-14

Thread
Robert Osfield

On 14 March 2017 at 17:38, Remo Eichenberger  wrote:
> Without this setting I see only a blue screen/window without any text.

Do you get any GL errors reported on the console?

Could you try disabling the incremental subloading of the glyph
texture by setting the env var OSG_TEXT_INCREMENTAL_SUBLOADING to OFF

i.e.

setenv OSG_TEXT_INCREMENTAL_SUBLOADING OFF
osgtext

Also have you tried OSG+GL3 on other platforms?  Knowing whether this
is a OSX specific bug or not will help us look for what the cause
might be.

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





Re: [osg-users] bug: osgText doesn't work on MacOSX GL4.x with VAO


2017-03-14

Thread
Remo Eichenberger

Without this setting I see only a blue screen/window without any text.

Remo

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





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





Re: [osg-users] bug: osgText doesn't work on MacOSX GL4.x with VAO


2017-03-14

Thread
Robert Osfield

On 14 March 2017 at 17:01, Remo Eichenberger  wrote:
> Update: Stock sample "examples_osgtext" partial works with:
>
> font->setMinFilterHint(osg::Texture::LINEAR);
>
> on MacOSX GL3 Core Profile

This will be disabling mipmapping.  Surely OSX GL3 core profile
supports mipmapping. this is a fundamental feature of texturing.
Perhaps the driver is broken.

Disabling mipmapping on text is not desirable as you'll end up with
aliasing artefacts when the text on screen size results in the texel
to pixel ratio less than one.

What happens you don't use the
font->setMinFilterHint(osg::Texture::LINEAR); hack?  A screenshot
would be useful.

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





Re: [osg-users] bug: osgText doesn't work on MacOSX GL4.x with VAO


2017-03-14

Thread
Remo Eichenberger

Update: Stock sample "examples_osgtext" partial works with:

font->setMinFilterHint(osg::Texture::LINEAR);

on MacOSX GL3 Core Profile

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





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





Re: [osg-users] bug: osgText doesn't work on MacOSX GL4.x with VAO


2017-03-11

Thread
Remo Eichenberger

Hi Robert

I've tested the latest branch on MacOSX 10.11.6:
https://github.com/openscenegraph/OpenSceneGraph/commit/f1f6d23eebda16a9d4560a0a130580d65edf7401

Non of the stock samples works because of not applied shader. MacOSX needs a 
default shader.

But simple text works when i add a shader on my sample code. 

Then i've added the Statshandler. It doesn't show the statistics.

Cheers,
Remo

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





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





Re: [osg-users] bug: osgText doesn't work on MacOSX GL4.x with VAO


2017-02-04

Thread
Robert Osfield

Hi Remo,

As a first step to resolving the osgText issues with VAO I have
created a text_refactor branch off OSG master.

All I have done so far is add the ability of osgText::TextBase to have
NodeList _children that it traverses automatically, this _children
list is intended for the Text and Text3D classes to populate with
standard scene graph elements such as osg::Geometry/osg::StateSet to
render the text in conventional ways rather the the custom render code
that these classes currently have.

The next step will be to adapt osgText::Text to create the appropriate
subgraph to render the text and add this into the _children list.
osgText::Text is not a straight forward class so I expect we'll need
to slow fill in all the functionality bit by bit.  I welcome efforts
from the community in this effort.

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: osgText doesn't work on MacOSX GL4.x with VAO


2017-01-27

Thread
Robert Osfield

HI Remo,

On 27 January 2017 at 14:29, Remo Eichenberger  wrote:
> OSG_VERTEX_BUFFER_HINT=VAO
> OSG_GEOMETRY_IMPLEMENTATION=VAO

Oh well, that exhausts one possibility of a fix.

I don't really know if it's worth trying to fix osgText::Text, when I
made the changes to support VAO I got things working under Linux, or
at least it appeared to be working, but osgText::Text implementation
is a real mess internally due to several early design decisions based
on limitations of hardware 15 years back then a series of contribution
that added extra features to Text but also with lots of complexities.

To properly fix it I feel that it might even be worth making
osgText::Text and full node and have it generate a subgraph (made with
standard osg::Geometry etc.) to do the actual rendering rather than
embed it all in a custom Drawable as is done now.  The problem would
be backwards compatibility.

I have too much other work on right now to dive into topic, but have a
think about  the issues when I do have time.

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





Re: [osg-users] bug: osgText doesn't work on MacOSX GL4.x with VAO


2017-01-27

Thread
Remo Eichenberger

yes,

OSG_VERTEX_BUFFER_HINT=VAO
OSG_GEOMETRY_IMPLEMENTATION=VAO

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





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





Re: [osg-users] bug: osgText doesn't work on MacOSX GL4.x with VAO


2017-01-27

Thread
Robert Osfield

On 27 January 2017 at 14:15, Remo Eichenberger  wrote:
> I use OSG master 255a86cbe22ba436ab162bd2a2e7cc0341140050

Have you enabled the new VAO support?

The env var OSG_VERTEX_BUFFER_HINT should be used and set to VAO.

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





Re: [osg-users] bug: osgText doesn't work on MacOSX GL4.x with VAO


2017-01-27

Thread
Remo Eichenberger

Hi Robert

I use OSG master 255a86cbe22ba436ab162bd2a2e7cc0341140050

Cheers,
Remo

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





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





Re: [osg-users] bug: osgText doesn't work on MacOSX GL4.x with VAO


2017-01-27

Thread
Robert Osfield

Hi Remo,

On 27 January 2017 at 13:59, Remo Eichenberger  wrote:
> I've tried a lot of things to get osgText working on MacOSX with VAO. GL3 on 
> OSX Core Profile requires VAOs.

I don't have an OSX system so can't comment on the specifics of VAO
support on MacOSX, I have rely upon OSX users to provide testing and
guidance on it.

The only thing I can add is to ask which version of the OSG you are
using, and whether you've tested the new VAO support in OSG master.

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





Re: [osg-users] bug: osgText doesn't work on MacOSX GL4.x with VAO


2017-01-27

Thread
Remo Eichenberger

Hi (Robert :)

I've tried a lot of things to get osgText working on MacOSX with VAO. GL3 on 
OSX Core Profile requires VAOs.

osgText doesn't setup the VAO path correctly on MacOSX. I can show glyphs when 
I use a osg::Geometry as a Wrapper to draw geometries from text glyphs like so:


Code:

class ExtText : public Text {
friend class VAOText;
};

class VAOText : public osg::Geometry
{
private:
osg::ref_ptr _t;

...
void redraw()
{
unsigned int contextID = 0; // renderInfo.getState()->getContextID();

if ( !_t->_textureGlyphQuadMap.empty() )
{
const ExtText::GlyphQuads& glyphquad = 
(_t->_textureGlyphQuadMap.begin())->second;
if (!glyphquad._transformedCoords[contextID].valid() || 
glyphquad._transformedCoords[contextID]->empty() )
{
_t->computePositions(contextID);
}
}

for(ExtText::TextureGlyphQuadMap::iterator 
titr=_t->_textureGlyphQuadMap.begin();
titr!=_t->_textureGlyphQuadMap.end();
++titr)
{
const ExtText::GlyphQuads& glyphquad = titr->second;
const ExtText::GlyphQuads::Coords3& transformedCoords = 
glyphquad._transformedCoords[contextID];
if (transformedCoords.valid() && !transformedCoords->empty())
{

setVertexArray(transformedCoords.get());
setTexCoordArray(0, glyphquad._texcoords.get());

getOrCreateStateSet()->setTextureAttributeAndModes(0, 
titr->first.get(),osg::StateAttribute::ON);
addPrimitiveSet(glyphquad._quadIndices);
}
}
}




But it doesn't work with plain osgText. So something is wrong in osgText / VAO.

Cheers,
Remo

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





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





Re: [osg-users] Bug while updating geometry in Linux


2017-01-26

Thread
Nikita Petrov

Thanks, Robert!

Adding vertices->dirty(); worked perfect.
I even removed geometry->dirtyBound(); - I suppose I don't need it? Because my 
example works without that call.

It is strange why it is only noticable on Linux.

Nikita



robertosfield wrote:
> HI Nikita,
> 
> I don't have time to try and the example problem right now, my best
> guide having had a quick read through is that perhaps you need to a a
> vertices->dirty() after you've done the vertices->push_back().  For a
> straight GL vertex array this won't be required, but if you are using
> VBO's this will be required so the OSG knows to updload the data to
> the GPU.
> 
> Robert.
> 
> On 26 January 2017 at 09:27, Nikita Petrov <> wrote:
> 
> > Hi,
> > 
> > I am trying to port my app from Windows to Linux.
> > I have a ribbon, which is updated dynamically. I add 2 points to vertices 
> > and I use GL_TRIANGLE_STRIP to create a ribbon.
> > On Windows everything works fine.
> > But on Linux all new vertices go to coordinates (0,0,0) after calling 
> > geometry->dirtyBound();
> > 
> > I even created a small app to test this behaviour on Linux. It should draw 
> > sine function ribbon.
> > Here's the code:
> > 
> > osg::ref_ptr vertices;
> > osg::ref_ptr geometry;
> > osg::DrawArrays* drawArrays;
> > int count;
> > 
> > class UpdateVertex: public osg::NodeCallback
> > {
> > public:
> > UpdateVertex() {}
> > virtual void operator()(osg::Node* node, osg::NodeVisitor* nv);
> > };
> > 
> > void UpdateVertex::operator()(osg::Node* node, osg::NodeVisitor* nv)
> > {
> > OpenThreads::Thread::microSleep(1000);
> > 
> > vertices->push_back(osg::Vec3(1+count/200.0, 1, 1+sin(count*M_PI/180.0)));
> > vertices->push_back(osg::Vec3(1+count/200.0, 2, 1+sin(count*M_PI/180.0)));
> > count++;
> > 
> > drawArrays->setCount(vertices->size());
> > geometry->dirtyBound();
> > 
> > traverse(node, nv);
> > }
> > 
> > int main(int argc, char *argv[])
> > {
> > vertices = new osg::Vec3Array();
> > 
> > count = 120;
> > for (int i=0;i > {
> > vertices->push_back(osg::Vec3(1+i/200.0, 1, 1+sin(i*M_PI/180.0)));
> > vertices->push_back(osg::Vec3(1+i/200.0, 2, 1+sin(i*M_PI/180.0)));
> > }
> > 
> > osg::ref_ptr normal = new osg::Vec3Array();
> > normal->push_back(osg::Vec3(0.0f, 0.0f, 1.0f));
> > osg::ref_ptr color = new osg::Vec4Array();
> > color->push_back(osg::Vec4(0,0,1,0.8f));
> > 
> > geometry = new osg::Geometry;
> > geometry->setDataVariance(osg::Object::DYNAMIC);
> > geometry->setUseDisplayList(false);
> > geometry->setVertexArray(vertices.get());
> > geometry->setNormalArray(normal.get());
> > geometry->setNormalBinding(osg::Geometry::BIND_OVERALL);
> > geometry->setColorArray(color.get());
> > geometry->setColorBinding(osg::Geometry::BIND_OVERALL);
> > 
> > drawArrays = new osg::DrawArrays(GL_TRIANGLE_STRIP, 0, vertices->size());
> > geometry->addPrimitiveSet(drawArrays);
> > 
> > osg::ref_ptr geode = new osg::Geode();
> > geode->addDrawable(geometry.get());
> > geode->getOrCreateStateSet()->setMode(GL_LIGHTING, 
> > osg::StateAttribute::OFF);
> > 
> > osg::ref_ptr root = new osg::Group();
> > 
> > root->addChild(geode.get());
> > 
> > root->addUpdateCallback(new UpdateVertex);
> > 
> > osgViewer::Viewer viewer;
> > viewer.setSceneData(root.get());
> > viewer.getCamera()->setSmallFeatureCullingPixelSize(0);
> > viewer.getCamera()->setClearColor(osg::Vec4(1,1,1,1));
> > viewer.addEventHandler(new osgViewer::StatsHandler);
> > 
> > viewer.realize();
> > 
> > return viewer.run();
> > }
> > 
> > And you can see what I get in the attachements.
> > If I press "S" to see number of vertices (thanks to StatsHandler), it is 
> > always increasing. So new vertices are added, but in (0,0,0) coordinates.
> > My guess is that geometry->dirtyBound(); is not working corectly.
> > 
> > I use master build of OSG.
> > On Windows I use x86 build with Visual Studio 2013.
> > On Linux Mint 18 Cinnamon 64-bit, I use x64 build with Qt Creator (GCC 
> > 64bit).
> > 
> > Hope that somebody have a clue to that issue.
> > 
> > Best regards,
> > Nikita
> > 
> > --
> > Read this topic online here:
> > http://forum.openscenegraph.org/viewtopic.php?p=70051#70051
> > 
> > 
> > 
> > 
> > Attachments:
> > http://forum.openscenegraph.org//files/2_123.png
> > http://forum.openscenegraph.org//files/1_632.png
> > 
> > 
> > ___
> > osg-users mailing list
> > 
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> > 
> ___
> osg-users mailing list
> 
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> 
>  --
> Post generated by Mail2Forum


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





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





Re: [osg-users] Bug while updating geometry in Linux


2017-01-26

Thread
Robert Osfield

HI Nikita,

I don't have time to try and the example problem right now, my best
guide having had a quick read through is that perhaps you need to a a
vertices->dirty() after you've done the vertices->push_back().  For a
straight GL vertex array this won't be required, but if you are using
VBO's this will be required so the OSG knows to updload the data to
the GPU.

Robert.

On 26 January 2017 at 09:27, Nikita Petrov  wrote:
> Hi,
>
> I am trying to port my app from Windows to Linux.
> I have a ribbon, which is updated dynamically. I add 2 points to vertices and 
> I use GL_TRIANGLE_STRIP to create a ribbon.
> On Windows everything works fine.
> But on Linux all new vertices go to coordinates (0,0,0) after calling 
> geometry->dirtyBound();
>
> I even created a small app to test this behaviour on Linux. It should draw 
> sine function ribbon.
> Here's the code:
>
> osg::ref_ptr vertices;
> osg::ref_ptr geometry;
> osg::DrawArrays* drawArrays;
> int count;
>
> class UpdateVertex: public osg::NodeCallback
> {
> public:
>   UpdateVertex() {}
>   virtual void operator()(osg::Node* node, osg::NodeVisitor* nv);
> };
>
> void UpdateVertex::operator()(osg::Node* node, osg::NodeVisitor* nv)
> {
>   OpenThreads::Thread::microSleep(1000);
>
>   vertices->push_back(osg::Vec3(1+count/200.0, 1, 1+sin(count*M_PI/180.0)));
>   vertices->push_back(osg::Vec3(1+count/200.0, 2, 1+sin(count*M_PI/180.0)));
>   count++;
>
>   drawArrays->setCount(vertices->size());
>   geometry->dirtyBound();
>
>   traverse(node, nv);
> }
>
> int main(int argc, char *argv[])
> {
> vertices = new osg::Vec3Array();
>
> count = 120;
> for (int i=0;i {
> vertices->push_back(osg::Vec3(1+i/200.0, 1, 1+sin(i*M_PI/180.0)));
> vertices->push_back(osg::Vec3(1+i/200.0, 2, 1+sin(i*M_PI/180.0)));
> }
>
> osg::ref_ptr normal = new osg::Vec3Array();
> normal->push_back(osg::Vec3(0.0f, 0.0f, 1.0f));
> osg::ref_ptr color = new osg::Vec4Array();
> color->push_back(osg::Vec4(0,0,1,0.8f));
>
> geometry = new osg::Geometry;
> geometry->setDataVariance(osg::Object::DYNAMIC);
> geometry->setUseDisplayList(false);
> geometry->setVertexArray(vertices.get());
> geometry->setNormalArray(normal.get());
> geometry->setNormalBinding(osg::Geometry::BIND_OVERALL);
> geometry->setColorArray(color.get());
> geometry->setColorBinding(osg::Geometry::BIND_OVERALL);
>
> drawArrays = new osg::DrawArrays(GL_TRIANGLE_STRIP, 0, vertices->size());
> geometry->addPrimitiveSet(drawArrays);
>
> osg::ref_ptr geode = new osg::Geode();
> geode->addDrawable(geometry.get());
> geode->getOrCreateStateSet()->setMode(GL_LIGHTING, 
> osg::StateAttribute::OFF);
>
> osg::ref_ptr root = new osg::Group();
>
> root->addChild(geode.get());
>
> root->addUpdateCallback(new UpdateVertex);
>
> osgViewer::Viewer viewer;
> viewer.setSceneData(root.get());
> viewer.getCamera()->setSmallFeatureCullingPixelSize(0);
> viewer.getCamera()->setClearColor(osg::Vec4(1,1,1,1));
> viewer.addEventHandler(new osgViewer::StatsHandler);
>
> viewer.realize();
>
> return viewer.run();
> }
>
> And you can see what I get in the attachements.
> If I press "S" to see number of vertices (thanks to StatsHandler), it is 
> always increasing. So new vertices are added, but in (0,0,0) coordinates.
> My guess is that geometry->dirtyBound(); is not working corectly.
>
> I use master build of OSG.
> On Windows I use x86 build with Visual Studio 2013.
> On Linux Mint 18 Cinnamon 64-bit, I use x64 build with Qt Creator (GCC 64bit).
>
> Hope that somebody have a clue to that issue.
>
> Best regards,
> Nikita
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=70051#70051
>
>
>
>
> Attachments:
> http://forum.openscenegraph.org//files/2_123.png
> http://forum.openscenegraph.org//files/1_632.png
>
>
> ___
> 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] Bug while updating geometry in Linux


2017-01-26

Thread
Nikita Petrov

Hi,

I am trying to port my app from Windows to Linux.
I have a ribbon, which is updated dynamically. I add 2 points to vertices and I 
use GL_TRIANGLE_STRIP to create a ribbon.
On Windows everything works fine.
But on Linux all new vertices go to coordinates (0,0,0) after calling 
geometry->dirtyBound();

I even created a small app to test this behaviour on Linux. It should draw sine 
function ribbon.
Here's the code:

osg::ref_ptr vertices;
osg::ref_ptr geometry;
osg::DrawArrays* drawArrays;
int count;

class UpdateVertex: public osg::NodeCallback
{
public:
  UpdateVertex() {}
  virtual void operator()(osg::Node* node, osg::NodeVisitor* nv);
};

void UpdateVertex::operator()(osg::Node* node, osg::NodeVisitor* nv)
{
  OpenThreads::Thread::microSleep(1000);

  vertices->push_back(osg::Vec3(1+count/200.0, 1, 1+sin(count*M_PI/180.0)));
  vertices->push_back(osg::Vec3(1+count/200.0, 2, 1+sin(count*M_PI/180.0)));
  count++;

  drawArrays->setCount(vertices->size());
  geometry->dirtyBound();

  traverse(node, nv);
}

int main(int argc, char *argv[])
{
vertices = new osg::Vec3Array();

count = 120;
for (int i=0;ipush_back(osg::Vec3(1+i/200.0, 1, 1+sin(i*M_PI/180.0)));
vertices->push_back(osg::Vec3(1+i/200.0, 2, 1+sin(i*M_PI/180.0)));
}

osg::ref_ptr normal = new osg::Vec3Array();
normal->push_back(osg::Vec3(0.0f, 0.0f, 1.0f));
osg::ref_ptr color = new osg::Vec4Array();
color->push_back(osg::Vec4(0,0,1,0.8f));

geometry = new osg::Geometry;
geometry->setDataVariance(osg::Object::DYNAMIC);
geometry->setUseDisplayList(false);
geometry->setVertexArray(vertices.get());
geometry->setNormalArray(normal.get());
geometry->setNormalBinding(osg::Geometry::BIND_OVERALL);
geometry->setColorArray(color.get());
geometry->setColorBinding(osg::Geometry::BIND_OVERALL);

drawArrays = new osg::DrawArrays(GL_TRIANGLE_STRIP, 0, vertices->size());
geometry->addPrimitiveSet(drawArrays);

osg::ref_ptr geode = new osg::Geode();
geode->addDrawable(geometry.get());
geode->getOrCreateStateSet()->setMode(GL_LIGHTING, 
osg::StateAttribute::OFF);

osg::ref_ptr root = new osg::Group();

root->addChild(geode.get());

root->addUpdateCallback(new UpdateVertex);

osgViewer::Viewer viewer;
viewer.setSceneData(root.get());
viewer.getCamera()->setSmallFeatureCullingPixelSize(0);
viewer.getCamera()->setClearColor(osg::Vec4(1,1,1,1));
viewer.addEventHandler(new osgViewer::StatsHandler);

viewer.realize();

return viewer.run();
}

And you can see what I get in the attachements.
If I press "S" to see number of vertices (thanks to StatsHandler), it is always 
increasing. So new vertices are added, but in (0,0,0) coordinates.
My guess is that geometry->dirtyBound(); is not working corectly.

I use master build of OSG.
On Windows I use x86 build with Visual Studio 2013.
On Linux Mint 18 Cinnamon 64-bit, I use x64 build with Qt Creator (GCC 64bit).

Hope that somebody have a clue to that issue.

Best regards,
Nikita

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




Attachments: 
http://forum.openscenegraph.org//files/2_123.png
http://forum.openscenegraph.org//files/1_632.png


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





Re: [osg-users] bug: osgText doesn't work on MacOSX GL4.x with VAO


2017-01-24

Thread
Sebastian Messerschmidt




Hi Remo

Hi Sebastian

I'm wondering if you have a running osgText on MacOSX Core Profile. Your 
shader-code is not compatible with it. I've written a partial working version 
of this shader. I also found that the Glyph Texture is created with red. But i 
think something is wrong with the texturecoordinates. I don't see any glyph.
I'm not using MacOSX, but I'm running on core profile under Windows and 
the shader seems to work for osgText there.



Code:
uniform sampler2D glyphTexture;
in vec2 texCoord;
out vec4 color;
void main()
{
  color = vertexColor * texture(glyphTexture, texCoord).r;
}


Basically the font should be white and modulated by the vertex color. I 
would have to dive into the implementation to see, why your information 
is in the red-channel. It might very well be, that the osgText is using 
GL_RED or something else which I can access via the .a swizzle in my 
driver.







I'm not sure the code of "Text::drawForegroundText" can work with VAO (It's 
required on MacOSX)
I'm not sure if the VAO path is used on my side. So I can't help you 
with this one.


Cheers
Sebastian


Here you find a draw dump from MacOSX:

[Image: http://forum.openscenegraph.org/files/dump_202.png ]

Cheers,
Remo[/img]

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





___
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: osgText doesn't work on MacOSX GL4.x with VAO


2017-01-21

Thread
Remo Eichenberger

Hi Sebastian,

Sorry, please ignore my post. The code is wrong. I need to test it first :)


Cheers,
Remo

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





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





Re: [osg-users] bug: osgText doesn't work on MacOSX GL4.x with VAO


2017-01-20

Thread
Remo Eichenberger

Hi Sebastian

Thank you for your help. Yes i don't see the glyphs. I use osgEarth, but this 
should not be a problem :)

I've tried the following according your sample:


Code:

ControlCanvas* canvas = ControlCanvas::getOrCreate( view );

view->getCamera()->getGraphicsContext()->getState()->setUseModelViewAndProjectionUniforms(true);

view->getCamera()->getGraphicsContext()->getState()->setUseVertexAttributeAliasing(true);

osg::ref_ptr texture = new osg::Texture2D;
osg::ref_ptr image = new osg::Image();
image->allocateImage(512, 512, 1, GL_RGBA, GL_UNSIGNED_BYTE);

texture->setImage(image);

view->getCamera()->getOrCreateStateSet()->setTextureAttributeAndModes(0, 
texture, osg::StateAttribute::ON);

LabelControl* label = new LabelControl();
osg::Program* textProgramObject = new osg::Program;
osg::Shader* textVertexObject =
new osg::Shader( osg::Shader::VERTEX );
osg::Shader* textFragmentObject =
new osg::Shader( osg::Shader::FRAGMENT );
textProgramObject->addShader( textFragmentObject );
textProgramObject->addShader( textVertexObject );
textFragmentObject->setShaderSource(frag);
textVertexObject->setShaderSource(vert);
label->getOrCreateStateSet()->setAttributeAndModes(textProgramObject, 
osg::StateAttribute::ON);

label->setTextBackdropType(osgText::Text::BackdropType::NONE);

label->setTextBackdropImplementation(osgText::Text::BackdropImplementation::DELAYED_DEPTH_WRITES);

label->setBackColor( Color( Color::Black, 0.8 ) );
label->setHorizAlign( Control::ALIGN_RIGHT );
label->setVertAlign( Control::ALIGN_BOTTOM );
label->setVisible( true );





But i don't see any glyphs.

Cheers,
Remo[/code]

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





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





Re: [osg-users] bug: osgText doesn't work on MacOSX GL4.x with VAO


2017-01-20

Thread
Sebastian Messerschmidt


Hi Remo,

A more detailed description on how it fails would be helpful.
If you're seeing non-textures quads instead of your glyphs you need to 
adapt your shader as the text-rendering isn't using a normal blending.
I've attached my default core-profile shader which uses pre-multiplied 
alpha.
Additionally I add a default sampler at camera root for the osg_Texture 
and I do:


for (auto index = 0u; index < mMainViewer->getNumViews(); ++index )
{
getCamera(index)->getGraphicsContext()->getState()->setUseModelViewAndProjectionUniforms(true);
getCamera(index)->getGraphicsContext()->getState()->setUseVertexAttributeAliasing(true);
}

nsRenderer::Helpers::addTexture( 
stats_handler->getCamera()->getOrCreateStateSet(), "osg_Texture",new 
osg::Texture2D(nsRenderer::Helpers::getDefaultImage(false)), 0);


Hope that helps
Sebastian

Hi,

I can't render osgText on MacOSX Core Profile:

text->setTextBackdropType(osgText::Text::BackdropType::NONE);
text->setTextBackdropImplementation(osgText::Text::BackdropImplementation::DELAYED_DEPTH_WRITES);
 
text->setBackColor( Color( Color::Black, 0.8 ) );

text->setHorizAlign( Control::ALIGN_RIGHT );
text->setVertAlign( Control::ALIGN_BOTTOM );
text->setVisible( true );

I've also tried to apply a default shader. But it doesn't work at all.
  
Cheers,

Remo

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





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


#version 440
#extension GL_ARB_enhanced_layouts : enable
#extension GL_ARB_separate_shader_objects : enable

layout (location=0) out vec4 FragmentData;

layout(location=1) in block
{
mediump vec2 tex_coord;
mediump vec4 color;
} In;

uniform sampler2D osg_Texture;

void main()
{
vec4 diffuse_color = In.color;
diffuse_color *=  texture2D(osg_Texture, In.tex_coord).a;

FragmentData = diffuse_color;
}#version 440
#extension GL_ARB_enhanced_layouts : enable
#extension GL_ARB_separate_shader_objects : enable

layout (location=0) in vec4 osg_Vertex;
layout (location=1) in vec3 osg_Normal;
layout (location=2) in vec4 osg_Color;
layout (location=3) in vec4 osg_MultiTexCoord0;
#ifdef HUD_CLIP_PLANES
layout(shared) uniform instanceData
{
vec4 clipPlane[6];
};
#endif

uniform mat4 osg_ModelViewMatrix;
uniform mat4 osg_ModelViewProjectionMatrix;
uniform mat4 TextureMatrix;

out gl_PerVertex
{
vec4 gl_Position;
};

layout(location=1) out block
{
mediump vec2 tex_coord;
mediump vec4 color;
} Out;

void main()
{
Out.color = osg_Color;
Out.tex_coord = vec4(osg_MultiTexCoord0).xy;
gl_Position = osg_ModelViewProjectionMatrix * osg_Vertex;

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





[osg-users] bug: osgText doesn't work on MacOSX GL4.x with VAO


2017-01-20

Thread
Remo Eichenberger

Hi,

I can't render osgText on MacOSX Core Profile:

text->setTextBackdropType(osgText::Text::BackdropType::NONE);
text->setTextBackdropImplementation(osgText::Text::BackdropImplementation::DELAYED_DEPTH_WRITES);

text->setBackColor( Color( Color::Black, 0.8 ) );
text->setHorizAlign( Control::ALIGN_RIGHT );
text->setVertAlign( Control::ALIGN_BOTTOM );
text->setVisible( true );

I've also tried to apply a default shader. But it doesn't work at all.
 
Cheers,
Remo

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





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





Re: [osg-users] bug: new OpenSceneGraph-3.5.5 threading...


2016-10-10

Thread
Christian Buchner

I can suggest three possible fixes in order of descending "cleanliness"

1)
You can tag your application using an application manifest that tells
Windows that the application
is DPI aware and handles all the scaling itself.

2)
Another possible fix is to force compatibility scaling individually per
executable in the Compatibility tab of the
Application properties ("Tell Windows not to scale an app that's not
DPI-aware")
https://technet.microsoft.com/en-us/library/dn528847.aspx?f=255=-2147217396

3)
Another possible fix is to tell Windows 10 to use a custom scaling of 100%
on your affected display
(Option #2 To Set Custom DPI Scaling Level for All Displays in Control
Panel)
http://www.tenforums.com/tutorials/5990-dpi-scaling-level-displays-change-windows-10-a.html


#3 might be quickest, but affects all applications
#2 has to be reapplied on every compilation of your binary
#1 seems to be the preferred solution because it sticks with the
application as it is applied on compilation

Christian


2016-10-08 23:25 GMT+02:00 Robert Osfield :

> Hi Li,
>
> I'm not a Windows expert so can't provide answers on Windows specific
> issues like this.  My guess Windows 10 has introduced some form of
> window scaling that the osgViewer isn't yet aware of so doesn't take
> account of.  To resolve this issue will require a Windows 10 dev to
> dive in an investigate.
>
> Robert.
>
> On 8 October 2016 at 18:31, Li Chi  wrote:
> > Hi,
> >
> > I tested the newest code, it works perfectly, thank you very much.
> >
> > Just another problem:
> > Under the windows 10 OS (may be other OS has the same result), when
> screen's TEXT SIZE isn't 100% (my computer's setting is 150%), the
> osgViewer.exe's full screen mode works a little odd. It just like some of
> the screen content is cutted, please see the attached screenshot picture.
> >
> > Thank you!
> >
> > Cheers,
> > Li
> >
> > --
> > Read this topic online here:
> > http://forum.openscenegraph.org/viewtopic.php?p=68915#68915
> >
> >
> >
> >
> > Attachments:
> > http://forum.openscenegraph.org//files/screenshot_970.jpg
> >
> >
> > ___
> > 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] bug: new OpenSceneGraph-3.5.5 threading...


2016-10-08

Thread
Robert Osfield

Hi Li,

I'm not a Windows expert so can't provide answers on Windows specific
issues like this.  My guess Windows 10 has introduced some form of
window scaling that the osgViewer isn't yet aware of so doesn't take
account of.  To resolve this issue will require a Windows 10 dev to
dive in an investigate.

Robert.

On 8 October 2016 at 18:31, Li Chi  wrote:
> Hi,
>
> I tested the newest code, it works perfectly, thank you very much.
>
> Just another problem:
> Under the windows 10 OS (may be other OS has the same result), when screen's 
> TEXT SIZE isn't 100% (my computer's setting is 150%), the osgViewer.exe's 
> full screen mode works a little odd. It just like some of the screen content 
> is cutted, please see the attached screenshot picture.
>
> Thank you!
>
> Cheers,
> Li
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=68915#68915
>
>
>
>
> Attachments:
> http://forum.openscenegraph.org//files/screenshot_970.jpg
>
>
> ___
> 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: new OpenSceneGraph-3.5.5 threading...


2016-10-08

Thread
Li Chi

Hi,

I tested the newest code, it works perfectly, thank you very much.

Just another problem:
Under the windows 10 OS (may be other OS has the same result), when screen's 
TEXT SIZE isn't 100% (my computer's setting is 150%), the osgViewer.exe's full 
screen mode works a little odd. It just like some of the screen content is 
cutted, please see the attached screenshot picture.

Thank you!

Cheers,
Li

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




Attachments: 
http://forum.openscenegraph.org//files/screenshot_970.jpg


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





Re: [osg-users] bug: new OpenSceneGraph-3.5.5 threading...


2016-10-08

Thread
Robert Osfield

HI Li,

Thanks for the stack trace.  I've spotted the bug.  The
osg::Camera::setCameraThread() method was setting attempting to set
the camera thread affinity even when the thread pointer was reset to
null.

I have just checked in a fix for this.  Could you try out the OSG git
master to double check it works fine.

Thanks,
Robert.

On 8 October 2016 at 13:16, Li Chi  wrote:
> Hi,
>
> I just tested standard osgviewer, all things seems good, not errors happed.
>
> CompositeViewer Crash Stack Trace Here:
>
> ot20-OpenThreadsd.dll!OpenThreads::Thread::setProcessorAffinity(const 
> OpenThreads::Affinity & affinity) Row 617 C++
> osg145-osgd.dll!osg::Camera::setCameraThread(osg::OperationThread * 
> gt) Row 553 C++
> osg145-osgViewerd.dll!osgViewer::ViewerBase::stopThreading() Row  336 
>   C++
> osg145-osgViewerd.dll!osgViewer::CompositeViewer::~CompositeViewer() 
> Row  106   C++
> [...]
> osgsidebysided.exe!main(int argc, char * * argv) Row 261C++
>
>
> Thank you!
>
> Cheers,
> Li
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=68913#68913
>
>
>
>
>
> ___
> 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: new OpenSceneGraph-3.5.5 threading...


2016-10-08

Thread
Li Chi

Hi,

I just tested standard osgviewer, all things seems good, not errors happed.

CompositeViewer Crash Stack Trace Here:

ot20-OpenThreadsd.dll!OpenThreads::Thread::setProcessorAffinity(const 
OpenThreads::Affinity & affinity) Row 617 C++
osg145-osgd.dll!osg::Camera::setCameraThread(osg::OperationThread * gt) 
Row 553 C++
osg145-osgViewerd.dll!osgViewer::ViewerBase::stopThreading() Row  336   
C++
osg145-osgViewerd.dll!osgViewer::CompositeViewer::~CompositeViewer() 
Row  106   C++
[...]   
osgsidebysided.exe!main(int argc, char * * argv) Row 261C++


Thank you!

Cheers,
Li

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





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





Re: [osg-users] bug: new OpenSceneGraph-3.5.5 threading...


2016-10-08

Thread
Robert Osfield

Hi Li,

Could you post the stack trace for the crash?

Does it happen with when you run standard osgviewer?

Robert.

On 7 October 2016 at 22:50, Li Chi  wrote:
> Hi,
>
> Running the attached source, when press 'ESC' key on a window to quit the 
> program, then the program crash down.
> Error In Win32Thread.cpp : setProcessorAffinity function
> Environment: Windows 10 / Visual Studio 2015
>
> Thank you!
>
> Cheers,
> Li
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=68909#68909
>
>
>
>
> Attachments:
> http://forum.openscenegraph.org//files/test_108.cpp
>
>
> ___
> 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] bug: new OpenSceneGraph-3.5.5 threading...


2016-10-08

Thread
Li Chi

Hi,

Running the attached source, when press 'ESC' key on a window to quit the 
program, then the program crash down.
Error In Win32Thread.cpp : setProcessorAffinity function
Environment: Windows 10 / Visual Studio 2015

Thank you!

Cheers,
Li

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




Attachments: 
http://forum.openscenegraph.org//files/test_108.cpp


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





Re: [osg-users] bug: Openscenegraph-3.4 branch install error with debug dll's on VS2013


2016-10-07

Thread
Robert Osfield

Hi Remo,

Could you please test OSG git master or the up coming 3.5.5 dev
release as they include a fix for the install error issue with VS.

Cheers,
Robert.

On 29 September 2016 at 15:57, Remo Eichenberger  wrote:
>
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=68827#68827
>
>
>
>
>
> ___
> 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] bug: Openscenegraph-3.4 branch install error with debug	dll's on VS2013


2016-09-29

Thread
Remo Eichenberger



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





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





Re: [osg-users] Bug touch point in win32


2016-05-31

Thread
Robert Osfield

Thanks Nguyen, fix merged and submitted git master.

On 25 April 2016 at 17:40, Nguyen Van Truong  wrote:
> I Use two touch screen in my App. I had a bug touch point in secondary
> screen ( the touch point not same mouse push point). My code repair
>
> case WM_TOUCH:
> /
> {
> unsigned int numInputs = (unsigned int) wParam;
> TOUCHINPUT* ti = new TOUCHINPUT[numInputs];
> POINT pt;
> osg::ref_ptr osg_event(NULL);
> if(getTouchInputInfoFunc &&
> (*getTouchInputInfoFunc)((HTOUCHINPUT)lParam, numInputs, ti,
> sizeof(TOUCHINPUT)))
> {
> // For each contact, dispatch the message to the
> appropriate message handler.
> for(unsigned int i=0; i< numInputs; ++i)
> {
> pt.x =TOUCH_COORD_TO_PIXEL(ti[i].x);
> pt.y =TOUCH_COORD_TO_PIXEL(ti[i].y);
> ScreenToClient(getHWND(), );
> if(ti[i].dwFlags & TOUCHEVENTF_DOWN)
> {
> if (!osg_event) {
> osg_event = getEventQueue()->touchBegan(
> ti[i].dwID, osgGA::GUIEventAdapter::TOUCH_BEGAN, pt.x, pt.y);
> } else {
> osg_event->addTouchPoint( ti[i].dwID,
> osgGA::GUIEventAdapter::TOUCH_BEGAN, pt.x, pt.y);
> }
> }
> else if(ti[i].dwFlags & TOUCHEVENTF_MOVE)
> {
> if (!osg_event) {
> osg_event = getEventQueue()->touchMoved(
> ti[i].dwID, osgGA::GUIEventAdapter::TOUCH_MOVED, pt.x, pt.y);
> } else {
> osg_event->addTouchPoint( ti[i].dwID,
> osgGA::GUIEventAdapter::TOUCH_MOVED, pt.x, pt.y);
> }
> }
> else if(ti[i].dwFlags & TOUCHEVENTF_UP)
> {
> // No double tap detection with RAW TOUCH
> Events, sorry.
> if (!osg_event) {
> osg_event = getEventQueue()->touchEnded(
> ti[i].dwID, osgGA::GUIEventAdapter::TOUCH_ENDED, pt.x, pt.y, 1);
> } else {
> osg_event->addTouchPoint( ti[i].dwID,
> osgGA::GUIEventAdapter::TOUCH_ENDED, pt.x, pt.y);
> }
> }
> }
> }
> if (closeTouchInputHandleFunc)
> (*closeTouchInputHandleFunc)((HTOUCHINPUT)lParam);
> delete [] ti;
> }
> break;
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org





[osg-users] bug in primitiveset.cpp?


2015-09-07

Thread
Julien Valentin

Hello all
I notice strange code at l231 of PrimitiveSet.cpp:
 
Code:
if (useVertexBufferObjects)
{
GLBufferObject* ebo = getOrCreateGLBufferObject(state.getContextID());
state.bindElementBufferObject(ebo);
if (ebo)
{
if (_numInstances>=1) state.glDrawElementsInstanced(mode, size(), 
GL_UNSIGNED_SHORT, (const GLvoid *)(ebo->getOffset(getBufferIndex())), 
_numInstances);
else glDrawElements(mode, size(), GL_UNSIGNED_SHORT, (const GLvoid 
*)(ebo->getOffset(getBufferIndex(;
}
else
{
if (_numInstances>=1) state.glDrawElementsInstanced(mode, size(), 
GL_UNSIGNED_SHORT, (), _numInstances);
else glDrawElements(mode, size(), GL_UNSIGNED_SHORT, ());
}
}
else



Does state.bindElementBufferObject(ebo); shouldn't be included in the if(ebo) 
test in case theres no index for the geometry?

Thank you!

Cheers,
Julien[/code]

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





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





Re: [osg-users] bug in primitiveset.cpp?


2015-09-07

Thread
Julien Valentin

Yes, it's a crash changing usevertexbufferobject at runtime that leads me to 
this observation:
bindElementBufferObject(0) crashes at if(ebo->isDirty())

Code:
inline void bindElementBufferObject(osg::GLBufferObject* ebo)
{
if (ebo == _currentEBO) return;
if (ebo->isDirty()) ebo->compileBuffer();
else ebo->bindBuffer();
_currentEBO = ebo;
}




robertosfield wrote:
> Hi Julien,
> 
> 
> I've just looked at the State::bindElementBufferObject(..) implementation and 
> it looks like it attempts to access the ebo even if the ptr is 0 which will 
> cause a crash.
> 
> 
> I'm guess this probably doesn't happen if the osg::Geometry is set up 
> correctly as the EBO should be created, as if useVertexBufferObjects is true 
> then the ebo "should" be non zero.  
> 
> 
> This doesn't mean that either the State::bindElementBufferObject(..) or the 
> DrawElements could should not be fixed though.
> 
> 
> Are you seeing a crash?
> 
> 
> 
> Robert.
> 
> 
> 
> Robert.
> 
> 
> On 7 September 2015 at 18:45, Julien Valentin < ()> wrote:
> 
> > Hello all
> > I notice strange code at l231 of PrimitiveSet.cpp:
> > 
> > Code:
> > if (useVertexBufferObjects)
> >     {
> >         GLBufferObject* ebo = 
> > getOrCreateGLBufferObject(state.getContextID());
> >         state.bindElementBufferObject(ebo);
> >         if (ebo)
> >         {
> >             if (_numInstances>=1) state.glDrawElementsInstanced(mode, 
> > size(), GL_UNSIGNED_SHORT, (const GLvoid 
> > *)(ebo->getOffset(getBufferIndex())), _numInstances);
> >             else glDrawElements(mode, size(), GL_UNSIGNED_SHORT, (const 
> > GLvoid *)(ebo->getOffset(getBufferIndex(;
> >         }
> >         else
> >         {
> >             if (_numInstances>=1) state.glDrawElementsInstanced(mode, 
> > size(), GL_UNSIGNED_SHORT, (), _numInstances);
> >             else glDrawElements(mode, size(), GL_UNSIGNED_SHORT, ());
> >         }
> >     }
> >     else
> > 
> > 
> > 
> > Does state.bindElementBufferObject(ebo); shouldn't be included in the 
> > if(ebo) test in case theres no index for the geometry?
> > 
> > Thank you!
> > 
> > Cheers,
> > Julien[/code]
> > 
> > --
> > Read this topic online here:
> > http://forum.openscenegraph.org/viewtopic.php?p=65052#65052 
> > (http://forum.openscenegraph.org/viewtopic.php?p=65052#65052)
> > 
> > 
> > 
> > 
> > 
> > ___
> > osg-users mailing list
> >  ()
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org 
> > (http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org)
> > 
> 
> 
>  --
> Post generated by Mail2Forum


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





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





Re: [osg-users] bug in primitiveset.cpp?


2015-09-07

Thread
Robert Osfield

Hi Julien,

I've just looked at the State::bindElementBufferObject(..) implementation
and it looks like it attempts to access the ebo even if the ptr is 0 which
will cause a crash.

I'm guess this probably doesn't happen if the osg::Geometry is set up
correctly as the EBO should be created, as if useVertexBufferObjects is
true then the ebo "should" be non zero.

This doesn't mean that either the State::bindElementBufferObject(..) or the
DrawElements could should not be fixed though.

Are you seeing a crash?

Robert.

Robert.

On 7 September 2015 at 18:45, Julien Valentin 
wrote:

> Hello all
> I notice strange code at l231 of PrimitiveSet.cpp:
>
> Code:
> if (useVertexBufferObjects)
> {
> GLBufferObject* ebo =
> getOrCreateGLBufferObject(state.getContextID());
> state.bindElementBufferObject(ebo);
> if (ebo)
> {
> if (_numInstances>=1) state.glDrawElementsInstanced(mode,
> size(), GL_UNSIGNED_SHORT, (const GLvoid
> *)(ebo->getOffset(getBufferIndex())), _numInstances);
> else glDrawElements(mode, size(), GL_UNSIGNED_SHORT, (const
> GLvoid *)(ebo->getOffset(getBufferIndex(;
> }
> else
> {
> if (_numInstances>=1) state.glDrawElementsInstanced(mode,
> size(), GL_UNSIGNED_SHORT, (), _numInstances);
> else glDrawElements(mode, size(), GL_UNSIGNED_SHORT, ());
> }
> }
> else
>
>
>
> Does state.bindElementBufferObject(ebo); shouldn't be included in the
> if(ebo) test in case theres no index for the geometry?
>
> Thank you!
>
> Cheers,
> Julien[/code]
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=65052#65052
>
>
>
>
>
> ___
> 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 Viewer::setReferenceTime


2015-06-07

Thread
Robert Osfield

Hi Benjamin,

Well spotted, can't believe how long that bug will have been lurking
without being picked up.  I've applied your suggested fix to
CompositeViewer and Viewer in OSG-svn/trunk and the OSG-3.2 branch.

Cheers,
Robert.

On 6 June 2015 at 21:44, Benjamin Richter b...@waldteufel.eu wrote:
 Hi everybody.

 I was having some trouble with Viewer::setReferenceTime today and while
 debugging found the issue in the following line [1]

 double delta_ticks =
 (time-currentTime)*(osg::Timer::instance()-getSecondsPerTick());

 As currentTime and time are given in seconds (see link below for context)
 but the result should be in ticks, dividing by getSecondsPerTick would be
 correct.

 (Apart from that: Thank you for this great library :D)

 Regards
 Benjamin

 [1]
 https://github.com/openscenegraph/osg/blob/3c55e5bc765aff03ed0850ef9b9b62dc6aabe6a8/src/osgViewer/Viewer.cpp#L446
 ___
 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] Bug in Viewer::setReferenceTime


2015-06-06

Thread
Benjamin Richter


Hi everybody.

I was having some trouble with Viewer::setReferenceTime today and while 
debugging found the issue in the following line [1]


double delta_ticks = 
(time-currentTime)*(osg::Timer::instance()-getSecondsPerTick());


As currentTime and time are given in seconds (see link below for 
context) but the result should be in ticks, dividing by 
getSecondsPerTick would be correct.


(Apart from that: Thank you for this great library :D)

Regards
Benjamin

[1] 
https://github.com/openscenegraph/osg/blob/3c55e5bc765aff03ed0850ef9b9b62dc6aabe6a8/src/osgViewer/Viewer.cpp#L446

___
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


2015-02-05

Thread
Robert Osfield

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


2015-02-05

Thread
Dan Shebounin

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


2015-02-05

Thread
Dan Shebounin

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] Bug in OSG? getMatrix() and setByMatrix() is not enough to transrer camera state


2015-02-05

Thread
Robert Osfield

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





[osg-users] Bug in OSG? getMatrix() and setByMatrix() is not enough	to transrer camera state


2015-02-05

Thread
Dan Shebounin

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] Bug in Collada reader


2014-12-23

Thread
Robert Osfield

Hi Mark,

Thanks for the rest model.  I have finally had the time to look into this
issue and have resolved it by added a fallback of reading the color array
as a Vec3Array if only rgb colours are available.  The fix is checked into
svn/trunk.

Cheers,
Robert.

On 27 March 2014 at 14:35, Bolstad, Mark bolst...@janelia.hhmi.org wrote:

 While trying to map some functionality to color per vertex, I came across
 a bug in that colors aren't loaded properly.

 At daeReader::resolveMeshArrays:931 (daeRGeometry.cpp) it calls out to
 createGeometryArrays with types of Vec4Array. If you trace this down into
 the daeSourceReader call to getArray, you'll find that it reads the data
 into a Vec3Array, then returns the Vec4Array resulting in no colors.

 Anyone have a quick fix? (I'm currently attempting to change the array to
 Vec3, then convert it to a Vec4 in resolve MeshArrays).

 Attached is a small collada file created in Blender that shows the problem.

 Mark

 ___
 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: osgGA::GUIEventAdapter returns wrong mouse ranges on android


2014-06-17

Thread
Robert Osfield

Hi Paul,

The osgGA::GUIEventAdapter has an MouseYOrientation value that
provides information on which way up the Y axis is.  OpenGL has Y
going up, while most UI toolkits have Y going down, to handle this
discrepency osgGA::GUIEventAdapter provides the MouseYOrigentation and
other utilities adapt it to make sure it's in the correct default OSG
orientation which is Y up - consistent with OpenGL.

Robert.

On 17 June 2014 01:48, Paul aquawic...@hotmail.com wrote:
 I can confirm this issue.

 For android I use setUpViewerAsEmbeddedInWindow(0, 0, width, height)
 and then setMouseInputRange(0, 0, width, height). I then send the input via 
 getEventQueue()-mouseButtonPress(x, y, button); The input coordinates from 
 android seem to be correct at this point, although it's flipped on the y 
 axis. Now, when I catch and use the events to use in OSG, the coordinates are 
 off.  Is there an easy fix?

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





 ___
 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: osgGA::GUIEventAdapter returns wrong mouse	ranges on android


2014-06-16

Thread
Paul

I can confirm this issue. 

For android I use setUpViewerAsEmbeddedInWindow(0, 0, width, height)
and then setMouseInputRange(0, 0, width, height). I then send the input via 
getEventQueue()-mouseButtonPress(x, y, button); The input coordinates from 
android seem to be correct at this point, although it's flipped on the y axis. 
Now, when I catch and use the events to use in OSG, the coordinates are off.  
Is there an easy fix?

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





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





Re: [osg-users] [BUG?] OSG traits without window decoration


2014-06-04

Thread
Marco Kliko

Hi,

Guys, I got the solution.
Thanks a lot for all your help!

The code is right now like this:

Code:

void init_viewer(osgViewer::Viewer* Viewer, int x, int y, int width, int height)
{
scene = osgDB::readNodeFile(d:/OpenSceneGraph-Data/cessna.osg);

Viewer-setSceneData(scene);
Viewer-setUpViewInWindow(x, y, width, height);
Viewer-addEventHandler(new KeyboardEventHandler());

//get window handle to remove the borders and later on for minimizim 
and restoring the OSG-window.
gw = dynamic_castosgViewer::GraphicsWindowWin32* 
(viewer-getCamera()-getGraphicsContext());
//this is the window handle
hWnd = gw-getHWND();   

//remove the buttons (minimize, restore and close)
LONG lStyle = GetWindowLong(hWnd, GWL_STYLE);   
lStyle = ~(WS_CAPTION | WS_THICKFRAME | WS_MINIMIZE | WS_MAXIMIZE | 
WS_SYSMENU);
SetWindowLong(hWnd, GWL_STYLE, lStyle);

//remove the window borders
LONG lExStyle = GetWindowLong(hWnd, GWL_EXSTYLE); 
lExStyle = ~(WS_EX_DLGMODALFRAME | WS_EX_CLIENTEDGE | 
WS_EX_STATICEDGE);
SetWindowLong(hWnd, GWL_EXSTYLE, lExStyle); 
}


void makeViewerVisible()
{
ShowWindow(hWnd, SW_RESTORE);
}

void makeViewerInvisible()
{
ShowWindow(hWnd, SW_MINIMIZE);
}





This works exactly how I wanted.
Instead of trying it from the OSG side, I let the window handle take care of 
removing the borders and hide/show the window.
The only thing that was needed is to get the windows handle from OSG. Then let 
windows do the magic.

Thanks you again!

Cheers,
Marco[/code]

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





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





Re: [osg-users] [BUG?] OSG traits without window decoration


2014-06-02

Thread
Marco Kliko


Trajce Nikolov NICK wrote:
 Hi
 
 
 
  So when the window is not visible, I would prefer to pause the rendering of 
  the model instead of destroying it.
  
 
 
 You can control the rendering loop by calling viewer-frame() whenever you 
 need. In some sort of similar application in the past I used timer to render 
 the frame and when not needed I killed the timer and reset when needed again. 
 If you are under windows you can send messages like WM_SHOW/WM_HIDE directly 
 to your HWND or set the windows style WS_VISIBLE, that how I controlled the 
 visibility of the window
 
 
 Nick
 


Hi Nick,

Thanks for your reaction. I want to try the WM_SHOW/WM_HIDE thingy.
But how do I get a HWND of the viewer?

I have found a website where they create a osg-window with an window handle.
http://my.safaribooksonline.com/book/animation-and-3d/9781849512824/interacting-with-outside-elements/ch09lvl1sec13
But I don't understand it completely. I believe parts of the code are missing. 
Am I correct?
I see the point to read it all and writing your own code instead of just 
copying it. But I am not experienced with window handles and I am having 
trouble seeing the big picture here.

Can somebody help me with this?

Thanks in advance!

Marco

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





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





Re: [osg-users] [BUG?] OSG traits without window decoration


2014-06-02

Thread
Trajce Nikolov NICK

Hi Marco,

 But how do I get a HWND of the viewer?

if (_viewer.valid())
{
osgViewer::CompositeViewer::Windows wins;
_viewer-getWindows(wins);
#ifdef WIN32
if (wins.size())
{
osgViewer::GraphicsHandleWin32 *hdl =
dynamic_castosgViewer::GraphicsHandleWin32*(wins.at(0));
if(hdl)
{
MSG* message = (MSG*)msg;
WNDPROC fWndProc = (WNDPROC)::GetWindowLongPtr(hdl-getHWND(),
GWLP_WNDPROC);
fWndProc(hdl-getHWND(), message-message, message-wParam,
message-lParam);
}
}
#endif
}

you have to construct your MSG message .. this is a snippet from my app

Hope it helps

Nick


On Mon, Jun 2, 2014 at 11:32 AM, Marco Kliko marco_kl...@hotmail.com
wrote:


 Trajce Nikolov NICK wrote:
  Hi
 
 
 
   So when the window is not visible, I would prefer to pause the
 rendering of the model instead of destroying it.
  
 
 
  You can control the rendering loop by calling viewer-frame() whenever
 you need. In some sort of similar application in the past I used timer to
 render the frame and when not needed I killed the timer and reset when
 needed again. If you are under windows you can send messages like
 WM_SHOW/WM_HIDE directly to your HWND or set the windows style WS_VISIBLE,
 that how I controlled the visibility of the window
 
 
  Nick
 


 Hi Nick,

 Thanks for your reaction. I want to try the WM_SHOW/WM_HIDE thingy.
 But how do I get a HWND of the viewer?

 I have found a website where they create a osg-window with an window
 handle.

 http://my.safaribooksonline.com/book/animation-and-3d/9781849512824/interacting-with-outside-elements/ch09lvl1sec13
 But I don't understand it completely. I believe parts of the code are
 missing. Am I correct?
 I see the point to read it all and writing your own code instead of just
 copying it. But I am not experienced with window handles and I am having
 trouble seeing the big picture here.

 Can somebody help me with this?

 Thanks in advance!

 Marco

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





 ___
 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] [BUG?]


2014-05-27

Thread
Marco Kliko

Hi everybody,

I have found a possible bug in OSG. But maybe I am using OSG wrong.
Hopefully someone can help me finding a solution.

Here's the case:
I want to use OSG for 3D rendering a model that I use in my own software 
programm. To embed the OSG window in my program, I want to put it on top of 
the page that normally shows the 3D-model.
When I'm not displaying the page, I want to stop/pause  the rendering task and 
put the window outside my screen (pos -1000, -1000 or something).

At first, I tried it with 

Code:
Viewer-stopThreading();
Viewer-setUpViewInWindow(-1000, -1000, 640, 480);
Viewer-startThreading();


to remove the window and

Code:
Viewer-stopThreading();
Viewer-setUpViewInWindow(x,y,width,height);
Viewer-startThreading();


to show the window again.

Somewhere else in my code I have a if-condition that checks if I need to render 
new pages.

Code:

if(page_visible)
{
viewer-frame();
}




This is working fine and actually was really suprised how quick it was. Kudo's 
to OSG!

But now I want the same window, but without the windows decoration. Because 
when I use it on top of my own software, I want it it to have it look it's 
embedded in the programm. This means that it has no windows-boarders around the 
osg-window. Also the minimize, restore and close buttons on the right top 
corner are gone too.

I found out this could be done with traits. But when I replace 
setUpViewInWindow with traits I doesn't work like I expected.
At first, the viewer comes, but without keyboard input. (This used to work with 
setUpViewInWindow).
But then when I call makeViewerInvisible, the window leaves the screen-area. So 
that is fine.
Then I call makeViewerVisible, and then the window doesn't show up.
When I add a breakpoint at the start of makeViewerInvisible, the window appear 
in a flash, to disappear again.

I hope you guys can reproduce this bug. (If it is a bug of course...)

Here's the code:


Code:


//at init
//please not, this is now a standalone project to test if it works, so at init, 
I make the viewer visible.

void interfaceOSG::init_viewer(osgViewer::Viewer* Viewer, int x, int y, int 
width, int height)
{

scene = osgDB::readNodeFile(d:/OpenSceneGraph-Data/cessna.osg);
Viewer-setCameraManipulator(new osgGA::TrackballManipulator());

Viewer-setSceneData(scene);
/*Viewer-setUpViewInWindow(x, y, width, height);*/

traits-x = x; //in screen space
traits-y = y; //in screen space
traits-width = width;
traits-height = height;
traits_das-windowDecoration = false; // Removes the window's border

osg::ref_ptrosg::GraphicsContext graphicsContext = 
osg::GraphicsContext::createGraphicsContext(traits_das.get());

viewer-getCamera()-setGraphicsContext(graphicsContext);
viewer-getCamera()-setViewport(new osg::Viewport(0, 0, 640, 480)); 
Viewer-addEventHandler(new KeyboardEventHandler());
}

void interfaceOSG::makeViewerVisible(osgViewer::Viewer* Viewer, int x, int y, 
int width, int height)
{
Viewer-stopThreading();
traits-x = x; 
traits-y = y;
traits-width = width;
traits-height = height;
traits-windowDecoration = false; // Removes the window's border

osg::ref_ptrosg::GraphicsContext graphicsContext = 
osg::GraphicsContext::createGraphicsContext(traits_das.get());

viewer-getCamera()-setGraphicsContext(graphicsContext);
viewer-getCamera()-setViewport(new osg::Viewport(0, 0, 640, 480)); 
Viewer-startThreading();
}

void interfaceOSG::makeViewerInvisible(osgViewer::Viewer* Viewer)
{
Viewer-stopThreading();
//Viewer-setUpViewInWindow(-1000, -1000, 640, 480);
traits-x = -1000; 
traits-y = -1000;
traits-width = 640;
traits-height = 480;
traits-windowDecoration = false; // Removes the window's border

osg::ref_ptrosg::GraphicsContext graphicsContext = 
osg::GraphicsContext::createGraphicsContext(traits_das.get());

viewer-getCamera()-setGraphicsContext(graphicsContext);
viewer-getCamera()-setViewport(new osg::Viewport(0, 0, 640, 480)); 

Viewer-startThreading();
}





If I wasn't clear enought about something, please do not hesitate to ask me 
more info. I'll gladly try to explain it further.  :) 

I hope you guys can help me. If I can't make this work, OSG will sadly be a big 
showstopper for my program... :| 

Thank you!

Cheers,
Marco

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





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





Re: [osg-users] [BUG?] OSG traits without window decoration


2014-05-27

Thread
Marco Kliko

Hello Robert,

Thanks for your quick reply! I really appreciate it!  :D 

Could you please tell me where (or on which line) I destroy the graphics window?
(Just to prevent I make the same mistake in the future...)

Ok, let me explain what the situation is.

I have a software application that needs a new module/extension that will 
include a 3D-model. 
This 3D model I want to create with OSG. This 3D model shows an object that is 
controlled by this application. 
(it represents the current state of it, like the angle of an arm or something)

As our applcation has multiple pages, the OSG window only should be visible 
when the page is active that needs to show the 3D-model.
I had in mind to put the osg window on top of the apllication page. Combining 
this without the windowDecoration, this could look like it is embedded in the 
application.

What I need is a function to let a windows without windowDecoration appear and 
a function to let a window disappear. 

Everytime the window needs to appear again, I don't want to create a window and 
load the complete model again.
The model is pretty big and complex, so it takes some time to load it.
So when the window is not visible, I would prefer to pause the rendering of the 
model instead of destroying it.
I want to pause the rendering to prevent using (a lot of) resources that I am 
not using while the viewer is not displayed on screen.

I hope I cleared up some confusion about what I am trying to achieve.

Thanks again for all your help!

Marco


robertosfield wrote:
 Hi Marco,
 
 I doubt what you are seeing is a bug in the OSG, rather a
 manifestation of trying to do something is crazy way.  It seems you
 are trying to hide a window by putting it off screen, but even more
 odd you are destroying the graphics window and then recreating it off
 screen, but would you need to create something you are not going to
 see.  It's perplexing trying to work out what you really intend.
 
 Might I suggest you explain in simple terms how you want your
 application to behave and let others in the community suggest how best
 to achieve this.
 
 Robert.
 
 ___
 osg-users mailing list
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
___
osg-users mailing list

http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

 --
Post generated by Mail2Forum[/quote]

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





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





Re: [osg-users] [BUG?] OSG traits without window decoration


2014-05-27

Thread
Daniel Trstenjak


Hi Marco,

On Tue, May 27, 2014 at 10:11:32AM +0200, Marco Kliko wrote:
 As our applcation has multiple pages, the OSG window only should be
 visible when the page is active that needs to show the 3D-model.  I
 had in mind to put the osg window on top of the apllication page.
 Combining this without the windowDecoration, this could look like it
 is embedded in the application.
 
 What I need is a function to let a windows without windowDecoration
 appear and a function to let a window disappear. 

That should be the job of the gui toolkit you're using. Normally you
have a special widget which supports the rendering with OpenGL.

By using this OpenGL widget on one page, the toolkit should take for
everything else when you're changing the pages. 


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





Re: [osg-users] [BUG?] OSG traits without window decoration


2014-05-27

Thread
Daniel Trstenjak


Hi Marco,

On Tue, May 27, 2014 at 11:01:36AM +0200, Marco Kliko wrote:
 I think I understand what you mean but I have no idea what to search for.
 Could you be so kind to give me a link to an example describing your proposal?
 Or some keywords to search for?

I would directly search for OpenGL inside of the documentation for your toolkit.

For Qt it's e.g.: http://qt-project.org/doc/qt-5/qtopengl-hellogl-example.html


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





Re: [osg-users] [BUG?] OSG traits without window decoration


2014-05-27

Thread
Marco Kliko

Daniel,

Thanks for sharing your thought.
But these widgets are implemented inside a Qt-enivronment application.
Am I right?
The environment of the application I am working with doesn't allow adding a 
widget in the window. 
It's a sort of selfmade environment that's why I want to put the OSG-window on 
top of my application.

I hope you understand what I mean.

Thanks a lot in advance,

Marco


Daniel Trstenjak wrote:
 Hi Marco,
 
 I would directly search for OpenGL inside of the documentation for your 
 toolkit.
 
 For Qt it's e.g.: http://qt-project.org/doc/qt-5/qtopengl-hellogl-example.html
 
 
 Greetings,
 Daniel
 ___
 osg-users mailing list
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
  --
 Post generated by Mail2Forum


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





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





Re: [osg-users] [BUG?] OSG traits without window decoration


2014-05-27

Thread
Trajce Nikolov NICK

Hi

 So when the window is not visible, I would prefer to pause the rendering
of the model instead of destroying it.

You can control the rendering loop by calling viewer-frame() whenever you
need. In some sort of similar application in the past I used timer to
render the frame and when not needed I killed the timer and reset when
needed again. If you are under windows you can send messages like
WM_SHOW/WM_HIDE directly to your HWND or set the windows style WS_VISIBLE,
that how I controlled the visibility of the window

Nick


On Tue, May 27, 2014 at 4:22 PM, Marco Kliko marco_kl...@hotmail.comwrote:

 Daniel,

 Thanks for sharing your thought.
 But these widgets are implemented inside a Qt-enivronment application.
 Am I right?
 The environment of the application I am working with doesn't allow adding
 a widget in the window.
 It's a sort of selfmade environment that's why I want to put the
 OSG-window on top of my application.

 I hope you understand what I mean.

 Thanks a lot in advance,

 Marco


 Daniel Trstenjak wrote:
  Hi Marco,
 
  I would directly search for OpenGL inside of the documentation for your
 toolkit.
 
  For Qt it's e.g.:
 http://qt-project.org/doc/qt-5/qtopengl-hellogl-example.html
 
 
  Greetings,
  Daniel
  ___
  osg-users mailing list
 
 
 http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
 
   --
  Post generated by Mail2Forum


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





 ___
 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] BUG: osgGA::GUIEventAdapter returns wrong mouse ranges	on android


2014-05-06

Thread
Martin Siggel

Dear OSG users,

the methods
GUIEventAdapter.getXmin,
GUIEventAdapter.getXmax,
GUIEventAdapter.getYmin,
GUIEventAdapter.getYmax ...

always return mouse input ranges of -1...1 instead of e.g. 0...1280,
0...800. Because of this bug, the standard picking handler is not working.
The viewer is created by calling viewer-setUpViewerAsEmbeddedInWindow as
done in the android demo.

This also happens, even if eventQueue-setMouseInputRange is called with
the appropriate screen dimensions.

Is there another way to tell the eventqueue, what the input ranges are?

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





[osg-users] Bug in Collada reader


2014-03-27

Thread
Bolstad, Mark

While trying to map some functionality to color per vertex, I came across a bug 
in that colors aren’t loaded properly.

At daeReader::resolveMeshArrays:931 (daeRGeometry.cpp) it calls out to 
createGeometryArrays with types of Vec4Array. If you trace this down into the 
daeSourceReader call to getArray, you’ll find that it reads the data into a 
Vec3Array, then returns the Vec4Array resulting in no colors.

Anyone have a quick fix? (I’m currently attempting to change the array to Vec3, 
then convert it to a Vec4 in resolve MeshArrays).

Attached is a small collada file created in Blender that shows the problem.

Mark


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





Re: [osg-users] Bug in Collada reader


2014-03-27

Thread
Trajce Nikolov NICK

from what you are stating if the color array is Vec4Array in creation you
should cast to the same in the reading portion - I guess the 4th component
is alpha of the color which is the proper way to have the colors stored. So
the fix would be casting to Vec4array in the reading part to get valid
array object

Nick


On Thu, Mar 27, 2014 at 3:35 PM, Bolstad, Mark bolst...@janelia.hhmi.orgwrote:

 While trying to map some functionality to color per vertex, I came across
 a bug in that colors aren't loaded properly.

 At daeReader::resolveMeshArrays:931 (daeRGeometry.cpp) it calls out to
 createGeometryArrays with types of Vec4Array. If you trace this down into
 the daeSourceReader call to getArray, you'll find that it reads the data
 into a Vec3Array, then returns the Vec4Array resulting in no colors.

 Anyone have a quick fix? (I'm currently attempting to change the array to
 Vec3, then convert it to a Vec4 in resolve MeshArrays).

 Attached is a small collada file created in Blender that shows the problem.

 Mark

 ___
 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 Collada reader


2014-03-27

Thread
Trajce Nikolov NICK

I read the code fast, actually it is the other way around I think. In the
reader it should read Vec4Array. Can you point me to the reading part
(file:line) where to look?

Nick


On Thu, Mar 27, 2014 at 4:21 PM, Trajce Nikolov NICK 
trajce.nikolov.n...@gmail.com wrote:

 from what you are stating if the color array is Vec4Array in creation you
 should cast to the same in the reading portion - I guess the 4th component
 is alpha of the color which is the proper way to have the colors stored. So
 the fix would be casting to Vec4array in the reading part to get valid
 array object

 Nick


 On Thu, Mar 27, 2014 at 3:35 PM, Bolstad, Mark 
 bolst...@janelia.hhmi.orgwrote:

 While trying to map some functionality to color per vertex, I came across
 a bug in that colors aren't loaded properly.

 At daeReader::resolveMeshArrays:931 (daeRGeometry.cpp) it calls out to
 createGeometryArrays with types of Vec4Array. If you trace this down into
 the daeSourceReader call to getArray, you'll find that it reads the data
 into a Vec3Array, then returns the Vec4Array resulting in no colors.

 Anyone have a quick fix? (I'm currently attempting to change the array to
 Vec3, then convert it to a Vec4 in resolve MeshArrays).

 Attached is a small collada file created in Blender that shows the
 problem.

 Mark

 ___
 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] Bug in initial renderer compile?


2014-01-24

Thread
Robert Osfield

Hi Michael,

On 24 January 2014 07:08, Michael Jensen mich...@ifad.dk wrote:

 Yes you may suggest upgrading to 3.2 ;-). It is indeed a good time since
 we have shipped our product to the customer and it will be a while until
 the next release. We are using osgEarth, osgBullet (and thus osgWorks) so
 we have a lot of rebuilding ahead of us, though.


I would suggest upgrading to 3.2.1 once I tag it as it'll contain the
object compilation bug fix.

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 initial renderer compile?


2014-01-24

Thread
Michael Jensen

Ok. I will do that.

Michael


On Fri, Jan 24, 2014 at 9:55 AM, Robert Osfield robert.osfi...@gmail.comwrote:

 Hi Michael,

 On 24 January 2014 07:08, Michael Jensen mich...@ifad.dk wrote:

 Yes you may suggest upgrading to 3.2 ;-). It is indeed a good time since
 we have shipped our product to the customer and it will be a while until
 the next release. We are using osgEarth, osgBullet (and thus osgWorks) so
 we have a lot of rebuilding ahead of us, though.


 I would suggest upgrading to 3.2.1 once I tag it as it'll contain the
 object compilation bug fix.

 Robert.




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




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





Re: [osg-users] Bug in initial renderer compile?


2014-01-23

Thread
Robert Osfield

Thanks for the example Michael.  Using this example I recreated the problem
with svn/trunk and fixed it by adding a clean up of an osg::Program that
are applied during the GLObjectVisitor traversal.  I have checked the fix
into svn/trunk and OSG-3.2 branch.  I have also attached a diff file of the
changes.  Might I suggest this would be a good time to try out the OSG-3.2
branch or svn/trunk :-)


On 23 January 2014 07:46, Michael Bach Jensen mich...@ifad.dk wrote:

 Hi Robert and Nick,

 It does very much look like a missing cleanup after compilation.

 The following things need to be present:
 - a geometry shader
 - a uniform
 - rendering the node using the above after an object that is not
 compatible with the shader program.

 I have attached a modified version of osgshape.cpp that causes the failure.

 Thank you for looking into it!

 Cheers,
 Michael

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




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


Index: src/osgUtil/GLObjectsVisitor.cpp
===
--- src/osgUtil/GLObjectsVisitor.cpp(revision 14023)
+++ src/osgUtil/GLObjectsVisitor.cpp(working copy)
@@ -31,19 +31,31 @@
 
 }
 
-
 void GLObjectsVisitor::apply(osg::Node node)
 {
+bool programSetBefore = _lastCompiledProgram.valid();
+
 if (node.getStateSet())
 {
 apply(*(node.getStateSet()));
 }
 
 traverse(node);
+
+bool programSetAfter = 
_renderInfo.getState()-getLastAppliedProgramObject()!=0;
+if (programSetBefore  !programSetAfter)
+{
+osg::GL2Extensions* extensions = 
osg::GL2Extensions::Get(_renderInfo.getState()-getContextID(), true);
+extensions-glUseProgram(0);
+_renderInfo.getState()-setLastAppliedProgramObject(0);
+_lastCompiledProgram = 0;
+}
 }
 
 void GLObjectsVisitor::apply(osg::Geode node)
 {
+bool programSetBefore = _lastCompiledProgram.valid();
+
 if (node.getStateSet())
 {
 apply(*(node.getStateSet()));
@@ -61,6 +73,15 @@
 }
 }
 }
+
+bool programSetAfter = _lastCompiledProgram.valid();
+if (!programSetBefore  programSetAfter)
+{
+osg::GL2Extensions* extensions = 
osg::GL2Extensions::Get(_renderInfo.getState()-getContextID(), true);
+extensions-glUseProgram(0);
+_renderInfo.getState()-setLastAppliedProgramObject(0);
+_lastCompiledProgram = 0;
+}
 }
 
 void GLObjectsVisitor::apply(osg::Drawable drawable)
@@ -159,7 +180,7 @@
 
 /
 //
-// GLObjectsVisitor
+// GLObjectsOperation
 //
 
 GLObjectsOperation::GLObjectsOperation(GLObjectsVisitor::Mode mode):
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org





Re: [osg-users] Bug in initial renderer compile?


2014-01-23

Thread
Michael Jensen

You are welcome, Robert. And thank you for providing a patch. It worked
like a charm! :-)

Yes you may suggest upgrading to 3.2 ;-). It is indeed a good time since we
have shipped our product to the customer and it will be a while until the
next release. We are using osgEarth, osgBullet (and thus osgWorks) so we
have a lot of rebuilding ahead of us, though.

Thank you,

Michael


On Thu, Jan 23, 2014 at 10:44 AM, Robert Osfield
robert.osfi...@gmail.comwrote:

 Thanks for the example Michael.  Using this example I recreated the
 problem with svn/trunk and fixed it by adding a clean up of an osg::Program
 that are applied during the GLObjectVisitor traversal.  I have checked the
 fix into svn/trunk and OSG-3.2 branch.  I have also attached a diff file of
 the changes.  Might I suggest this would be a good time to try out the
 OSG-3.2 branch or svn/trunk :-)


 On 23 January 2014 07:46, Michael Bach Jensen mich...@ifad.dk wrote:

 Hi Robert and Nick,

 It does very much look like a missing cleanup after compilation.

 The following things need to be present:
 - a geometry shader
 - a uniform
 - rendering the node using the above after an object that is not
 compatible with the shader program.

 I have attached a modified version of osgshape.cpp that causes the
 failure.

 Thank you for looking into it!

 Cheers,
 Michael

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




 ___
 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




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





[osg-users] Bug in initial renderer compile?


2014-01-22

Thread
Michael Bach Jensen

Hi,

During development of a new shader-based point-rendering system I started 
getting INVALID_OPERATION at start of State::apply(StateSet*) for the first 
rendered frame (subsequent frames are OK).

The scene consists of a geode, shapedrawable box (no stateset/fixed function 
pipeline) and the point rendering node (shader pipeline) both under the same 
parent group. When rendering, the box is drawn before the points.

It turned out to be due to my point shader being active for the box. The shader 
becomes active (by mistake?) as a result of the renderer calling compile().

Adding a stateset to the box node with an empty program fixes the issue since 
it forces fixed function into effect before drawing the box.

It would be nice to avoid this initial INVALID_OPERATION message.

Has anyone else encountered this or something similar? It looks like a bug to 
me. What do you think?

Thank you!

Cheers,
Michael

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





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





Re: [osg-users] Bug in initial renderer compile?


2014-01-22

Thread
Robert Osfield

Hi Micahel,

It could be a big with the GLCompileVisitor not cleaning up on the state
it's compiling.  Could you create a small example that illustrates this
problem - such as modifiying one the OSG examples such as osgshape so it
can reproduce the error.  With such an example I can then step through what
is being set and work out what might be going on, and what needs to be done
to address the issue.

Robert.


On 22 January 2014 10:33, Michael Bach Jensen mich...@ifad.dk wrote:

 Hi,

 During development of a new shader-based point-rendering system I started
 getting INVALID_OPERATION at start of State::apply(StateSet*) for the
 first rendered frame (subsequent frames are OK).

 The scene consists of a geode, shapedrawable box (no stateset/fixed
 function pipeline) and the point rendering node (shader pipeline) both
 under the same parent group. When rendering, the box is drawn before the
 points.

 It turned out to be due to my point shader being active for the box. The
 shader becomes active (by mistake?) as a result of the renderer calling
 compile().

 Adding a stateset to the box node with an empty program fixes the issue
 since it forces fixed function into effect before drawing the box.

 It would be nice to avoid this initial INVALID_OPERATION message.

 Has anyone else encountered this or something similar? It looks like a bug
 to me. What do you think?

 Thank you!

 Cheers,
 Michael

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





 ___
 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 initial renderer compile?


2014-01-22

Thread
Trajce Nikolov NICK

Hi,

I have the same issue on my ATI laptop but it is not happening on NVIDIA
machines

Nick


On Wed, Jan 22, 2014 at 1:58 PM, Robert Osfield robert.osfi...@gmail.comwrote:

 Hi Micahel,

 It could be a big with the GLCompileVisitor not cleaning up on the state
 it's compiling.  Could you create a small example that illustrates this
 problem - such as modifiying one the OSG examples such as osgshape so it
 can reproduce the error.  With such an example I can then step through what
 is being set and work out what might be going on, and what needs to be done
 to address the issue.

 Robert.


 On 22 January 2014 10:33, Michael Bach Jensen mich...@ifad.dk wrote:

 Hi,

 During development of a new shader-based point-rendering system I started
 getting INVALID_OPERATION at start of State::apply(StateSet*) for the
 first rendered frame (subsequent frames are OK).

 The scene consists of a geode, shapedrawable box (no stateset/fixed
 function pipeline) and the point rendering node (shader pipeline) both
 under the same parent group. When rendering, the box is drawn before the
 points.

 It turned out to be due to my point shader being active for the box. The
 shader becomes active (by mistake?) as a result of the renderer calling
 compile().

 Adding a stateset to the box node with an empty program fixes the issue
 since it forces fixed function into effect before drawing the box.

 It would be nice to avoid this initial INVALID_OPERATION message.

 Has anyone else encountered this or something similar? It looks like a
 bug to me. What do you think?

 Thank you!

 Cheers,
 Michael

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





 ___
 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] Bug in initial renderer compile?


2014-01-22

Thread
Michael Bach Jensen

Hi Robert and Nick,

It does very much look like a missing cleanup after compilation.

The following things need to be present:
- a geometry shader
- a uniform
- rendering the node using the above after an object that is not compatible 
with the shader program.

I have attached a modified version of osgshape.cpp that causes the failure.

Thank you for looking into it!

Cheers,
Michael

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



/* OpenSceneGraph example, osgshape.
*
*  Permission is hereby granted, free of charge, to any person obtaining a copy
*  of this software and associated documentation files (the Software), to deal
*  in the Software without restriction, including without limitation the rights
*  to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
*  copies of the Software, and to permit persons to whom the Software is
*  furnished to do so, subject to the following conditions:
*
*  THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
*  IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
*  FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
*  AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
*  LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
*  OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
*  THE SOFTWARE.
*/

#include osg/Geode
#include osg/ShapeDrawable
#include osg/Material
#include osg/Texture2D
#include osgUtil/ShaderGen

#include osgViewer/Viewer

#include osgDB/ReadFile
#include osgDB/WriteFile

#include osg/Math

#include GL/glext.h

// for the grid data..
#include ../osghangglide/terrain_coords.h

osg::Geode* createShapes()
{
osg::Geode* geode = new osg::Geode();


// ---
// Set up a StateSet to texture the objects
// ---
osg::StateSet* stateset = new osg::StateSet();

osg::Image* image = osgDB::readImageFile( Images/lz.rgb );
if (image)
{
osg::Texture2D* texture = new osg::Texture2D;
texture-setImage(image);
texture-setFilter(osg::Texture::MIN_FILTER, osg::Texture::LINEAR);
stateset-setTextureAttributeAndModes(0,texture, 
osg::StateAttribute::ON);
}

stateset-setMode(GL_LIGHTING, osg::StateAttribute::ON);

geode-setStateSet( stateset );


float radius = 0.8f;
float height = 1.0f;

osg::TessellationHints* hints = new osg::TessellationHints;
hints-setDetailRatio(0.5f);

geode-addDrawable(new osg::ShapeDrawable(new 
osg::Sphere(osg::Vec3(0.0f,0.0f,0.0f),radius),hints));
geode-addDrawable(new osg::ShapeDrawable(new 
osg::Box(osg::Vec3(2.0f,0.0f,0.0f),2*radius),hints));
geode-addDrawable(new osg::ShapeDrawable(new 
osg::Cone(osg::Vec3(4.0f,0.0f,0.0f),radius,height),hints));
geode-addDrawable(new osg::ShapeDrawable(new 
osg::Cylinder(osg::Vec3(6.0f,0.0f,0.0f),radius,height),hints));
geode-addDrawable(new osg::ShapeDrawable(new 
osg::Capsule(osg::Vec3(8.0f,0.0f,0.0f),radius,height),hints));

osg::HeightField* grid = new osg::HeightField;
grid-allocate(38,39);
grid-setXInterval(0.28f);
grid-setYInterval(0.28f);

for(unsigned int r=0;r39;++r)
{
for(unsigned int c=0;c38;++c)
{
grid-setHeight(c,r,vertex[r+c*39][2]);
}
}
geode-addDrawable(new osg::ShapeDrawable(grid));

osg::ConvexHull* mesh = new osg::ConvexHull;
osg::Vec3Array* vertices = new osg::Vec3Array(4);
(*vertices)[0].set(9.0+0.0f,-1.0f+2.0f,-1.0f+0.0f);
(*vertices)[1].set(9.0+1.0f,-1.0f+0.0f,-1.0f+0.0f);
(*vertices)[2].set(9.0+2.0f,-1.0f+2.0f,-1.0f+0.0f);
(*vertices)[3].set(9.0+1.0f,-1.0f+1.0f,-1.0f+2.0f);
osg::UByteArray* indices = new osg::UByteArray(12);
(*indices)[0]=0;
(*indices)[1]=2;
(*indices)[2]=1;
(*indices)[3]=0;
(*indices)[4]=1;
(*indices)[5]=3;
(*indices)[6]=1;
(*indices)[7]=2;
(*indices)[8]=3;
(*indices)[9]=2;
(*indices)[10]=0;
(*indices)[11]=3;
mesh-setVertices(vertices);
mesh-setIndices(indices);
geode-addDrawable(new osg::ShapeDrawable(mesh));

return geode;
}

static const GLuint PIXELSIZE_BINDATTRIB_LOCATION = osg::Drawable::ATTRIBUTE_6;

osg::Program* createPointShader()
{
static const char* vertSource =
{
#version 120\n
\n
varying vec4 color;\n
\n
void main(void)\n
{\n
gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;\n
gl_PointSize = 30.0;\n
color = gl_Color;\n
}\n
};

static const char* geomSource =
{
#version 330 core\n
\n
uniform float minPixelSize;\n
\n
layout (points) in;\n
in vec4 color[];\n
\n
layout (points, max_vertices = 1) 



Re: [osg-users] Bug in initial renderer compile?


2014-01-22

Thread
Michael Bach Jensen

Hi again,

I should mention that I am currently on OpenSceneGraph 3.1.4. :-)

Michael

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





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





[osg-users] Bug in trunk with Intersector epsilon


2013-08-01

Thread
Aurelien Albert

Hi,

I think there is a bug in the trunk : the epsilon used for osgUtil::Intersector 
class is not initialized.

Thank you!

Cheers,
Aurelien

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





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





Re: [osg-users] Bug in trunk with Intersector epsilon


2013-08-01

Thread
Robert Osfield

Hi Aurelien,

On 1 August 2013 16:09, Aurelien Albert aurelien.alb...@alyotech.fr wrote:
 I think there is a bug in the trunk : the epsilon used for 
 osgUtil::Intersector class is not initialized.

Opps, I did originally have a initializer for _epsilon when it was
initially implemented in LineSegmentIntersector but must have missed
transferring when I moved _epsilon to the parent class.

Missing initilaizer now checked in. Thanks for spotting + reporting the problem.

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 Qt thread integration


2013-01-24

Thread
Vitezslav Zajic

Hi,

I have run into the same problem with the application I'm working on. Since it 
seems to me that it was not corrected yet (or am I mistaken?), i'm writing 
here. I suggest that at least the static_cast is replaced with the dynamic_cast:


Code:
QtThreadPrivateData* pd = 
static_castQtThreadPrivateData*(QThread::currentThread());



It helped in my case (everything seems to be working), and, if there is still 
some bug caused by the possibly returned null pointer, it will be at least more 
easily trackable.

Note that this can be reproduced if you use single-threaded rendering in the 
application's main thread. The main thread is created by Qt, not by 
OpenThreads, and is not an instance of QtThreadPrivateData.

Cheers,
Vitezslav

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





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





[osg-users] Bug in osgGA::GUIEventHandler in OSG 3.0.1 release (fixed in current trunk).


2013-01-22

Thread
Jesper D. Thomsen

Hi guys,

Our software uses OSG for displaying a modelview for our muscular-skeletal 
simulation software. In our latest beta-version we have switched to OSG 3.0.1, 
but we just yesterday found a bug related to osgGA::GUIEventHandler, which we 
use for handling mouse events in our modelview. If we create a new OSG graph 
but keep the drawing context, the osgGA::GUIEventHandler for the view would 
sometimes not receive the usual (MOVE, MOVE, ...,  MOVE, MOVE, PUSH, RELEASE, 
FRAME) sequence of osgGA::GUIEventAdapter's when pressing a mousebutton in the 
view. If the modelview was left open for a period of time (tens of seconds to 
minutes), the next mousebutton push would trigger and send any saved up event 
to the GUIEventHandler. We previously used OSG 2.9.11, where this issue doesn't 
seem to occur, and I have just tested our software with a fresh OSG 3.1.4 built 
from svn trunk, and it also seems to work correctly.

My question is if this is a known bug from the OSG release version which has 
been fixed, and if there's any plan for either a new official release version 
of OSG or at least a developer release in the short term future (1-2 months)?

Best regards, and thanks

Jesper D. Thomsen
AnyBody Technology
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org





Re: [osg-users] Bug in osgGA::GUIEventHandler in OSG 3.0.1 release (fixed in current trunk).


2013-01-22

Thread
Robert Osfield

Hi Jesper,

I'm just wrapping up some work and plan to make a developer release
this week.  I don't have an schedule for the next stable release, but
would like to get one out in the next few months.

Robert.

On 22 January 2013 14:32, Jesper D. Thomsen j...@anybodytech.com wrote:
 Hi guys,



 Our software uses OSG for displaying a modelview for our muscular-skeletal
 simulation software. In our latest beta-version we have switched to OSG
 3.0.1, but we just yesterday found a bug related to osgGA::GUIEventHandler,
 which we use for handling mouse events in our modelview. If we create a new
 OSG graph but keep the drawing context, the osgGA::GUIEventHandler for the
 view would sometimes not receive the usual (MOVE, MOVE, …,  MOVE, MOVE,
 PUSH, RELEASE, FRAME) sequence of osgGA::GUIEventAdapter’s when pressing a
 mousebutton in the view. If the modelview was left open for a period of time
 (tens of seconds to minutes), the next mousebutton push would trigger and
 send any “saved up” event to the GUIEventHandler. We previously used OSG
 2.9.11, where this issue doesn’t seem to occur, and I have just tested our
 software with a fresh OSG 3.1.4 built from svn trunk, and it also seems to
 work correctly.



 My question is if this is a known bug from the OSG release version which has
 been fixed, and if there’s any plan for either a new official release
 version of OSG or at least a developer release in the short term future (1-2
 months)?



 Best regards, and thanks



 Jesper D. Thomsen

 AnyBody Technology


 ___
 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] bug in GraphicsWindowQt


2012-10-12

Thread
Gianni Ambrosio

Hi,
it seems there is a bug in GraphWidget::keyPressEvent( QKeyEvent* event ) at 
least in OSG 2.9.14 with Qt 4.8.2.
I guess the problem is here:

int remapKey(QKeyEvent* event)
{
KeyMap::iterator itr = mKeyMap.find(event-key());
if (itr == mKeyMap.end())
{
return int(*(event-text().toAscii().data()));
}
else
return itr-second;
}

return int(*(event-text().toAscii().data())); is not correct for a QKeyEvent 
like CTRL+F in fact txt does not contain 'f'. That code is correct only for 
key events without modifiers. The variable 'txt contains something else I don't 
understand but I could ask toe Qt support about that. The only way to get the 
key pressed in combination with a modifier is to look at the 'k' value of 
QKeyEvent.

Regards,
Gianni

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





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





Re: [osg-users] Bug in Qt thread integration


2012-10-03

Thread
Chris Long

Hi,

Thanks for the replies and suggestions.

I think I might not have explained the issue as well as I thought, so I'll try 
again.

QThread::currentThread does return a value with static type QThread*. However, 
it might not point to a QThread instance, but an instance of a subclass of 
QThread.

The problem is that OpenThreads assumes that the return value can be cast to a 
pointer to a specific subclass of QThread that OpenThreads defines, 
QtThreadPrivateData, like this:


Code:
QtThreadPrivateData* pd = 
static_castQtThreadPrivateData*(QThread::currentThread());




This is a problem because if the current thread is a different subclass of 
QThread, this cast is invalid so when the new pointer (pd) is used, it causes a 
seg fault or random behavior.

We have observed in our application that this does in fact sometimes occur. 
Specifically, QThread::currentThread can return a QAdoptedThread*, which is 
legal since QAdoptedThread is a subclass of QThread.

I hope this clarifies things.

Thank you!

Cheers,
Chris

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





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





Re: [osg-users] Bug in Qt thread integration


2012-09-28

Thread
Torben Dannhauer

Hi,

In fact QThread::currentThread returns a QThread.

maybe you want to use qobject_cast instead of other casts, it is has some other 
advantages 
(http://lists.qt.nokia.com/pipermail/qt-interest/2010-October/028327.html).

Cheers,
Torben

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





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




    
  1   2   3   4    >