from:"OpenSceneGraph Users"

Hi Robert,

I fixed my issue by recreating the osg::Billboard, instead of re-adding all
the drawables to the billboard.

1) tags = new osg::Billboard;

// add all the billboards
2) tags->addDrawable(osg::Geometry, osg::Vec3(pos.x, pos.y, pos.z));

3) draw scene

I understand very well what you are saying, but I don't have time to
understand and create a custom node right now.
We are not using Shaders, the number of tags is very dynamic, however is
less than 100.

Thank you very much,
Catalin


On Thu, 13 Feb 2020 at 10:04, OpenSceneGraph Users <
osg-users@lists.openscenegraph.org> wrote:

> HI Catalin,
>
> I would recommend against deleting and recreating scene graphs on every
> frame, this will lead to poor performance.
>
> If you have a really dynamic dataset then it may be appropriate to write a
> custom node for this, or use a shader.
>
> In the case of shaders you can often replace billboards with a single
> geometry that get instanced and have the
>  vertex shader use the index id as a look up into a uniform array that
> contains the offsets, or any scales you want.
> To change the positions you just update the uniform, to change number you
> just change the number of instances.
>
> Robert.
>
> On Wed, 12 Feb 2020 at 20:31, OpenSceneGraph Users <
> osg-users@lists.openscenegraph.org> wrote:
>
>> Hi,
>>
>> I have an issue, might not be related to osg::Billboard it self.
>>
>> At every frame, I delete all the drawables for a osg::Billboard:
>> tags->removeDrawables(0, size);
>>
>> and I add them again, possible with different values for position:
>> tags->addDrawable(osg::Geometry, osg::Vec3(pos.x, pos.y, pos.z));
>>
>> but in the view I still see the old positions of the tags!
>>
>> Does OSG has some kind of cache? Do I have to invalidate something?
>>
>> Greetings,
>> Catalin
>> ___
>> 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.70438.1581581043.7167.osg-users-openscenegraph.org%40lists.openscenegraph.org
> <https://groups.google.com/d/msgid/osg-users/mailman.70438.1581581043.7167.osg-users-openscenegraph.org%40lists.openscenegraph.org?utm_medium=email_source=footer>
> .
> _______
> 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.70438.1581581043.7167.osg-users-openscenegraph.org%40lists.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/CAO8T4jKTC1LoadUD9dOe1s8LgCO3X7i_FNarsoGraAzRRdqixA%40mail.gmail.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] How to scale/rotate/move an asset in OpenSceneGraph

2020-02-12 Thread OpenSceneGraph Users

That helped a lot.

Thanks
Regards
Luca

Il giorno mar 11 feb 2020 alle ore 17:38 Armin Samii  ha
scritto:

> Check out the examples directory.
> One example:
> https://github.com/openscenegraph/OpenSceneGraph/blob/master/examples/osganimate/osganimate.cpp#L247
> 1. Create a MatrixTransform
> 2. Add your rectangle as a child of that transform
> 3. Save the MatrixTransform node
>
> On Tue, Feb 11, 2020 at 11:29 AM Luca Costantino <
> luca.costant...@gmail.com> wrote:
>
>> I am totally new with OpenSceneGraph
>>
>> I can open and save an OSG asset. I need to do some simple
>> transformations on it, like dimension scaling/rotation/translation.
>>
>> It seems a pretty easy task, anyway I can't find any quick documentation
>> :/
>>
>> osg::ref_ptr rectangle = 
>> osgDB::readNodeFile("../../inputs/Rectangle.osg");
>> // define simple transformation matrix// apply  simple trnasformation matrix
>>
>> osgDB::writeNodeFile(*rectangle, "../../outputs/saved.osg");
>>
>> Any hint?
>>
>> --
>> 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/a6df11c6-2805-44e4-af15-62aa8a77dabb%40googlegroups.com
>> <https://groups.google.com/d/msgid/osg-users/a6df11c6-2805-44e4-af15-62aa8a77dabb%40googlegroups.com?utm_medium=email_source=footer>
>> .
>
> --
> 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/CAJFSWeRt5250LuWy-2i4yhv3-wOGxEXMkKF%2BQ8RtMrzSM7Z1Sg%40mail.gmail.com
> <https://groups.google.com/d/msgid/osg-users/CAJFSWeRt5250LuWy-2i4yhv3-wOGxEXMkKF%2BQ8RtMrzSM7Z1Sg%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
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/CA%2BvfGHbipV0_R7Hnj53-fWjVhQYmn%3DJUcyHF2DXkVjPHuGPk3Q%40mail.gmail.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG 3.0.1 Windows Binaries

That's pretty old. What are you struggling with trying to compile it
yourself?

On Thu, Feb 13, 2020 at 8:05 AM OpenSceneGraph Users <
osg-users@lists.openscenegraph.org> wrote:

> Hi all
>
> I need to use OSG 3.0.1 in order to be compatible with some legacy app.
> I cannot find anywhere the precompiled binaries for Windows, and
> unfortunately I am struggling to compile it on my own with Visual Studio.
>
> Does anyone has such binaries to share, or can point where they can be
> downloaded?
>
> Thanks
> Regards
>
> Luca
>
> --
> 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/2a96992b-6835-4fa5-b4d8-f7ccc3aaa851%40googlegroups.com
> <https://groups.google.com/d/msgid/osg-users/2a96992b-6835-4fa5-b4d8-f7ccc3aaa851%40googlegroups.com?utm_medium=email_source=footer>
> .
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>


-- 
Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com
http://www.alphapixel.com/
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 •
GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
Legal/IP • Forensics • Imaging • UAVs • GIS • GPS •
osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded • Mobile •
iPhone/iPad/iOS • Android
@alphapixel <https://twitter.com/alphapixel> facebook.com/alphapixel (775)
623-PIXL [7495]

-- 
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/CAGoufmZv1Y-c0_6EmFRUcfObcnfr0i9TVqJsggREHTn_Ax1g0A%40mail.gmail.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] OSG 3.0.1 Windows Binaries

Hi all

I need to use OSG 3.0.1 in order to be compatible with some legacy app.
I cannot find anywhere the precompiled binaries for Windows, and 
unfortunately I am struggling to compile it on my own with Visual Studio.

Does anyone has such binaries to share, or can point where they can be 
downloaded?

Thanks
Regards

Luca

-- 
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/2a96992b-6835-4fa5-b4d8-f7ccc3aaa851%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG 3.0.1 Windows Binaries

That's pretty old. What are you struggling with trying to compile it
yourself?

On Thu, Feb 13, 2020 at 8:05 AM OpenSceneGraph Users <
osg-users@lists.openscenegraph.org> wrote:

> Hi all
>
> I need to use OSG 3.0.1 in order to be compatible with some legacy app.
> I cannot find anywhere the precompiled binaries for Windows, and
> unfortunately I am struggling to compile it on my own with Visual Studio.
>
> Does anyone has such binaries to share, or can point where they can be
> downloaded?
>
> Thanks
> Regards
>
> Luca
>
> --
> 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/2a96992b-6835-4fa5-b4d8-f7ccc3aaa851%40googlegroups.com
> <https://groups.google.com/d/msgid/osg-users/2a96992b-6835-4fa5-b4d8-f7ccc3aaa851%40googlegroups.com?utm_medium=email_source=footer>
> .
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>


-- 
Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com
http://www.alphapixel.com/
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 •
GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
Legal/IP • Forensics • Imaging • UAVs • GIS • GPS •
osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded • Mobile •
iPhone/iPad/iOS • Android
@alphapixel <https://twitter.com/alphapixel> facebook.com/alphapixel (775)
623-PIXL [7495]
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG 3.0.1 Windows Binaries

std::min / std::max undefined -> solved adding #include  at the
beginning of a couple of files
min and max not defined -> solved changing them in std::min and std:: max
and adding the same header
if(getline(x, y) == 0) error -> it should be if (stream.fail())

right now it's building again, but I'm sure I will face some other error :/
I just switched from VS2017 to VS 2019, just in case...

Il giorno gio 13 feb 2020 alle ore 17:33 Chris Hanson 
ha scritto:

> That's pretty old. What are you struggling with trying to compile it
> yourself?
>
> On Thu, Feb 13, 2020 at 8:05 AM OpenSceneGraph Users <
> osg-users@lists.openscenegraph.org> wrote:
>
>> Hi all
>>
>> I need to use OSG 3.0.1 in order to be compatible with some legacy app.
>> I cannot find anywhere the precompiled binaries for Windows, and
>> unfortunately I am struggling to compile it on my own with Visual Studio.
>>
>> Does anyone has such binaries to share, or can point where they can be
>> downloaded?
>>
>> Thanks
>> Regards
>>
>> Luca
>>
>> --
>> 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/2a96992b-6835-4fa5-b4d8-f7ccc3aaa851%40googlegroups.com
>> <https://groups.google.com/d/msgid/osg-users/2a96992b-6835-4fa5-b4d8-f7ccc3aaa851%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>
>
> --
> Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com
> http://www.alphapixel.com/
> Training • Consulting • Contracting
> 3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4
> • GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
> Legal/IP • Forensics • Imaging • UAVs • GIS • GPS •
> osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded • Mobile •
> iPhone/iPad/iOS • Android
> @alphapixel <https://twitter.com/alphapixel> facebook.com/alphapixel (775)
> 623-PIXL [7495]
>
> --
> 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/CAGoufmZv1Y-c0_6EmFRUcfObcnfr0i9TVqJsggREHTn_Ax1g0A%40mail.gmail.com
> <https://groups.google.com/d/msgid/osg-users/CAGoufmZv1Y-c0_6EmFRUcfObcnfr0i9TVqJsggREHTn_Ax1g0A%40mail.gmail.com?utm_medium=email_source=footer>
> .
>

-- 
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/CA%2BvfGHZk-RE9Pbh3p9msxvvSogujhFrYzXn3_4%3Dbc5%3D9aNJKRw%40mail.gmail.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OSG 3.0.1 Windows Binaries

Hi Luca,

 

Building an old version of OSG with a relatively new compiler will provoke 
these errors. Can’t you build with an older compiler toolset?

 

Cheers

Sebastian 

 

From: osg-users  On Behalf Of 
OpenSceneGraph Users
Sent: Donnerstag, 13. Februar 2020 17:38
To: osg-us...@googlegroups.com
Cc: OpenSceneGraph Users 
Subject: Re: [osg-users] OSG 3.0.1 Windows Binaries

 

std::min / std::max undefined -> solved adding #include  at the 
beginning of a couple of files

min and max not defined -> solved changing them in std::min and std:: max and 
adding the same header

if(getline(x, y) == 0) error -> it should be if (stream.fail())

 

right now it's building again, but I'm sure I will face some other error :/

I just switched from VS2017 to VS 2019, just in case...

 

Il giorno gio 13 feb 2020 alle ore 17:33 Chris Hanson mailto:xe...@alphapixel.com> > ha scritto:

That's pretty old. What are you struggling with trying to compile it yourself?

 

On Thu, Feb 13, 2020 at 8:05 AM OpenSceneGraph Users 
mailto:osg-users@lists.openscenegraph.org> 
> wrote:

Hi all

 

I need to use OSG 3.0.1 in order to be compatible with some legacy app.

I cannot find anywhere the precompiled binaries for Windows, and unfortunately 
I am struggling to compile it on my own with Visual Studio.

 

Does anyone has such binaries to share, or can point where they can be 
downloaded?

 

Thanks

Regards

 

Luca

-- 
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 
<mailto:osg-users+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/2a96992b-6835-4fa5-b4d8-f7ccc3aaa851%40googlegroups.com
 
<https://groups.google.com/d/msgid/osg-users/2a96992b-6835-4fa5-b4d8-f7ccc3aaa851%40googlegroups.com?utm_medium=email_source=footer>
 .
___
osg-users mailing list
osg-users@lists.openscenegraph.org <mailto:osg-users@lists.openscenegraph.org> 
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org




 

-- 

Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com 
<mailto:xe...@alphapixel.com>  http://www.alphapixel.com/

Training • Consulting • Contracting

3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 • 
GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL

Legal/IP • Forensics • Imaging • UAVs • GIS • GPS • osgEarth • Terrain • 
Telemetry • Cryptography • LIDAR • Embedded • Mobile • iPhone/iPad/iOS • Android

@alphapixel <https://twitter.com/alphapixel>  facebook.com/alphapixel 
<http://facebook.com/alphapixel>  (775) 623-PIXL [7495]

-- 
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 
<mailto:osg-users+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/CAGoufmZv1Y-c0_6EmFRUcfObcnfr0i9TVqJsggREHTn_Ax1g0A%40mail.gmail.com
 
<https://groups.google.com/d/msgid/osg-users/CAGoufmZv1Y-c0_6EmFRUcfObcnfr0i9TVqJsggREHTn_Ax1g0A%40mail.gmail.com?utm_medium=email_source=footer>
 .

-- 
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 
<mailto:osg-users+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/CA%2BvfGHZk-RE9Pbh3p9msxvvSogujhFrYzXn3_4%3Dbc5%3D9aNJKRw%40mail.gmail.com
 
<https://groups.google.com/d/msgid/osg-users/CA%2BvfGHZk-RE9Pbh3p9msxvvSogujhFrYzXn3_4%3Dbc5%3D9aNJKRw%40mail.gmail.com?utm_medium=email_source=footer>
 .



smime.p7s
Description: S/MIME cryptographic signature
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] osg::Billboard positions

2020-02-12 Thread OpenSceneGraph Users

Hi,

I have an issue, might not be related to osg::Billboard it self.

At every frame, I delete all the drawables for a osg::Billboard:
tags->removeDrawables(0, size);

and I add them again, possible with different values for position:
tags->addDrawable(osg::Geometry, osg::Vec3(pos.x, pos.y, pos.z));

but in the view I still see the old positions of the tags!

Does OSG has some kind of cache? Do I have to invalidate something?

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

Re: [osg-users] ProgramBinary and shader composition - does it work?

2020-02-23 Thread OpenSceneGraph Users

Hi Glenn,

The way I'd tackle the issue of compilation of shaders taking a long time
is to avoid doing it frame time, doing as much work in scene graph
setup/compilation.

For you usage case I assume you have a complex shader with many different
constant inputs either controlling code paths or values, and the scene
graph is configuring these as the values change provided by the scene graph
via the #PCS defines.  If you can work out what range of different defines
you will need then build a subgraph with each of these combinations and the
sharing osg::Program that depends upon these then compile this subgraph,
once it's all compiled you can discard it save for the osg::Program that
you then reuse in your main application.

This approach should in theory populate the osg::Program with all the GLSL
program combinations that you will need and the OSG can internally just use
these when rendering your main scene graph.

Robert.

On Sun, 23 Feb 2020 at 14:14, OpenSceneGraph Users <
osg-users@lists.openscenegraph.org> wrote:

> Robert,
>
> I have an application with several complex shaders. According to the
> profiler some of them take a while to link (glLinkProgram), long enough to
> cause a frame drop. This app cannot tolerate any frame drops so I was
> looking into glProgramBinary as a possible mitigation. I'm open to other
> ideas of course.
>
> Glenn Waldron / osgEarth
>
>
> On Thu, Feb 20, 2020 at 10:31 AM OpenSceneGraph Users <
> osg-users@lists.openscenegraph.org> wrote:
>
>> Hi Glenn,
>>
>> On Wed, 19 Feb 2020 at 17:56, OpenSceneGraph Users <
>> osg-users@lists.openscenegraph.org> wrote:
>>
>>> I was looking in the glProgramBinary support in osg::Program. I don't
>>> *think* it is integrated with your "pragmatic" define-based shader
>>> composition system. Specifically there doesn't seem to be a way to
>>> associate a ProgramBinary with a particular defineString at the
>>> PerContextProgram level.
>>>
>>> Am I right? And if so will you consider a submission to make this work?
>>>
>>
>> When writing the #pragma(tic) shader composition functionality I was just
>> focused on conventional GLSL compiled shaders, I didn't consider
>> glProgramBinary, so no idea of how it might interact, I don't expect it
>> would would work though as the main task of shader composition is
>> compositing the shaders to compile and compiling these at runtime.
>>
>> Is there a reason why you are trying to the the glProgramBinary path?
>>
>> 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
>

-- 
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.72005.1582472886.7168.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.72005.1582472886.7168.osg-users-openscenegraph.org%40lists.openscenegraph.org.

Re: [osg-users] ProgramBinary and shader composition - does it work?

2020-02-23 Thread OpenSceneGraph Users

Robert,

I have an application with several complex shaders. According to the
profiler some of them take a while to link (glLinkProgram), long enough to
cause a frame drop. This app cannot tolerate any frame drops so I was
looking into glProgramBinary as a possible mitigation. I'm open to other
ideas of course.

Glenn Waldron / osgEarth


On Thu, Feb 20, 2020 at 10:31 AM OpenSceneGraph Users <
osg-users@lists.openscenegraph.org> wrote:

> Hi Glenn,
>
> On Wed, 19 Feb 2020 at 17:56, OpenSceneGraph Users <
> osg-users@lists.openscenegraph.org> wrote:
>
>> I was looking in the glProgramBinary support in osg::Program. I don't
>> *think* it is integrated with your "pragmatic" define-based shader
>> composition system. Specifically there doesn't seem to be a way to
>> associate a ProgramBinary with a particular defineString at the
>> PerContextProgram level.
>>
>> Am I right? And if so will you consider a submission to make this work?
>>
>
> When writing the #pragma(tic) shader composition functionality I was just
> focused on conventional GLSL compiled shaders, I didn't consider
> glProgramBinary, so no idea of how it might interact, I don't expect it
> would would work though as the main task of shader composition is
> compositing the shaders to compile and compiling these at runtime.
>
> Is there a reason why you are trying to the the glProgramBinary path?
>
> Robert.
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Best practices for dealing with complex scene graph

2020-03-01 Thread OpenSceneGraph Users

Hi,
I was wondering what the best practices are for dealing with a complex 
scene graph where a single osg::Group might have , say, 5000 children where 
each child is fairly simple osg::Geom geometry. Clearly, this is 
inefficient and draws slowly.
So obviously, compiling/collecting the geometry into one drawable would be 
much more efficient. osgUtil::Optimizer does not seem to do this for me, or 
am I missing something?

Andrew

-- 
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/19df5325-01d5-4fa7-94d2-9c9560c92956%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Best practices for dealing with complex scene graph

2020-03-01 Thread OpenSceneGraph Users

Iterating over the 5000 children would be pretty slow - what if you could
discard some of these children without even looking at them? A hierarchy of
sorts, where you can ignore large swaths of those children, would help...
Consider, for example, using a k-d tree:
http://www.openscenegraph.org/index.php/documentation/user-guides/107-kdtrees

Or you can do this on your own, if you like, by grouping nearby nodes into
their own osg::Group. Depends what your underlying data looks like.

I would not recommend combining the geometry into a single drawable unless
you expect all of them to be visible at once, and that each piece of
geometry is fairly small.

On Sun, Mar 1, 2020 at 9:07 AM AndrewC  wrote:

> Hi,
> I was wondering what the best practices are for dealing with a complex
> scene graph where a single osg::Group might have , say, 5000 children where
> each child is fairly simple osg::Geom geometry. Clearly, this is
> inefficient and draws slowly.
> So obviously, compiling/collecting the geometry into one drawable would be
> much more efficient. osgUtil::Optimizer does not seem to do this for me, or
> am I missing something?
>
> Andrew
>
> --
> 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/19df5325-01d5-4fa7-94d2-9c9560c92956%40googlegroups.com
> <https://groups.google.com/d/msgid/osg-users/19df5325-01d5-4fa7-94d2-9c9560c92956%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 

Armin Samii

Visualization Software Engineer, Argo AI <http://argo.ai/>
CONFIDENTIALITY NOTICE: This e-mail and any files transmitted with it are
confidential and designated solely for use of the individual(s) or entity
to whom they are addressed. If you are not the named addressee, you are
notified that disseminating, copying, disclosing or taking any action in
reliance on its contents is strictly prohibited and could subject you to
legal action by the sender. Please notify the sender immediately if you
have received this e-mail in error and delete it from your system. Thanks
for your cooperation.

-- 
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/CAJFSWeRYxGwRuUmHAqLC2V4NikiqOjJ5K839TKV7REzLM35-vg%40mail.gmail.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Best practices for dealing with complex scene graph


I found a reasonably good generic solution to flatten any part of my scene 
graph.
- Use a visitor pattern to collect all my osg::Geometry into a set of 
geometries starting at the osg::Group in question
- do a clone of the geometries into a new set with 
(osg::CopyOp::DEEP_COPY_PRIMITIVES | osg::CopyOp::DEEP_COPY_ARRAYS) , then 
add them into a new osg::Group for the optimizer to work with.
- Use a osgUtil::MergeGeometryVisitor to collect all the primitive sets
- Then an osgUtil::IndexMeshVisitor to merge the primitive sets


On Sunday, March 1, 2020 at 9:07:42 AM UTC-8, AndrewC wrote:
>
> Hi,
> I was wondering what the best practices are for dealing with a complex 
> scene graph where a single osg::Group might have , say, 5000 children where 
> each child is fairly simple osg::Geom geometry. Clearly, this is 
> inefficient and draws slowly.
> So obviously, compiling/collecting the geometry into one drawable would be 
> much more efficient. osgUtil::Optimizer does not seem to do this for me, or 
> am I missing something?
>
> Andrew
>

-- 
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/81eebbe0-f14b-4aa4-9c09-8bed0152647b%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Best practices for dealing with complex scene graph

I think if you could describe more of your problem domain, we might have
better suggestions. Like, what do all of these geometries actually
represent? I know you're trying to generalize the problem, but sometimes
knowing the specifics of the problem allows us to make domain-specific
suggestions.

Like, sometimes the question is "how do I make my axe cut faster" but the
real answer is "here, use a chainsaw instead".


On Mon, Mar 2, 2020 at 4:48 PM OpenSceneGraph Users <
osg-users@lists.openscenegraph.org> wrote:

>
> I found a reasonably good generic solution to flatten any part of my scene
> graph.
> - Use a visitor pattern to collect all my osg::Geometry into a set of
> geometries starting at the osg::Group in question
> - do a clone of the geometries into a new set with
> (osg::CopyOp::DEEP_COPY_PRIMITIVES | osg::CopyOp::DEEP_COPY_ARRAYS) , then
> add them into a new osg::Group for the optimizer to work with.
> - Use a osgUtil::MergeGeometryVisitor to collect all the primitive sets
> - Then an osgUtil::IndexMeshVisitor to merge the primitive sets
>
>
> On Sunday, March 1, 2020 at 9:07:42 AM UTC-8, AndrewC wrote:
>>
>> Hi,
>> I was wondering what the best practices are for dealing with a complex
>> scene graph where a single osg::Group might have , say, 5000 children where
>> each child is fairly simple osg::Geom geometry. Clearly, this is
>> inefficient and draws slowly.
>> So obviously, compiling/collecting the geometry into one drawable would
>> be much more efficient. osgUtil::Optimizer does not seem to do this for me,
>> or am I missing something?
>>
>> Andrew
>>
> --
> 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/81eebbe0-f14b-4aa4-9c09-8bed0152647b%40googlegroups.com
> <https://groups.google.com/d/msgid/osg-users/81eebbe0-f14b-4aa4-9c09-8bed0152647b%40googlegroups.com?utm_medium=email_source=footer>
> .
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>


-- 
Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com
http://www.alphapixel.com/
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 •
GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
Legal/IP • Forensics • Imaging • UAVs • GIS • GPS •
osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded • Mobile •
iPhone/iPad/iOS • Android
@alphapixel <https://twitter.com/alphapixel> facebook.com/alphapixel (775)
623-PIXL [7495]

-- 
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/CAGoufmZ-2KZSCWM8vOx-g-SY1pEMdSE4EQSrbuqcPyfmBYup0g%40mail.gmail.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Best practices for dealing with complex scene graph

I think if you could describe more of your problem domain, we might have
better suggestions. Like, what do all of these geometries actually
represent? I know you're trying to generalize the problem, but sometimes
knowing the specifics of the problem allows us to make domain-specific
suggestions.

Like, sometimes the question is "how do I make my axe cut faster" but the
real answer is "here, use a chainsaw instead".


On Mon, Mar 2, 2020 at 4:48 PM OpenSceneGraph Users <
osg-users@lists.openscenegraph.org> wrote:

>
> I found a reasonably good generic solution to flatten any part of my scene
> graph.
> - Use a visitor pattern to collect all my osg::Geometry into a set of
> geometries starting at the osg::Group in question
> - do a clone of the geometries into a new set with
> (osg::CopyOp::DEEP_COPY_PRIMITIVES | osg::CopyOp::DEEP_COPY_ARRAYS) , then
> add them into a new osg::Group for the optimizer to work with.
> - Use a osgUtil::MergeGeometryVisitor to collect all the primitive sets
> - Then an osgUtil::IndexMeshVisitor to merge the primitive sets
>
>
> On Sunday, March 1, 2020 at 9:07:42 AM UTC-8, AndrewC wrote:
>>
>> Hi,
>> I was wondering what the best practices are for dealing with a complex
>> scene graph where a single osg::Group might have , say, 5000 children where
>> each child is fairly simple osg::Geom geometry. Clearly, this is
>> inefficient and draws slowly.
>> So obviously, compiling/collecting the geometry into one drawable would
>> be much more efficient. osgUtil::Optimizer does not seem to do this for me,
>> or am I missing something?
>>
>> Andrew
>>
> --
> 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/81eebbe0-f14b-4aa4-9c09-8bed0152647b%40googlegroups.com
> <https://groups.google.com/d/msgid/osg-users/81eebbe0-f14b-4aa4-9c09-8bed0152647b%40googlegroups.com?utm_medium=email_source=footer>
> .
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>


-- 
Chris 'Xenon' Hanson, omo sanza lettere. xe...@alphapixel.com
http://www.alphapixel.com/
Training • Consulting • Contracting
3D • Scene Graphs (Open Scene Graph/OSG) • OpenGL 2 • OpenGL 3 • OpenGL 4 •
GLSL • OpenGL ES 1 • OpenGL ES 2 • OpenCL
Legal/IP • Forensics • Imaging • UAVs • GIS • GPS •
osgEarth • Terrain • Telemetry • Cryptography • LIDAR • Embedded • Mobile •
iPhone/iPad/iOS • Android
@alphapixel <https://twitter.com/alphapixel> facebook.com/alphapixel (775)
623-PIXL [7495]
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgQt aspect ratio issue when inside QMainWindow

2020-02-24 Thread OpenSceneGraph Users

Hi Angelo,

I believe you should handle from the osgQOpenGLWidget virtual methods, 
which should be something like virtual void resizeGL( int width, int height ); 

As it's expected it should be called whenever there's a change in the 
widget size. From there you would be able to call 
osgViewer::GraphicsWindowEmbedded 
resized method as 
well as camera's necessary adjustment for the new size and most important 
the aspect ration for this new size.


On Thursday, February 20, 2020 at 3:12:43 PM UTC+1, Angelo Emanuele 
Fiorilla wrote:
>
> Hi,
> I am trying to put an osgQOpenGLWidget inside a QMainWindow. I managed to 
> made it quite easily but the resulting image is stretched and I cannot 
> change its aspect ratio to made it right (the cow.osg is really stretched).
> Can you help me, please? I have been struggling with this few lines of 
> code for 5 days now.
>
> I can provide source code as follows...
>
> Thank you so much
>
> #include "mainwindow.h"
>
> MainWindow::MainWindow(QWidget *parent)
> : QMainWindow(parent)
> {
> QSurfaceFormat format = QSurfaceFormat::defaultFormat();
> format.setVersion(2, 0);
> format.setProfile(QSurfaceFormat::CompatibilityProfile);
> format.setRenderableType(QSurfaceFormat::OpenGL);
> format.setOption(QSurfaceFormat::DebugContext);
> format.setDepthBufferSize(24);
> format.setSamples(8);
> format.setStencilBufferSize(8);
> format.setSwapBehavior(QSurfaceFormat::DoubleBuffer);
> QSurfaceFormat::setDefaultFormat(format);
>
> osgWidget = new osgQOpenGLWidget(this);
> QObject::connect(osgWidget, ::initialized, this, 
> ::setupOsgView);
>
> setCentralWidget(osgWidget);
> osgWidget->show();
> }
>
> void MainWindow::setupOsgView() {
>
> osgWidget->getOsgViewer()->setCameraManipulator(new 
> osgGA::TerrainManipulator());
> osgWidget->getOsgViewer()->addEventHandler(new 
> osgGA::StateSetManipulator(osgWidget->getOsgViewer()->getCamera()->getOrCreateStateSet()));
> osgWidget->getOsgViewer()->addEventHandler(new 
> osgViewer::ThreadingHandler);
> osgWidget->getOsgViewer()->addEventHandler(new 
> osgViewer::WindowSizeHandler);
> osgWidget->getOsgViewer()->addEventHandler(new osgViewer::StatsHandler);
> osgWidget->getOsgViewer()->addEventHandler(new 
> osgViewer::RecordCameraPathHandler);
> osgWidget->getOsgViewer()->addEventHandler(new 
> osgViewer::LODScaleHandler);
> osgWidget->getOsgViewer()->addEventHandler(new 
> osgViewer::ScreenCaptureHandler);
>
> osg::ref_ptr loadedModel = osgDB::readRefNodeFile("cow.osg");
> if(!loadedModel) {
> std::cout << "No data loaded" << std::endl;
> }
>
>     osgUtil::Optimizer optimizer;
> optimizer.optimize(loadedModel);
>
> osgWidget->getOsgViewer()->setSceneData(loadedModel);
> }
>
> MainWindow::~MainWindow()
> {
>
> }
>
>

-- 
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/dcfa7c78-c750-428c-ae4a-8db831fed0a2%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgQt aspect ratio issue when inside QMainWindow

2020-02-25 Thread OpenSceneGraph Users

Hi Mohamed,
thank you for your reply. Actually, the methods initializeGL, resizeGL 
and paintGL are not virtual and are already implemented inside the 
osgQOpenGLWidget class.
Probably there's some function inside these methods that is called only 
once, probably at window initialization, or that is effective only the at 
the first time.
I am currently reading the code but I am not an expert on OpenSceneGraph 
and I can't figure out what's missing (i.e. why window resize causes just 
an image stretch).


Il giorno lunedì 24 febbraio 2020 14:14:53 UTC+1, mohamed selim ha scritto:
>
> Hi Angelo,
>
> I believe you should handle from the osgQOpenGLWidget virtual methods, 
> which should be something like virtual void resizeGL( int width, int 
> height ); 
> As it's expected it should be called whenever there's a change in the 
> widget size. From there you would be able to call 
> osgViewer::GraphicsWindowEmbedded 
> resized method as 
> well as camera's necessary adjustment for the new size and most important 
> the aspect ration for this new size.
>
>
> On Thursday, February 20, 2020 at 3:12:43 PM UTC+1, Angelo Emanuele 
> Fiorilla wrote:
>>
>> Hi,
>> I am trying to put an osgQOpenGLWidget inside a QMainWindow. I managed to 
>> made it quite easily but the resulting image is stretched and I cannot 
>> change its aspect ratio to made it right (the cow.osg is really stretched).
>> Can you help me, please? I have been struggling with this few lines of 
>> code for 5 days now.
>>
>> I can provide source code as follows...
>>
>> Thank you so much
>>
>> #include "mainwindow.h"
>>
>> MainWindow::MainWindow(QWidget *parent)
>> : QMainWindow(parent)
>> {
>> QSurfaceFormat format = QSurfaceFormat::defaultFormat();
>> format.setVersion(2, 0);
>> format.setProfile(QSurfaceFormat::CompatibilityProfile);
>> format.setRenderableType(QSurfaceFormat::OpenGL);
>> format.setOption(QSurfaceFormat::DebugContext);
>> format.setDepthBufferSize(24);
>> format.setSamples(8);
>> format.setStencilBufferSize(8);
>> format.setSwapBehavior(QSurfaceFormat::DoubleBuffer);
>> QSurfaceFormat::setDefaultFormat(format);
>>
>> osgWidget = new osgQOpenGLWidget(this);
>> QObject::connect(osgWidget, ::initialized, this, 
>> ::setupOsgView);
>>
>> setCentralWidget(osgWidget);
>> osgWidget->show();
>> }
>>
>> void MainWindow::setupOsgView() {
>>
>> osgWidget->getOsgViewer()->setCameraManipulator(new 
>> osgGA::TerrainManipulator());
>> osgWidget->getOsgViewer()->addEventHandler(new 
>> osgGA::StateSetManipulator(osgWidget->getOsgViewer()->getCamera()->getOrCreateStateSet()));
>> osgWidget->getOsgViewer()->addEventHandler(new 
>> osgViewer::ThreadingHandler);
>> osgWidget->getOsgViewer()->addEventHandler(new 
>> osgViewer::WindowSizeHandler);
>> osgWidget->getOsgViewer()->addEventHandler(new osgViewer::StatsHandler);
>> osgWidget->getOsgViewer()->addEventHandler(new 
>> osgViewer::RecordCameraPathHandler);
>> osgWidget->getOsgViewer()->addEventHandler(new 
>> osgViewer::LODScaleHandler);
>> osgWidget->getOsgViewer()->addEventHandler(new 
>> osgViewer::ScreenCaptureHandler);
>>
>> osg::ref_ptr loadedModel = osgDB::readRefNodeFile("cow.osg");
>> if(!loadedModel) {
>> std::cout << "No data loaded" << std::endl;
>> }
>>
>> osgUtil::Optimizer optimizer;
>> optimizer.optimize(loadedModel);
>>
>> osgWidget->getOsgViewer()->setSceneData(loadedModel);
>> }
>>
>> MainWindow::~MainWindow()
>> {
>>
>> }
>>
>>

-- 
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/3dddce23-89d9-4b0f-b8c7-bd9e429ef36e%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] How to scale the size of Geometry

You don't say what you are doing at the viewer level, but if you are using 
the OSG's standard CameraManiplators, including the default 
TrackballManipulator, the when the viewer initializes it'll compute the 
size of the scene it has to render and places the camera far away enough to 
ensure the scene is within the window, so if the scene is bigger the camera 
ends up further away.

Try creating an osg::Group and two different osg::Geometry as children that 
sit side by side, one large and one small and you should see the difference.

-- 
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/2fcfa484-24c6-41df-af30-d3597821e435%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Best practices for dealing with complex scene graph

2020-03-03 Thread OpenSceneGraph Users

Hi Andrew,

How best to go about this type of task will depend upon what exactly is 
being rendered and how it's updated if ever.

If the geometries are all the same then you could use geometry instancing 
combined with a Uniform Array or a Texture2DArray to store data that is 
indexed via the index id.

If the geometries are very simple, such as can be represented by a sprite 
then using point sprites is a good way of scaling.

If you do go a batching route then the best way is batch by state and 
geographical position so each batch can use the same state and sit within a 
tight area so that culling is maximized.

Cheers,
Robert.

-- 
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/8c56b271-fc47-4a49-a425-9e1c01a5197a%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Best practices for dealing with complex scene graph

2020-03-01 Thread OpenSceneGraph Users

Hi Armin,
Essentially the scene graph is a one-for-one representation of my DOM. Each 
individual object can be edited, or its attributes changed. 
The DOM can be a small number of geometrically "complex" objects  - this 
causes no performance problems as the geometry "leafs" are large 
geometrically, or the DOM might have a large number of simple objects.

A KD tree would be useful for removing "not visible" nodes, but in general 
they are all visible.

In "theory" the  whole scene graph geometry was flattened to one set of 
vertex, colors and normals for maximum efficiency - of course, updates to 
the scene graph would require this structure to be partially or fully 
rebuilt.

That's a bit of overkill for me, as I "know" the parent Group node in the 
scene graph that I want to make more efficient. Typically the objects under 
this node have the same attributes. 

I could flatten my nodes "manually", but flattening the scene graph seems a 
typical "use-case" that OSG users would want to do.

I have done some tests with osg::Optimizer with the MERGE_GEOMETRY option 
after collecting all the osg::Geometry nodes into a temporary group -  this 
does not do exactly what I want, as it only collects the 
osg::PrimitiveSets. Not merging the sets themselves.
Weirdly calling "optimize" also causes my scene graph to stop drawing for 
some unknown and very frustrating reason.

There is a lot of code in the OSG GLES plugin code that looks promising, 
but it's quite undocumented and I am having to guess about it's 
functionality.

Andrew

On Sunday, March 1, 2020 at 6:14:07 PM UTC-8, Armin Samii wrote:
>
> Iterating over the 5000 children would be pretty slow - what if you could 
> discard some of these children without even looking at them? A hierarchy of 
> sorts, where you can ignore large swaths of those children, would help...
> Consider, for example, using a k-d tree: 
> http://www.openscenegraph.org/index.php/documentation/user-guides/107-kdtrees
>
> Or you can do this on your own, if you like, by grouping nearby nodes into 
> their own osg::Group. Depends what your underlying data looks like.
>
>
>
> I would not recommend combining the geometry into a single drawable unless 
> you expect all of them to be visible at once, and that each piece of 
> geometry is fairly small.
>
> On Sun, Mar 1, 2020 at 9:07 AM AndrewC  > wrote:
>
>> Hi,
>> I was wondering what the best practices are for dealing with a complex 
>> scene graph where a single osg::Group might have , say, 5000 children where 
>> each child is fairly simple osg::Geom geometry. Clearly, this is 
>> inefficient and draws slowly.
>> So obviously, compiling/collecting the geometry into one drawable would 
>> be much more efficient. osgUtil::Optimizer does not seem to do this for me, 
>> or am I missing something?
>>
>> Andrew
>>
>> -- 
>> 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-...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/osg-users/19df5325-01d5-4fa7-94d2-9c9560c92956%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/osg-users/19df5325-01d5-4fa7-94d2-9c9560c92956%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>
>
> -- 
>
> Armin Samii
>
> Visualization Software Engineer, Argo AI <http://argo.ai/>
> CONFIDENTIALITY NOTICE: This e-mail and any files transmitted with it are 
> confidential and designated solely for use of the individual(s) or entity 
> to whom they are addressed. If you are not the named addressee, you are 
> notified that disseminating, copying, disclosing or taking any action in 
> reliance on its contents is strictly prohibited and could subject you to 
> legal action by the sender. Please notify the sender immediately if you 
> have received this e-mail in error and delete it from your system. Thanks 
> for your cooperation.
>

-- 
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/a98e70fb-9a0b-4925-a526-1371d294b5af%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

2020-01-26 Thread OpenSceneGraph Users


>
>
> It would be best to have 3.6.5 go out with support for recent VC and FBX 
> versions so would appreciate if you could generate a PR for them.  I can 
> merge them and make 3.6.5-rc3
>
> Cheers,
> Robert
>  
>

OK, done. https://github.com/openscenegraph/OpenSceneGraph/pull/907 

These changes fix my Windows VC builds but I'm no expert in CMake or the 
requirements of all the different builds so I suggest that this is reviewed 
by experienced OSG builders.

Cheers,
Stuart

-- 
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/2fcf7e29-5f6d-45e5-a85f-54546aa48c54%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

Hi Fiabian,

On Monday, 27 January 2020 09:41:43 UTC, Fabian Roth wrote:
>
> Hi,
> I am currently testing this RC with openmw.
> If i have the fps display or profiler open while exiting the application i 
> get a crash on exit.
> I am not sure if this is due to a bug in my build, a bug in openmw or a 
> real issue with osg.
> The issue seems to be related to the destruction of the default font, but 
> i was not able to investigate further.
> Attached is a Backtrace of the issue i am currently observing.
>

That stack trace looks like the automatic clean up of the ObjectCache with 
the DefaultFont within it is related somehow to the crash.  How the 
DefaultFont is managed has changed, to address bugs ironically, and in a 
general sense the clean up the stack trace looks just fine to me, it's 
roughly what I'd expect to happen.  However, I don't have any clear idea 
why in this instance the crash has occurred.

Given there isn't any obvious amiss we are unfortunately are left to widen 
out the search for what is amiss. 

Does running an OSG example like osgtext fail?

Do others in the OpenMMW community seen this same crash?

Is it possible to run OpenMMW single threaded to see if there might be some 
thread interaction?

What OS/compile and OpenMMW version combination are you using?

One possible cause of crash like this is memory corruption during the run 
of the application that is only revealed on clean up.  Using a memory tools 
like valgrind might be spot this type of issue.

Perhaps others might have seen something similar and can help shed some 
light on the nature of the crash.

If it's possible to recreate the crash with an standard OSG example, or a 
small modification of one, then this would be really helpful for me to jump 
in a start investigating the issue.

Cheers.
Robert.

-- 
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/d1bd2b26-bb79-4825-9082-f7d6713480f7%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

38}, data = 
{prev = 0x0, cleanup = 0x0, canceltype = -1500010701}}}
not_first_call = 
#42 0x56125862bdea in _start ()

Am Freitag, 24. Januar 2020 20:26:18 UTC+1 schrieb Robert Osfield:
>
> HI All,
>
> Still waiting on feedback on how well 3.6.5-rc2 is working OK.  I'm ready 
> to tag 3.6.5 at my end as there are no Issue reported yet that I can look 
> into resolving.
>
> If there are no Issue's raised by Monday I'll go ahead and tag 3.6.5 
> stable release.
>
> Cheers,
> Robert.
>

-- 
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/9d9a8df8-202a-4cf3-b53d-23fa4bedd809%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

Hi Chris,

Thanks the links.  I've tracked down the example you created and re-run it
on my system and on the scene graph creation of the second window/view I
get text without textures.

In summary:
>
>- Fabian has done something weird with either OSG or OpenMW that
>hasn't been specified yet.
>
> If the codebase is the same perhaps it comes down to a sensitivity to
compiler version or dependencies?

>
>- It's beginning to feel like you're misspelling OpenMW deliberately.
>
> Sigh.  I likely have dyslexia, while I've never been formally diagnosed I
have the traits, the downside is that I regularily get letters wrong, don't
spot mispellings.  This isn't personal, it's just an issue I have to deal
with, and unfortunately as I read/wrote code and read/write email the
community also have to accept that I don't get everything right every
time.  In other ways my brain functions pretty well so overall I can still
be productive.


>- Regarding the as-yet unresolved default font/object cache not being
>released issue I reported in March, the ball was left in your court with
>nothing more I could do. Hopefully enough has been linked above that we can
>move forward with that again if you've got more time now.
>
>
If this is the one that the attached example recreates then I will be
looking into this today.

-- 
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.67380.1580309147.7166.osg-users-openscenegraph.org%40lists.openscenegraph.org.
cmake_minimum_required(VERSION 2.6)

SET(PROJECT_NAME viewtest)

PROJECT(${PROJECT_NAME})

FIND_PACKAGE(OpenThreads)
FIND_PACKAGE(osg)
FIND_PACKAGE(osgDB)
FIND_PACKAGE(osgUtil)
FIND_PACKAGE(osgGA)
FIND_PACKAGE(osgText)
FIND_PACKAGE(osgViewer)

SET(SOURCES
main.cpp
)

INCLUDE_DIRECTORIES(${OPENTHREADS_INCLUDE_DIR} ${OSG_INCLUDE_DIR})

LINK_DIRECTORIES(${OSG_LIB_DIR})

ADD_EXECUTABLE(${PROJECT_NAME} ${SOURCES})

TARGET_LINK_LIBRARIES(${PROJECT_NAME} ${OSG_LIBRARIES} ${OSGVIEWER_LIBRARIES} 
${OSGUTIL_LIBRARIES} ${OSGDB_LIBRARIES} ${OSGGA_LIBRARIES}  
${OSGTEXT_LIBRARIES} ${OPENTHREADS_LIBRARIES})
#include 

#include 

#include 

#include 

#include 

class AddViewOperation : public osg::Operation
{
public:
AddViewOperation(osg::ref_ptr view)
: osg::Operation("AddView", false)
, _view(view)
{}

void operator() (osg::Object * compositeViewer) override
{
OSG_NOTICE << "AddView operator()" << std::endl;
osgViewer::CompositeViewer * viewer = dynamic_cast(compositeViewer);
viewer->stopThreading();
viewer->addView(_view);
viewer->startThreading();
}

protected:
osg::ref_ptr _view;
};

class RemoveViewOperation : public osg::Operation
{
public:
RemoveViewOperation(osg::ref_ptr view)
: osg::Operation("RemoveView", false)
, _view(view)
{
OSG_NOTICE<<"RemoveViewOperation::RemoveViewOperation()"<(compositeViewer);
viewer->stopThreading();
viewer->removeView(_view);
viewer->startThreading();
}

protected:
osg::ref_ptr _view;
};

class ViewAdder : public osgGA::GUIEventHandler
{
public:
ViewAdder(osgViewer::CompositeViewer * viewer)
: _viewer(viewer)
, _view(nullptr)
{}

bool handle(const osgGA::GUIEventAdapter& ea, osgGA::GUIActionAdapter& aa)
{
if (ea.getEventType() == osgGA::GUIEventAdapter::KEYUP && (ea.getKey() == 'v' || ea.getKey() == 'V'))
{
if (_view)
{
OSG_NOTICE << "Existing view, remove it" << std::endl;
// parts of the scene get removed before the view gets destroyed.
// normally this is fine as things get handled by destructors.
// however, things that are still cached require the cache to be released
_view->setSceneData(nullptr);
// We need to remove the view after the event traversal is done to avoid invalidating iterators
_viewer->addUpdateOperation(new RemoveViewOperation(_view));
_view = nullptr;
}
else
{
OSG_NOTICE << "No existing view, create one" << std::endl;
_view = new osgViewer::View;
_view->setName("View two");

_view->setUpViewInWindow(800, 200, 1024, 768);


osg::ref_ptr text2 = new osgText::Text();
text2->setFont("times.ttf");
text2->setText(&quo

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



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] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

 fa fa
  0x0c067fff9080: fa fa fd fd fd fa fa fa fa fa fa fa fa fa 00 00
  0x0c067fff9090: 05 fa fa fa 00 00 05 fa fa fa fa fa fa fa fa fa
  0x0c067fff90a0: 00 00 07 fa fa fa 00 00 07 fa fa fa fa fa fa fa
Shadow byte legend (one shadow byte represents 8 application bytes):
  Addressable:   00
  Partially addressable: 01 02 03 04 05 06 07 
  Heap left redzone:   fa
  Freed heap region:   fd
  Stack left redzone:  f1
  Stack mid redzone:   f2
  Stack right redzone: f3
  Stack after return:  f5
  Stack use after scope:   f8
  Global redzone:  f9
  Global init order:   f6
  Poisoned by user:f7
  Container overflow:  fc
  Array cookie:ac
  Intra object redzone:bb
  ASan internal:   fe
  Left alloca redzone: ca
  Right alloca redzone:cb
==11872==ABORTING

-- 
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/222411d9-3219-4d28-8090-a0602ce81f01%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

Hi Robert,

As I've mentioned in the past, I'm an OpenMW (note the single M) developer. 
It was actually me who reported the issues with the default font, and only 
a subset were resolved before you went on hiatus. I've lost the thread 
where we were discussing it as I'd bookmarked the forum thread, which is 
now dead. As I recall, though, my most recent minimal 
things-don't-get-relased-when-they-should example was resolvable by a 
couple of potential changes I suggested, but you said they'd have to wait 
until you could investigate more thoroughly, as it was in code no one had 
touched for a while, so could maybe upset other applications, or not 
exhaustively remove all such bugs.

I pretty much stopped trying to make OpenMW play nicely with 3.6.x when you 
disappeared as there wasn't much point if nothing would be mergeable until 
you had more time, and now you do, I don't have much.

Anyway, on to the matter at hand, I don't get the crash, but I'm missing 
some commits in the 3.6 branch, and also I still have one of my proposed 
fixes. I'm making things more upstream-like, and I'll add another sentence 
once everything's rebuilt.

So after waiting an age for everything to rebuild, I got reminded that the 
occlusion query API got changed by Julien Valentine's recent PR. He made a 
PR for OpenMW that was supposed to resolve that, but obviously it didn't 
work until I tweaked it. Once I'd built everything, I tested it, and I'm 
not seeing the crash here. This is with a Debug build of OpenMW and OSG, 
and on Windows, and I don't think anyone else is using debug builds of 
both, especially not on Windows.

I guess that means that I've not really given any more information beyond 
this not being something that happens for everyone. It might be dependent 
on other factors, so a more detailed description of how reliable the crash 
is and whether it's dependent on anything is needed before anyone can do 
anything on OpenMW's end.

One thing of note is that the OpenMW profiler doesn't use the default font 
(at least on my machine). It uses a truetype one. I seem to remember seeing 
it use the default font in the past, and it's not impossible that this is 
toggled via a setting I've forgotten about, but I've had a good look and 
can't find one.

So that's what I know.

Chris

On Monday, 27 January 2020 09:57:23 UTC, Robert Osfield wrote:
>
> Hi Fiabian,
>
> On Monday, 27 January 2020 09:41:43 UTC, Fabian Roth wrote:
>>
>> Hi,
>> I am currently testing this RC with openmw.
>> If i have the fps display or profiler open while exiting the application 
>> i get a crash on exit.
>> I am not sure if this is due to a bug in my build, a bug in openmw or a 
>> real issue with osg.
>> The issue seems to be related to the destruction of the default font, but 
>> i was not able to investigate further.
>> Attached is a Backtrace of the issue i am currently observing.
>>
>
> That stack trace looks like the automatic clean up of the ObjectCache with 
> the DefaultFont within it is related somehow to the crash.  How the 
> DefaultFont is managed has changed, to address bugs ironically, and in a 
> general sense the clean up the stack trace looks just fine to me, it's 
> roughly what I'd expect to happen.  However, I don't have any clear idea 
> why in this instance the crash has occurred.
>
> Given there isn't any obvious amiss we are unfortunately are left to widen 
> out the search for what is amiss. 
>
> Does running an OSG example like osgtext fail?
>
> Do others in the OpenMMW community seen this same crash?
>
> Is it possible to run OpenMMW single threaded to see if there might be 
> some thread interaction?
>
> What OS/compile and OpenMMW version combination are you using?
>
> One possible cause of crash like this is memory corruption during the run 
> of the application that is only revealed on clean up.  Using a memory tools 
> like valgrind might be spot this type of issue.
>
> Perhaps others might have seen something similar and can help shed some 
> light on the nature of the crash.
>
> If it's possible to recreate the crash with an standard OSG example, or a 
> small modification of one, then this would be really helpful for me to jump 
> in a start investigating the issue.
>
> Cheers.
> Robert.
>
>
>
>
>  
>
>
>  
>

-- 
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/ff578130-867c-4c93-9fb0-fd573b20ab91%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

Hi Fabian,


> My build is using static osg, static osg-plugins and link time
> optimization.
> I created an address sanitizer enabled build.
> It exhibits a heap-use-after-free.
> I will try to further investigate this week.
>
> =
> ==11872==ERROR: AddressSanitizer: heap-use-after-free on address
> 0x603082c0 at pc 0x55b4b9659551 bp 0x7ffdf8a9c190 sp 0x7ffdf8a9c180
> READ of size 8 at 0x603082c0 thread T0
> #0 0x55b4b9659550 in
> OpenThreads::ScopedPointerLock::ScopedPointerLock(OpenThreads::Mutex*)
> ./openmw/extern-git/OpenSceneGraph/include/OpenThreads/ScopedLock:54
> #1 0x55b4b9659550 in osg::StateAttribute::removeParent(osg::StateSet*)
> ./openmw/extern-git/OpenSceneGraph/src/osg/StateAttribute.cpp:38
> #2 0x55b4b965a033 in osg::StateSet::clear()
> ./openmw/extern-git/OpenSceneGraph/src/osg/StateSet.cpp:734
>

Given the stack trace it kinda looks like the getRefMutex() call in
StateAttribute.cpp is the where things might be going astray (note the
comment I've added below):

void StateAttribute::removeParent(osg::StateSet* object)
{
OpenThreads::ScopedPointerLock lock(getRefMutex());
// calls the base classes Referenced::getRefMutex() method that will map to
Referenced::getGlobalReferencedMutex

ParentList::iterator pitr =
std::find(_parents.begin(),_parents.end(),object);
if (pitr!=_parents.end()) _parents.erase(pitr);
}

The Referenced::getGlobalReferencedMutex() implementation in Referenced.cpp
is:

OpenThreads::Mutex* Referenced::getGlobalReferencedMutex()
{
static GlobalMutexPointer s_ReferencedGlobalMutext = new
OpenThreads::Mutex;
return s_ReferencedGlobalMutext.get();
}

// helper class for forcing the global mutex to be constructed when the
library is loaded.
struct InitGlobalMutexes
{
InitGlobalMutexes()
{
Referenced::getGlobalReferencedMutex();
}
};
static InitGlobalMutexes s_initGlobalMutexes;

Which is all a bit hacky way of trying to get a singleton's
_ReferencedGlobalMutext to construct before any other code calling
getGlobalReferencedMutex() gets called.

I don't really know why a pointer is even being used here, it's not how I'd
write the code these days, but off the top of my head don't recall the
derivation and motivations between all this code as it dates back to the
earliest days of the OSG project, so almost two decades :-)

What I'd write today would simply be:

static OpenThreads::Mutex s_ReferencedGlobalMutex;
OpenThreads::Mutex* Referenced::getGlobalReferencedMutex()
{
return _ReferencedGlobalMutex;
}

You could try substituting this in.  I will try a build here just to make
sure the above works fine for standard OSG work.  I don't expect this
change to have any affect on your own code, if it does it suggest there is
some issue with order of clean up of statics.

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

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

Hi Chris,

On Mon, 27 Jan 2020 at 23:51, OpenSceneGraph Users <
osg-users@lists.openscenegraph.org> wrote:

> As I've mentioned in the past, I'm an OpenMW (note the single M)
> developer. It was actually me who reported the issues with the default
> font, and only a subset were resolved before you went on hiatus. I've lost
> the thread where we were discussing it as I'd bookmarked the forum thread,
> which is now dead. As I recall, though, my most recent minimal
> things-don't-get-relased-when-they-should example was resolvable by a
> couple of potential changes I suggested, but you said they'd have to wait
> until you could investigate more thoroughly, as it was in code no one had
> touched for a while, so could maybe upset other applications, or not
> exhaustively remove all such bugs.
>

The googlegroup has search options, here's what I get if I search for
OpenMW. it comes up with several threads with you contributing:

https://groups.google.com/forum/#!searchin/osg-users/OpenMW%7Csort:date


> I pretty much stopped trying to make OpenMW play nicely with 3.6.x when
> you disappeared as there wasn't much point if nothing would be mergeable
> until you had more time, and now you do, I don't have much.
>

I had to step back from the OSG support side as it consumes so much time
and mind-share, it's not really possible to tackle other complex work at
the same time so I'm having to block the OSG support side and not tackle
any complex other work during this period. I don't disappear completely, I
just step back.

Anyway, on to the matter at hand, I don't get the crash, but I'm missing
> some commits in the 3.6 branch, and also I still have one of my proposed
> fixes. I'm making things more upstream-like, and I'll add another sentence
> once everything's rebuilt.
>

If you have things you feel would be suitable to merge with the 3.6 branch
please make them. I can't review and provide feedback.  To properly judge
changes I do need to understand the motivation behind them, it may be that
the changes are workaround issues that are based solved in other ways.


> So after waiting an age for everything to rebuild, I got reminded that the
> occlusion query API got changed by Julien Valentine's recent PR. He made a
> PR for OpenMW that was supposed to resolve that, but obviously it didn't
> work until I tweaked it. Once I'd built everything, I tested it, and I'm
> not seeing the crash here. This is with a Debug build of OpenMW and OSG,
> and on Windows, and I don't think anyone else is using debug builds of
> both, especially not on Windows.
>

When you say not seeing the crash, I we talking about a different issue to
what Fabian was referring to?  Is Fabian working on the same versions of
OpenME and OSG as yourself?

I guess that means that I've not really given any more information beyond
> this not being something that happens for everyone. It might be dependent
> on other factors, so a more detailed description of how reliable the crash
> is and whether it's dependent on anything is needed before anyone can do
> anything on OpenMW's end.
>
> One thing of note is that the OpenMW profiler doesn't use the default font
> (at least on my machine). It uses a truetype one. I seem to remember seeing
> it use the default font in the past, and it's not impossible that this is
> toggled via a setting I've forgotten about, but I've had a good look and
> can't find one.
>

The OSG falls back to using the DefaultFont when the requested font can't
be found, so any chance this might be happening?  Something like font files
missing, case of the font being different - Windows isn't case sensitive so
when you move to a case sensitive OS you can see issues if there are errors
in the filename.

Cheers,
Robert.

-- 
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.67301.1580201727.7167.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.67301.1580201727.7167.osg-users-openscenegraph.org%40lists.openscenegraph.org.

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

Hello again.

The googlegroup has search options, here's what I get if I search for 
> OpenMW. it comes up with several threads with you contributing:
>
> https://groups.google.com/forum/#!searchin/osg-users/OpenMW%7Csort:date
>

I can find chunks of the right thread (this is some: 
https://groups.google.com/forum/#!searchin/osg-users/OpenMW|sort:date/osg-users/4lwB0MZdPqM/-ohFXtp-CQAJ)

but some seems to be missing. For example, this newer chunk shows up as a 
separate thread: 
https://groups.google.com/forum/#!searchin/osg-users/anyoldname3|sort:date/osg-users/lbFxUItJ_qc/KEkYK_1dAgAJ.

It's reasonably likely that that's the end of the thread.

I don't disappear completely, I just step back.
>

I'm aware of the reasoning and that it's not total. It still has a pretty 
big impact on how much OSG work you actually get done, so I feel my word 
choice isn't that extreme.

If you have things you feel would be suitable to merge with the 3.6 branch 
> please make them. I can't review and provide feedback.  To properly judge 
> changes I do need to understand the motivation behind them, it may be that 
> the changes are workaround issues that are based solved in other ways.
>

https://groups.google.com/d/msg/osg-users/lbFxUItJ_qc/c54xoN8oAAAJ has a 
diff that resolved my problem and I suggested went into 3.6. A few posts 
lower, there's what we both agreed was the source for a simple application 
that didn't work. You said you'd look into it in more detail later in the 
hope of finding other potential solutions. I can't do that for you. I put 
days into this and couldn't find any better solutions than the one I 
posted. That might have been because I didn't write OSG and am unaware of a 
nifty feature that will fix everything, because I'm not actually clever 
enough to conceive of the right approach, or because there's genuinely no 
other option. It's certainly not because I didn't do a thorough enough 
investigation.

When you say not seeing the crash, I we talking about a different issue to 
> what Fabian was referring to?  Is Fabian working on the same versions of 
> OpenME and OSG as yourself?
>

I was referring to the crash he was seeing with the profiler. It's still 
called *OpenMW* with one *O* and one *W*, by the way. My testing was with 
the 3.6 branch of OSG as of 9b41f260 and master branch OpenMW from a few 
weeks ago. I've also got minor local changes to adapt to the Julien 
Valentine occlusion query PR you merged recently. Nothing that touches 
anything relevant to Fabian's crash has been merged since then, so latest 
master branch OpenMW is a good analogue for what I'm using. I suspect 
Fabian isn't using the same OSG and OpenMW as me exactly, as he needs to 
either merge this https://github.com/OpenMW/openmw/pull/2676 (or something 
like it) or use an OSG revision from before this 
https://github.com/openscenegraph/OpenSceneGraph/pull/902 got merged.

The OSG falls back to using the DefaultFont when the requested font can't 
> be found, so any chance this might be happening?  Something like font files 
> missing, case of the font being different - Windows isn't case sensitive so 
> when you move to a case sensitive OS you can see issues if there are errors 
> in the filename.
>

I've checked, and we switched to using a bundled TTF font in the middle of 
2018. Most development happens on Linux (and the person who switched the 
font over uses it exclusively) so the only way it wouldn't be finding the 
font would be if Fabian's doing something weird.

My build is using static osg, static osg-plugins and link time optimization.
>

For example, this could be the weird thing. We don't test statically linked 
OSG, although our semi-official Android port does things that way (it's not 
maintained by the core team, just one guy on his own, and it's got plenty 
of shortcomings). One possibility is that the Freetype plugin just got left 
out when building. Renaming the DLL so OpenMW couldn't see it did make it 
use the OSG default font in the profiler, but didn't allow me to reproduce 
Fabian's crash.

In summary:

   - Fabian has done something weird with either OSG or OpenMW that hasn't 
   been specified yet.
   - It's beginning to feel like you're misspelling OpenMW deliberately.
   - Regarding the as-yet unresolved default font/object cache not being 
   released issue I reported in March, the ball was left in your court with 
   nothing more I could do. Hopefully enough has been linked above that we can 
   move forward with that again if you've got more time now.
   - Without knowing what source code Fabian has built, I can't reproduce 
   or identify the issue he's seeing.

Cheers,

Chris

On Tuesday, 28 January 2020 11:51:31 UTC, OpenSceneGraph Users wrote:
>
> Hi Fabian & Chris,
>
> I was curious about the clean up of the global getGlobalReferencedMutex() 
> so I added some debug messages to OpenThreads and to relev

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test



On Tuesday, January 28, 2020 at 10:11:49 AM UTC+1, OpenSceneGraph Users 
wrote:
>
> Hi Fabian,
>  
>
>> My build is using static osg, static osg-plugins and link time 
>> optimization.
>> I created an address sanitizer enabled build.
>> It exhibits a heap-use-after-free.
>> I will try to further investigate this week.
>>
>> =
>> ==11872==ERROR: AddressSanitizer: heap-use-after-free on address 
>> 0x603082c0 at pc 0x55b4b9659551 bp 0x7ffdf8a9c190 sp 0x7ffdf8a9c180
>> READ of size 8 at 0x603082c0 thread T0
>> #0 0x55b4b9659550 in 
>> OpenThreads::ScopedPointerLock::ScopedPointerLock(OpenThreads::Mutex*)
>>  
>> ./openmw/extern-git/OpenSceneGraph/include/OpenThreads/ScopedLock:54
>> #1 0x55b4b9659550 in 
>> osg::StateAttribute::removeParent(osg::StateSet*) 
>> ./openmw/extern-git/OpenSceneGraph/src/osg/StateAttribute.cpp:38
>> #2 0x55b4b965a033 in osg::StateSet::clear() 
>> ./openmw/extern-git/OpenSceneGraph/src/osg/StateSet.cpp:734
>>
>
> Given the stack trace it kinda looks like the getRefMutex() call in 
> StateAttribute.cpp is the where things might be going astray (note the 
> comment I've added below):
>
> void StateAttribute::removeParent(osg::StateSet* object)
> {
> OpenThreads::ScopedPointerLock 
> lock(getRefMutex()); // calls the base classes Referenced::getRefMutex() 
> method that will map to Referenced::getGlobalReferencedMutex
>
> ParentList::iterator pitr = 
> std::find(_parents.begin(),_parents.end(),object);
> if (pitr!=_parents.end()) _parents.erase(pitr);
> }
>
> The Referenced::getGlobalReferencedMutex() implementation in 
> Referenced.cpp is:
>
> OpenThreads::Mutex* Referenced::getGlobalReferencedMutex()
> {
> static GlobalMutexPointer s_ReferencedGlobalMutext = new 
> OpenThreads::Mutex;
> return s_ReferencedGlobalMutext.get();
> }
>
> // helper class for forcing the global mutex to be constructed when the 
> library is loaded.
> struct InitGlobalMutexes
> {
> InitGlobalMutexes()
> {
> Referenced::getGlobalReferencedMutex();
> }
> };
> static InitGlobalMutexes s_initGlobalMutexes;
>
> Which is all a bit hacky way of trying to get a singleton's 
> _ReferencedGlobalMutext to construct before any other code calling 
> getGlobalReferencedMutex() gets called.
>
> I don't really know why a pointer is even being used here, it's not how 
> I'd write the code these days, but off the top of my head don't recall the 
> derivation and motivations between all this code as it dates back to the 
> earliest days of the OSG project, so almost two decades :-)
>
> What I'd write today would simply be:
>
> static OpenThreads::Mutex s_ReferencedGlobalMutex;
> OpenThreads::Mutex* Referenced::getGlobalReferencedMutex()
> {
> return _ReferencedGlobalMutex;
> }
>
> You could try substituting this in.  I will try a build here just to make 
> sure the above works fine for standard OSG work.  I don't expect this 
> change to have any affect on your own code, if it does it suggest there is 
> some issue with order of clean up of statics.
>
> Robert.
>

Hi Robert,
Using your suggested changes i get a crash on start.
I forgot to mention i also link OpenThreads statically.
I am starting to suspect the static linking and optimization surfaces 
undefined behavior.

Greetings,
Fabian

ASAN:DEADLYSIGNAL
=
==19668==ERROR: AddressSanitizer: SEGV on unknown address 0x0010 
(pc 0x5597ebadb5ac bp 0x60c00b80 sp 0x7ffce8efbba0 T0)
==19668==The signal is caused by a READ memory access.
==19668==Hint: address points to the zero page.
#0 0x5597ebadb5ab in 
OpenThreads::ScopedPointerLock::ScopedPointerLock(OpenThreads::Mutex*)
 
./openmw/extern-git/OpenSceneGraph/include/OpenThreads/ScopedLock:54
#1 0x5597ebadb5ab in addParent 
./openmw/extern-git/OpenSceneGraph/src/osg/StateAttribute.cpp:31
#2 0x5597ebadbc84 in setAttribute 
./openmw/extern-git/OpenSceneGraph/src/osg/StateSet.cpp:1784
#3 0x5597ebadc737 in 
osg::StateSet::setAttributeAndModes(osg::StateAttribute*, unsigned int) 
[clone .part.309] 
./openmw/extern-git/OpenSceneGraph/src/osg/StateSet.cpp:1076
#4 0x5597ebcb7241 in __base_ctor  
./openmw/extern-git/OpenSceneGraph/src/osgUtil/RenderBin.cpp:174
#5 0x5597ebcb7a37 in __base_ctor  
./openmw/extern-git/OpenSceneGraph/src/osgUtil/RenderBin.cpp:37
#6 0x5597ebcb7a37 in renderBinPrototypeList 
./openmw/extern-git/OpenSceneGraph/src/osgUtil/RenderBin.cpp:53
#7 0x5597eab5bacb in RenderBinSingletonProxy::RenderBinSingletonProxy() 
./openmw/extern-git/OpenSceneGraph/src/osgUtil/RenderBin.

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

Hi Robert,

I'm reasonably sure that Fabian's crash isn't the same issue as that 
example exposes.

>>- Fabian has done something weird with either OSG or OpenMW that 
>>hasn't been specified yet.
>>
>> If the codebase is the same perhaps it comes down to a sensitivity to 
> compiler version or dependencies?
>

We have official builds for a variety of Linux distros, Windows and MacOS 
(and semi-official builds for Android that are generally less reliable) so 
we should have pretty good coverage with known-good dependency and tooling 
versions. As I've mentioned before, the most likely culprit for this 
suddenly appearing for Fabian is that we pretty much never link to OSG 
statically. It's a nightmare on Windows (I don't think anyone's even 
attempted it in the last five years) but is more feasible on Linux, where 
the majority of our contributors are, so I've put out a call for other 
testers to try and reproduce the problem.

Also, Robert, I'm assuming you don't have a copy of Morrowind to test 
OpenMW with. Right now, Steam, GreenManGaming and Fanatical are all 
offering it for less than £4, but at least one of those sales ends in less 
than twenty hours. If you're not keen, £4 is a reasonable investment for me 
to make to increase cooperation between our projects, but it would help if 
you got back to me quickly.

Thanks,

Chris

On Wednesday, 29 January 2020 14:46:02 UTC, OpenSceneGraph Users wrote:
>
> Hi Chris,
>
> Thanks the links.  I've tracked down the example you created and re-run it 
> on my system and on the scene graph creation of the second window/view I 
> get text without textures.  
>
> In summary:
>>
>>- Fabian has done something weird with either OSG or OpenMW that 
>>hasn't been specified yet.
>>
>> If the codebase is the same perhaps it comes down to a sensitivity to 
> compiler version or dependencies?
>
>>
>>- It's beginning to feel like you're misspelling OpenMW deliberately.
>>
>> Sigh.  I likely have dyslexia, while I've never been formally diagnosed I 
> have the traits, the downside is that I regularily get letters wrong, don't 
> spot mispellings.  This isn't personal, it's just an issue I have to deal 
> with, and unfortunately as I read/wrote code and read/write email the 
> community also have to accept that I don't get everything right every 
> time.  In other ways my brain functions pretty well so overall I can still 
> be productive.
>
>
>>- Regarding the as-yet unresolved default font/object cache not being 
>>released issue I reported in March, the ball was left in your court with 
>>nothing more I could do. Hopefully enough has been linked above that we 
>> can 
>>move forward with that again if you've got more time now.
>>
>>
> If this is the one that the attached example recreates then I will be 
> looking into this today.
>  
>

-- 
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/73cd3f2d-7a89-4ded-b247-e3586cea02ca%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] DefaultFont crash issue

Hi Robert,

In relation to the DefaultFont crash issue, I noticed that my code would
occasionally crash on creation of osgText::Text.
Most of my osgText::Text is not created on the main thread.
In order to avoid the DefaultFont crash, I created a
osg::ref_ptr necessaryFont = osgText::Font::getDefaultFont();
which sticks around from the beginning of the program to the end and
doesn't get used by anything.
After I did this, my code no longer crashed on osgText::Text creation.
The OpenSceneGraph version used is 3.6.4 and on both Windows (7 64-bit) and
Linux (Ubuntu 16.04).
Also when I was previously using OpenSceneGraph version 3.6.2,
osgText::Text creation never crashed.

Regards,
Anna



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

> Hi Robert,
>
> I'm reasonably sure that Fabian's crash isn't the same issue as that
> example exposes.
>
>
>>>- Fabian has done something weird with either OSG or OpenMW that
>>>hasn't been specified yet.
>>>
>>> If the codebase is the same perhaps it comes down to a sensitivity to
>> compiler version or dependencies?
>>
>
> We have official builds for a variety of Linux distros, Windows and MacOS
> (and semi-official builds for Android that are generally less reliable) so
> we should have pretty good coverage with known-good dependency and tooling
> versions. As I've mentioned before, the most likely culprit for this
> suddenly appearing for Fabian is that we pretty much never link to OSG
> statically. It's a nightmare on Windows (I don't think anyone's even
> attempted it in the last five years) but is more feasible on Linux, where
> the majority of our contributors are, so I've put out a call for other
> testers to try and reproduce the problem.
>
>
>
> Also, Robert, I'm assuming you don't have a copy of Morrowind to test
> OpenMW with. Right now, Steam, GreenManGaming and Fanatical are all
> offering it for less than £4, but at least one of those sales ends in less
> than twenty hours. If you're not keen, £4 is a reasonable investment for me
> to make to increase cooperation between our projects, but it would help if
> you got back to me quickly.
>
> Thanks,
>
> Chris
>
> On Wednesday, 29 January 2020 14:46:02 UTC, OpenSceneGraph Users wrote:
>>
>> Hi Chris,
>>
>> Thanks the links.  I've tracked down the example you created and re-run
>> it on my system and on the scene graph creation of the second window/view I
>> get text without textures.
>>
>> In summary:
>>>
>>>- Fabian has done something weird with either OSG or OpenMW that
>>>hasn't been specified yet.
>>>
>>> If the codebase is the same perhaps it comes down to a sensitivity to
>> compiler version or dependencies?
>>
>>>
>>>- It's beginning to feel like you're misspelling OpenMW deliberately.
>>>
>>> Sigh.  I likely have dyslexia, while I've never been formally diagnosed
>> I have the traits, the downside is that I regularily get letters wrong,
>> don't spot mispellings.  This isn't personal, it's just an issue I have to
>> deal with, and unfortunately as I read/wrote code and read/write email the
>> community also have to accept that I don't get everything right every
>> time.  In other ways my brain functions pretty well so overall I can still
>> be productive.
>>
>>
>>>- Regarding the as-yet unresolved default font/object cache not
>>>being released issue I reported in March, the ball was left in your court
>>>    with nothing more I could do. Hopefully enough has been linked above that
>>>we can move forward with that again if you've got more time now.
>>>
>>>
>> If this is the one that the attached example recreates then I will be
>> looking into this today.
>>
>>
> --
> 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/73cd3f2d-7a89-4ded-b247-e3586cea02ca%40googlegroups.com
> <https://groups.google.com/d/msgid/osg-users/73cd3f2d-7a89-4ded-b247-e3586cea02ca%40googlegroups.com?utm_medium=email_source=footer>
> .
> ___
> 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] DefaultFont crash issue

Hi Anna,

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

> In relation to the DefaultFont crash issue, I noticed that my code would
> occasionally crash on creation of osgText::Text.
> Most of my osgText::Text is not created on the main thread.
> In order to avoid the DefaultFont crash, I created a
> osg::ref_ptr necessaryFont =
> osgText::Font::getDefaultFont();
> which sticks around from the beginning of the program to the end and
> doesn't get used by anything.
> After I did this, my code no longer crashed on osgText::Text creation.
> The OpenSceneGraph version used is 3.6.4 and on both Windows (7 64-bit)
> and Linux (Ubuntu 16.04).
> Also when I was previously using OpenSceneGraph version 3.6.2,
> osgText::Text creation never crashed.
>

This sounds like a bug somewhere in the initialization of the Font, to
investigate I'll need to reproduce the problem on my system.

Does the multi-theaded test code path in osgtext fail for you as well:

   osgtext --mt

I have just tried this on my Kubunutu 18.04 system with the 3.6 branch and
it works fine.

Could you create a small test program that illustrates what you are doing?

Cheers,
Robert.

-- 
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.67694.1580375800.7167.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.67694.1580375800.7167.osg-users-openscenegraph.org%40lists.openscenegraph.org.

Re: [osg-users] DefaultFont crash issue

Hi all,

I have new information about what Fabian has done that's weird. When he's 
been saying he's doing static linking, he's not doing what most people 
would associate that phrase with (i.e. building OSG to a library file such 
that all code is contained within and consuming that when linking OpenMW). 
Instead, it's more like what CMake calls an object library - he's building 
dependencies to intermediate-representation object files, but only doing 
translation to native code and linking once when everything's an object 
file. I wouldn't be surprised if this puts static initialisers and 
destructors in orders they've never been in before and that's what's 
causing the problem.

Hopefully this will point the investigation in the right direction.

Cheers,

Chris

On Wednesday, 29 January 2020 22:38:08 UTC, OpenSceneGraph Users wrote:
>
> Hi Robert,
>
> In relation to the DefaultFont crash issue, I noticed that my code would 
> occasionally crash on creation of osgText::Text. 
> Most of my osgText::Text is not created on the main thread. 
> In order to avoid the DefaultFont crash, I created a 
> osg::ref_ptr necessaryFont = 
> osgText::Font::getDefaultFont();
> which sticks around from the beginning of the program to the end and 
> doesn't get used by anything.
> After I did this, my code no longer crashed on osgText::Text creation.
> The OpenSceneGraph version used is 3.6.4 and on both Windows (7 64-bit) 
> and Linux (Ubuntu 16.04).
> Also when I was previously using OpenSceneGraph version 3.6.2, 
> osgText::Text creation never crashed.
>
> Regards,
> Anna
>
>
>
> On Wed, Jan 29, 2020 at 5:15 PM OpenSceneGraph Users <
> osg-...@lists.openscenegraph.org > wrote:
>
>> Hi Robert,
>>
>> I'm reasonably sure that Fabian's crash isn't the same issue as that 
>> example exposes.
>>
>>
>>>>- Fabian has done something weird with either OSG or OpenMW that 
>>>>hasn't been specified yet.
>>>>
>>>> If the codebase is the same perhaps it comes down to a sensitivity to 
>>> compiler version or dependencies?
>>>
>>
>> We have official builds for a variety of Linux distros, Windows and MacOS 
>> (and semi-official builds for Android that are generally less reliable) so 
>> we should have pretty good coverage with known-good dependency and tooling 
>> versions. As I've mentioned before, the most likely culprit for this 
>> suddenly appearing for Fabian is that we pretty much never link to OSG 
>> statically. It's a nightmare on Windows (I don't think anyone's even 
>> attempted it in the last five years) but is more feasible on Linux, where 
>> the majority of our contributors are, so I've put out a call for other 
>> testers to try and reproduce the problem.
>>
>>
>>
>> Also, Robert, I'm assuming you don't have a copy of Morrowind to test 
>> OpenMW with. Right now, Steam, GreenManGaming and Fanatical are all 
>> offering it for less than £4, but at least one of those sales ends in less 
>> than twenty hours. If you're not keen, £4 is a reasonable investment for me 
>> to make to increase cooperation between our projects, but it would help if 
>> you got back to me quickly.
>>
>> Thanks,
>>
>> Chris
>>
>> On Wednesday, 29 January 2020 14:46:02 UTC, OpenSceneGraph Users wrote:
>>>
>>> Hi Chris,
>>>
>>> Thanks the links.  I've tracked down the example you created and re-run 
>>> it on my system and on the scene graph creation of the second window/view I 
>>> get text without textures.  
>>>
>>> In summary:
>>>>
>>>>- Fabian has done something weird with either OSG or OpenMW that 
>>>>hasn't been specified yet.
>>>>
>>>> If the codebase is the same perhaps it comes down to a sensitivity to 
>>> compiler version or dependencies?
>>>
>>>>
>>>>- It's beginning to feel like you're misspelling OpenMW 
>>>>deliberately.
>>>>
>>>> Sigh.  I likely have dyslexia, while I've never been formally diagnosed 
>>> I have the traits, the downside is that I regularily get letters wrong, 
>>> don't spot mispellings.  This isn't personal, it's just an issue I have to 
>>> deal with, and unfortunately as I read/wrote code and read/write email the 
>>> community also have to accept that I don't get everything right every 
>>> time.  In other ways my brain functions pretty well so overall I can still 
>>> be productive.
>>>
>>>
>>>>- Regarding the as-yet unresolved default font/object cach

Re: [osg-users] DefaultFont crash issue

I too have seen thread-related issues when creating Text from multiple
threads. I was never able to find the time to debug it to conclusion; but I
suspect that a shared Font object that needs to create new Glyph textures
isn't doing so in a thread-safe manner. For example,
Font::assignGlyphToGlyphTexture() modifies some structures without Mutex
protection. Just something to check.

Glenn Waldron / osgEarth


On Thu, Jan 30, 2020 at 4:36 AM OpenSceneGraph Users <
osg-users@lists.openscenegraph.org> wrote:

> Hi Anna,
>
> On Wed, 29 Jan 2020 at 22:38, OpenSceneGraph Users <
> osg-users@lists.openscenegraph.org> wrote:
>
>> In relation to the DefaultFont crash issue, I noticed that my code would
>> occasionally crash on creation of osgText::Text.
>> Most of my osgText::Text is not created on the main thread.
>> In order to avoid the DefaultFont crash, I created a
>> osg::ref_ptr necessaryFont =
>> osgText::Font::getDefaultFont();
>> which sticks around from the beginning of the program to the end and
>> doesn't get used by anything.
>> After I did this, my code no longer crashed on osgText::Text creation.
>> The OpenSceneGraph version used is 3.6.4 and on both Windows (7 64-bit)
>> and Linux (Ubuntu 16.04).
>> Also when I was previously using OpenSceneGraph version 3.6.2,
>> osgText::Text creation never crashed.
>>
>
> This sounds like a bug somewhere in the initialization of the Font, to
> investigate I'll need to reproduce the problem on my system.
>
> Does the multi-theaded test code path in osgtext fail for you as well:
>
>osgtext --mt
>
> I have just tried this on my Kubunutu 18.04 system with the 3.6 branch and
> it works fine.
>
> Could you create a small test program that illustrates what you are doing?
>
> Cheers,
> 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 with applying global default attributes?

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] Rendering dynamic occupancy grid

2020-02-05 Thread OpenSceneGraph Users

I want to render a 2D dynamic occupancy grid with large number of cells, 
with each grid cell of different color based on some probability info. I'm 
wondering if osg::shader is a must for the sake of performance. Thanks!

-- 
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/0a9c7759-d0f1-44da-8719-8c7bb3574e5f%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Rendering dynamic occupancy grid




On Thursday, 6 February 2020 07:42:06 UTC, zqh wrote:
>
> I want to render a 2D dynamic occupancy grid with large number of cells, 
> with each grid cell of different color based on some probability info. I'm 
> wondering if osg::shader is a must for the sake of performance. Thanks!
>

Could you provide a screenshot of roughly what you are trying to achieve?

When you say large number of cells, what dimensions of grid and your 
thinking of?

What is rate of update of the input data that control the cells?

What is hardware constraints and performance you are aiming for?

What have you tried so far?  What are your results?

Cheers,
Robert.
 

-- 
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/20ed0ac2-8c97-4a79-a3ba-fb67dd191ad0%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] LineSegmentIntersector and MatrixTransform nodes

This is an old issue that appears to still be in 3.6.3
It appears that if any geometry is under a MatrixTransform node then
osg::LineSegmentIntersector fails to intersect properly with this
geometry.  I am not using scaling in the matrix transform.The only solution
is to manually transform the geometry and not use any MatrixTransforms.

Thx
Andrew

-- 
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.69113.1581012041.7167.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.69113.1581012041.7167.osg-users-openscenegraph.org%40lists.openscenegraph.org.

Re: [osg-users] LineSegmentIntersector and MatrixTransform nodes

Hi Andrew,

On Thu, 6 Feb 2020 at 18:11, OpenSceneGraph Users <
osg-users@lists.openscenegraph.org> wrote:

> This is an old issue that appears to still be in 3.6.3
> It appears that if any geometry is under a MatrixTransform node then
> osg::LineSegmentIntersector fails to intersect properly with this
> geometry.  I am not using scaling in the matrix transform.The only solution
> is to manually transform the geometry and not use any MatrixTransforms.
>

This should work fine, perhaps you doing something inappropriate.
Could you provide an example that illustrates the problem?

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

Re: [osg-users] Rendering dynamic occupancy grid

I don’t think a shader is a must, given your description. Have you considered 
simply creating a texture where each pixel represents a cell of your grid?

Guy Volckaert
Senior Software Engineer

Meggitt Training Systems (Quebec) Inc.
Systèmes d’entraînement Meggitt (Québec) Inc.
6140 Henri Bourassa West
Montreal, Quebec, H4R 3A6
Canada

Tel: 1 (514) 339 9938 Ext 617
Fax: 1 (514) 339 2641
Mobile: 1 (514) 928 5641
skype: guy.volckaert
guy.volcka...@meggitt.com<mailto:guy.volcka...@meggitt.com>
www.meggitt.com<http://www.meggitt.com/>


From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of OpenSceneGraph Users
Sent: February 5, 2020 2:12 PM
To: OpenSceneGraph Users 
Subject: [osg-users] Rendering dynamic occupancy grid

*** This e-mail originated from the public Internet and its authenticity cannot 
be confirmed. Please exercise caution when you open attachments or click on 
links contained within the message – Meggitt MIS ***

I want to render a 2D dynamic occupancy grid with large number of cells, with 
each grid cell of different color based on some probability info. I'm wondering 
if osg::shader is a must for the sake of performance. Thanks!
--
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<mailto:osg-users+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/osg-users/0a9c7759-d0f1-44da-8719-8c7bb3574e5f%40googlegroups.com<https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_msgid_osg-2Dusers_0a9c7759-2Dd0f1-2D44da-2D8719-2D8c7bb3574e5f-2540googlegroups.com-3Futm-5Fmedium-3Demail-26utm-5Fsource-3Dfooter=DwMFaQ=qLqNacw0Yb7yQVtNq3JZjw=zWo-Tw9Oq46R7IRQO1SdxuPIKmLepAibHly52V3p1sY=I68-5kENCAhl8z0rMwHWHqC1tRtSP9L_KxDLWYa4L8Q=rynNgswpsO7RIJ4G8cc-ZEDtRzANZoHaOGsW3FAHt-s=>.




This e-mail may contain proprietary information and/or copyright material. This 
e-mail is intended for the use of the addressee only. Any unauthorized use may 
be unlawful. If you receive this e-mail by mistake, please advise the sender 
immediately by using the reply facility in your e-mail software. Information 
contained in and/or attached to this document may be subject to export control 
regulations of the European Community, USA, or other countries. Each recipient 
of this document is responsible to ensure that usage and/or transfer of any 
information contained in this document complies with all relevant export 
control regulations. If you are in any doubt about the export control 
restrictions that apply to this information, please contact the sender 
immediately. Be aware that Meggitt may monitor incoming and outgoing e-mails to 
ensure compliance with the Meggitt IT Use policy. Unless otherwise agreed by 
Meggitt, products and services are supplied on the terms of the Meggitt 
Standard Global Terms and Conditions of Sale available at www.meggitt.com or on 
request. .

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

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

Hi Robert,

That commit does indeed seem to have fixed my minimal reproducible example, 
and, unlike with my other minimal reproducible examples, it's fixed the 
issue with the OpenMW-CS, too. Thanks for getting that sorted.

Now I just have to remember what my favourite workaround for 3.4.1 was...

Cheers,

Chris

On Thursday, 30 January 2020 16:30:05 UTC, Robert Osfield wrote:
>
> Hi Chris et. al,
>
> On Thursday, 30 January 2020 14:39:08 UTC, OpenSceneGraph Users wrote:
>>
>> I slowly closing in on the cause of the Font issue, currently it looks 
>> like the removeView() is behaving differently form the CompositeViewer 
>> destructor and not handling clean up of contexts correctly.  I need to 
>> refactor how things are done internally, but expect to have a solution 
>> checked in this afternoon.
>>
>
> I have now checked a fix to the CompositeViewer::removeView() bug where GL 
> objects, including the Font, were not being cleaned up correctly.
>
>  
> https://github.com/openscenegraph/OpenSceneGraph/commit/25868955d2214139722806d20d2c4b60e32d4a61
>
> Cheers,
> Robert.
>

-- 
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/ef7190c6-6de8-4f0a-84be-4ffaefe30ecc%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test



On Wednesday, January 29, 2020 at 11:02:48 AM UTC+1, Robert Osfield wrote:
>
> Hi Fabian,
>
> On Wednesday, 29 January 2020 00:24:35 UTC, Fabian Roth wrote:
>>
>> Hi Chris,
>> I am using the latest openmw master with the compatibility patch from the 
>> pull request cherry picked, my build changes and minor other tweaks.
>> I use the osg rc with a only a cmake version change.
>> The branches are here:
>> https://github.com/Eli2/openmw/tree/eli2-openmw-static
>> https://github.com/Eli2/OpenSceneGraph/tree/eli2-openmw-static
>>
>> By now i strongly suspect i run into the "Static Initialization Order 
>> Fiasco", as described here:
>> https://cryptopp.com/wiki/Static_Initialization_Order_Fiasco
>>
>> I am currently looking into why my build uses the default font.
>>
>
> The way that the singleton methods are done is an attempt to resolve the 
> construction order issue, but l don't recall a focus on the destruction 
> side.  It could well be an issue.
>
> One workaround might be to add a mutex directly to the Font objects that 
> are being destructed rather than using the global one.  Or, to explicitly 
> clear the ObjectCache on destruction rather than leaving it to static clean 
> up.  The later would be my preferred approach.
>
> A call to:
>
>osgDB::Registry::instance()->getObjectCache()->clear();
>
> In application clean up should be sufficient, or force the destruction of 
> the Registry singleton:
>
>osgDB::Registry::instance(true);   // passing in true forces the 
> destruction, yes a bit hacky... the OSG has a long history so can't recall 
> the circumstances of that addition...
>
> I will hold the 3.6.5 release back till we have some conclusion on this 
> issue, in case we need to make changes to the core OSG.
>
> Cheers,
> Robert.
>
 
Hi Robert,
Thank you for the help.
Manually clearing the registry fixed my crash on exit.
I will continue testing the next rc, so far so good.

Greetings,
Fabian

-- 
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/9062cb33-09fa-496a-8852-c7ffc1e826ac%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Cannot render and load OBJ when using QOpenGLWidget with osgViewer::GraphicsWindowEmbedded on OSG 3.5.6 rc2 and 3.6.4

Maybe you can try to write out the Node to .osgt just after you read it,
and compare the result between the working and non working version.
Also to try: write out the options string; maybe other options have changed
as well?
The change in options suggests that you are somehow running different code,
or have different environment settings (OSG_OPTIMIZER=OFF maybe?).
I know very little about Qt and cannot reproduce your problem, I can do
little more than provide hints for you to search on.
Laurens.

On Thu, Jan 30, 2020 at 5:07 PM OpenSceneGraph Users <
osg-users@lists.openscenegraph.org> wrote:

>
> Hi  laurens,
> I've tried osgDB::Options("noTriStripPolygons")
> and now I can see
>
> VertexCacheVisitor searching all triangles
> but nothing is rendered.
>
> --
> 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/0052c00e-6e19-4f63-b9af-4a116cee872b%40googlegroups.com
> <https://groups.google.com/d/msgid/osg-users/0052c00e-6e19-4f63-b9af-4a116cee872b%40googlegroups.com?utm_medium=email_source=footer>
> .
> ___
> 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] Incrementally adding new imagery to an existing .ive

On Fri, 31 Jan 2020 at 12:21, OpenSceneGraph Users <
osg-users@lists.openscenegraph.org> wrote:

> I'm creating a lunar map.  I started with a small base image.  Great.
> Now I want to extend the base image with surround imagery.
> I can't seem to craft the right Google query to get a result.
> Ideas?  Can it even be done?
> I'm currently using osgdem to create the .ive.
>

You don't give us any real insight into what you are doing.  What do mean
by "Google query"?

The OSG and VPB have nothing to do with Google data.  VPB just works with
local static data.

Could it be osgEarth is the right tool for what you want to do?

Robert.

-- 
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.67962.1580474716.7167.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.67962.1580474716.7167.osg-users-openscenegraph.org%40lists.openscenegraph.org.

[osg-users] Incrementally adding new imagery to an existing .ive

I'm creating a lunar map.  I started with a small base image.  Great.
Now I want to extend the base image with surround imagery.
I can't seem to craft the right Google query to get a result.
Ideas?  Can it even be done?
I'm currently using osgdem to create the .ive.

-- 
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/71e1310b-b8e2-4b18-b49d-7ac071ade4f8%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Create BoundingBoxes dynamically, by creating global Geode and attaching children later

After reading the "short" OSG documentation over at 
http://syntheractive.com/developer/downloads/OSGQSG.pdf , I figured it out 
on my own :)

Things that helped me: (obvious if you know what you are doing...)

   - geodes can't have unlimited children, just use a global group, where 
   you attach a new geode for every bounding box.
   - dont use * pointers, use osg::Ref_ptr<>, and if you use 
   iosg::ref_ptr use X.get() to get the object
   - just remove lighting, or set normals
   - if you want the object to have one color, use BIND_OVERALL
   - no need to update or set anything dirty
   - you don't need a state set / matrix at all (in my case, because all is 
   in global coordinates)

Maybe if someone like me stumbles across this thread, this Info helps

-- 
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/e155d7d2-1cc0-4cd7-92da-a24bf107b73c%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] DefaultFont crash issue

Hi Anna & Glenm,

On Thu, 30 Jan 2020 at 13:00, OpenSceneGraph Users <
osg-users@lists.openscenegraph.org> wrote:

> I too have seen thread-related issues when creating Text from multiple
> threads. I was never able to find the time to debug it to conclusion; but I
> suspect that a shared Font object that needs to create new Glyph textures
> isn't doing so in a thread-safe manner. For example,
> Font::assignGlyphToGlyphTexture() modifies some structures without Mutex
> protection. Just something to check.
>

Thanks for the suggestion.  I've done a code review of the
Glyph/GlyphTexture/Font code and have added a mutex lock to the
Font::assignGlyphToGlyphTexture().  There are already mutex locks
elsewhere, but there may be a need to add more.  The change is checked into
the 3.6 branch and master:

https://github.com/openscenegraph/OpenSceneGraph/commit/2e0472ba7e05e680a9a7e0bc7676d4e5a12eefa5

I have tested by running all the OSG examples and running osgtext --mt, and
don't see any regressions.  I can't confirm that the change has fixed the
crashes that you both have seen as I haven't got any example that
reproduces it.  Could you test the 3.6 branch and let me know how you get
on.

This fix isn't in 3.6.5-rc3. but will be part of the final 3.6.5 stable
release.

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

Re: [osg-users] OpenSceneGraph-3.6.5 relased!

2020-02-01 Thread OpenSceneGraph Users

Hello OSG Community,

OpenSceneGraph 3.6.5 Windows binaries are now up at the Objexx Engineering 
OSG page at:
https://objexx.com/OpenSceneGraph.html

There are debug and release packages built with Visual C++ 2019 which 
should be binary compatible with Visual C++ 2017 or 2019 application builds.

Let me know if any questions or problems arise or if you would like to see 
additional build types and/or plugins added in the future.

Enjoy,
Stuart

-- 
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/36bbb1ac-e338-4269-9186-709a00fc20e8%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] OpenSceneGraph-3.6.5 relased!

git repository
Merge pull request #818 from mp3butcher/patch-31fix comment block CMake 
syntax

Thu, 15 Aug 2019 20:46:52 +0200
Author : Julien Valentin
fix cmake block comment syntax

Thu, 15 Aug 2019 20:27:05 +0200
Author : Julien Valentin
remove unproperly parsed CMake 
commenthttps://github.com/openscenegraph/OpenSceneGraph/issues/812

Wed, 7 Aug 2019 10:56:59 +0100
Author : OpenSceneGraph git repository
Merge pull request #808 from 640kb/OpenSceneGraph-3.6las plugin: fix 
linking against static boost library under windows

Wed, 7 Aug 2019 09:49:16 +0200
Author : Daniel Wendt
las plugin: fix linking against static boost library under 
windowsSigned-off-by: Daniel Wendt


Wed, 31 Jul 2019 14:11:59 +0100
Author : Robert Osfield
Added a _fontFallback to TextBase to cache any fallback font (usually 
DefaultFont) that is used when the Textbase::_font is null.

Mon, 29 Jul 2019 13:01:00 +0100
Author : Robert Osfield
Replaced GL_QUADS usage with GL_TRIANGLE_STRIP

Mon, 29 Jul 2019 12:29:25 +0100
Author : Robert Osfield
Refactored the mesh setup to use GL_TRIANGLE_STIP instead of GL_QUADS

Mon, 29 Jul 2019 09:59:57 +0100
Author : Robert Osfield
Updated version to 3.6.5

Mon, 29 Jul 2019 08:57:56 +0100
Author : OpenSceneGraph git repository
Merge pull request #804 from eligovision/OpenSceneGraph-3.6_GLQUADS[*] 
ParticleSystem: Use GL_TRIANGLES instead if GL_QUADS when GL{1,2}…

Fri, 26 Jul 2019 21:14:45 +0300
Author : Konstantin S. Matveyev
[*] ParticleSystem: Use GL_TRIANGLES instead if GL_QUADS when GL{1,2} or 
GLES1 are unavailable

-- 
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/350c6f52-e6d9-4dac-908f-7b6ea57be5d6%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?

2020-02-02 Thread 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?

2020-02-02 Thread 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] LineSegmentIntersector and MODEL Frame

2020-02-03 Thread OpenSceneGraph Users

Hi Chris,
I guess you want the scene to accept the IntersectionVisitor, not the
camera.
Laurens.

On Sat, Feb 1, 2020 at 1:18 PM OpenSceneGraph Users <
osg-users@lists.openscenegraph.org> wrote:

> I have a scene built with a few objects loaded, the most pertinent one
> being a large plane surface centered at the origin. I want to cast a ray
> from a particular point at a particular angle inside the scene and get a
> list of everything it intersects—both the point of intersection and the
> Node object. Most examples of using intersectors involve picking from the
> window, so I haven't seen exactly what I wanted. But from what I've read,
> the following should at least be close:
>
> Vec3d start( 0.0, 0.0, 100.0 );
> Vec3d end( 0.0, 0.0, -100.0 );
> ref_ptr intsec = new LineSegmentIntersector(
> Intersector::MODEL, start, end );
> IntersectionVisitor iv( intsec.get() );
> viewer.getCamera()->accept( iv );
> cout << intsec->containsIntersections() << endl;
>
> My start and end points in this snippet are well above and well below the
> surface object. So that plane object should definitely be intersected by a
> line running between them. However the containsIntersections function
> always returns false.
>
> Immediately after making this preliminary test pick, the program calls
> viewer.run() so I know everything is arranged as expected in the scene. So
> my guess is that I'm missunderstanding how the visitor works. Perhaps the
> accept() function is not what I should be using to execute the intersector?
>
>  ~ Chris
>
>
>
> --
> 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/58d20034-cb65-4bef-937f-f85a1fa92030%40googlegroups.com
> <https://groups.google.com/d/msgid/osg-users/58d20034-cb65-4bef-937f-f85a1fa92030%40googlegroups.com?utm_medium=email_source=footer>
> .
> ___
> 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] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

Hi Chris et. al,

On Thursday, 30 January 2020 14:39:08 UTC, OpenSceneGraph Users wrote:
>
> I slowly closing in on the cause of the Font issue, currently it looks 
> like the removeView() is behaving differently form the CompositeViewer 
> destructor and not handling clean up of contexts correctly.  I need to 
> refactor how things are done internally, but expect to have a solution 
> checked in this afternoon.
>

I have now checked a fix to the CompositeViewer::removeView() bug where GL 
objects, including the Font, were not being cleaned up correctly.

 
https://github.com/openscenegraph/OpenSceneGraph/commit/25868955d2214139722806d20d2c4b60e32d4a61

Cheers,
Robert.

-- 
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/33fb547f-d61a-4c75-a3ec-e717ee1a6454%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Cannot render and load OBJ when using QOpenGLWidget with osgViewer::GraphicsWindowEmbedded on OSG 3.5.6 rc2 and 3.6.4

I will try, but I doubt it would be of insight, I am not running two 
different code, it's just launching the application using debugger or 
without (that's it), with the debugger application always is able to render 
the obj file, otherwise nothing is rendered.


On Thursday, January 30, 2020 at 5:40:51 PM UTC+1, OpenSceneGraph Users 
wrote:
>
> Maybe you can try to write out the Node to .osgt just after you read it, 
> and compare the result between the working and non working version.
> Also to try: write out the options string; maybe other options have 
> changed as well?
> The change in options suggests that you are somehow running different 
> code, or have different environment settings (OSG_OPTIMIZER=OFF maybe?).
> I know very little about Qt and cannot reproduce your problem, I can do 
> little more than provide hints for you to search on.
> Laurens.
>
> On Thu, Jan 30, 2020 at 5:07 PM OpenSceneGraph Users <
> osg-...@lists.openscenegraph.org > wrote:
>
>>  
>> Hi  laurens,
>> I've tried osgDB::Options("noTriStripPolygons")
>> and now I can see 
>>
>> VertexCacheVisitor searching all triangles
>> but nothing is rendered.
>>
>> -- 
>> 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-...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/osg-users/0052c00e-6e19-4f63-b9af-4a116cee872b%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/osg-users/0052c00e-6e19-4f63-b9af-4a116cee872b%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> ___
>> osg-users mailing list
>> osg-...@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/3fe24e91-ce2e-421e-b417-542cf8df6119%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

Hi Robert,
Compiling and a few simple runs worked fine, using
windows 10 Enterprise 1909 18363,592
Visual Studio 15.9.19
CMake 3.15.5
Regards, Laurens.

On Thu, Jan 30, 2020 at 5:30 PM OpenSceneGraph Users <
osg-users@lists.openscenegraph.org> wrote:

> Hi Chris et. al,
>
> On Thursday, 30 January 2020 14:39:08 UTC, OpenSceneGraph Users wrote:
>>
>> I slowly closing in on the cause of the Font issue, currently it looks
>> like the removeView() is behaving differently form the CompositeViewer
>> destructor and not handling clean up of contexts correctly.  I need to
>> refactor how things are done internally, but expect to have a solution
>> checked in this afternoon.
>>
>
> I have now checked a fix to the CompositeViewer::removeView() bug where GL
> objects, including the Font, were not being cleaned up correctly.
>
>
> https://github.com/openscenegraph/OpenSceneGraph/commit/25868955d2214139722806d20d2c4b60e32d4a61
>
> Cheers,
> Robert.
>
> --
> 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/33fb547f-d61a-4c75-a3ec-e717ee1a6454%40googlegroups.com
> <https://groups.google.com/d/msgid/osg-users/33fb547f-d61a-4c75-a3ec-e717ee1a6454%40googlegroups.com?utm_medium=email_source=footer>
> .
> ___
> 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] OpenScenGraph-3.6.5-rc3 tagged, please test :-)

Hi All,

I have merged a couple of fixes since rc2 so it's time for another release 
candidate:

   
https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGraph-3.6.5-rc3

If there aren't any issues reported by I'll go ahead a tag 3.6.5 tomorrow.

Thanks in advance for testing,
Robert.

-- Changes since 3.6.5-rc2

Thu, 30 Jan 2020 16:30:41 +
Author : OpenSceneGraph git repository
Merge pull request #911 from LaurensVoerman/FbxSdkFixFix for older versions 
of fbxsdk without xml or zlib libraries,

Thu, 30 Jan 2020 16:21:32 +
Author : Robert Osfield
Added explicit clean up removeView

Thu, 30 Jan 2020 16:32:42 +0100
Author : Laurens Voerman
Fix for older versions of fbxsdk without xml or zlib libraries, fix cmake 
multiconfig generators (msvc) with irrelevant CMAKE_BUILD_TYPE.

Mon, 27 Jan 2020 10:11:23 +
Author : OpenSceneGraph git repository
Merge pull request #907 from DeadParrot/OpenSceneGraph-3.6FBX plugin 
updates / PREFIX-NOTFOUND work-around

Sun, 26 Jan 2020 14:28:56 -0500
Author : Stuart Mentzer
FBX plugin updates / PREFIX-NOTFOUND work-around


-- 
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/5ec35d39-2c08-4831-922c-7a95b5ed964f%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] LineSegmentIntersector and MODEL Frame

2020-02-03 Thread OpenSceneGraph Users

I found the problem, and it was mine. It helps if I attach my root node to 
the scene BEFORE I try to insect with it. ;)

On Monday, February 3, 2020 at 1:04:10 PM UTC-5, Nonsanity wrote:
>
> Thanks. I had thought to apply the visitor to the scene, but GetScene() 
> didn't have Accept(). With your confirmation that using the scene was 
> correct, I found that viewer.getSceneData()->accept( iv ) did exist.
>
> However, calling that line just results in a segfault. The rest of the 
> code is the same as before. I'm going to search to see if I'm doing 
> something obviously wrong, but in case I got the above line incorrect, I 
> wanted to post my failed results here for further comment.
>
>
> On Monday, February 3, 2020 at 3:06:33 AM UTC-5, OpenSceneGraph Users 
> wrote:
>>
>> Hi Chris,
>> I guess you want the scene to accept the IntersectionVisitor, not the 
>> camera.
>> Laurens.
>>
>> On Sat, Feb 1, 2020 at 1:18 PM OpenSceneGraph Users <
>> osg-...@lists.openscenegraph.org> wrote:
>>
>>> I have a scene built with a few objects loaded, the most pertinent one 
>>> being a large plane surface centered at the origin. I want to cast a ray 
>>> from a particular point at a particular angle inside the scene and get a 
>>> list of everything it intersects—both the point of intersection and the 
>>> Node object. Most examples of using intersectors involve picking from the 
>>> window, so I haven't seen exactly what I wanted. But from what I've read, 
>>> the following should at least be close:
>>>
>>> Vec3d start( 0.0, 0.0, 100.0 );
>>> Vec3d end( 0.0, 0.0, -100.0 );
>>> ref_ptr intsec = new LineSegmentIntersector( 
>>> Intersector::MODEL, start, end );
>>> IntersectionVisitor iv( intsec.get() );
>>> viewer.getCamera()->accept( iv );
>>> cout << intsec->containsIntersections() << endl;
>>>
>>> My start and end points in this snippet are well above and well below 
>>> the surface object. So that plane object should definitely be intersected 
>>> by a line running between them. However the containsIntersections function 
>>> always returns false.
>>>
>>> Immediately after making this preliminary test pick, the program calls 
>>> viewer.run() so I know everything is arranged as expected in the scene. So 
>>> my guess is that I'm missunderstanding how the visitor works. Perhaps the 
>>> accept() function is not what I should be using to execute the intersector?
>>>
>>>  ~ Chris
>>>
>>>
>>>
>>> -- 
>>> 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-...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/osg-users/58d20034-cb65-4bef-937f-f85a1fa92030%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/osg-users/58d20034-cb65-4bef-937f-f85a1fa92030%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>> ___
>>> osg-users mailing list
>>> osg-...@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/c000c686-2aa4-410f-902d-33e95248450c%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] LineSegmentIntersector and MODEL Frame

2020-02-03 Thread OpenSceneGraph Users

Thanks. I had thought to apply the visitor to the scene, but GetScene() 
didn't have Accept(). With your confirmation that using the scene was 
correct, I found that viewer.getSceneData()->accept( iv ) did exist.

However, calling that line just results in a segfault. The rest of the code 
is the same as before. I'm going to search to see if I'm doing something 
obviously wrong, but in case I got the above line incorrect, I wanted to 
post my failed results here for further comment.


On Monday, February 3, 2020 at 3:06:33 AM UTC-5, OpenSceneGraph Users wrote:
>
> Hi Chris,
> I guess you want the scene to accept the IntersectionVisitor, not the 
> camera.
> Laurens.
>
> On Sat, Feb 1, 2020 at 1:18 PM OpenSceneGraph Users <
> osg-...@lists.openscenegraph.org > wrote:
>
>> I have a scene built with a few objects loaded, the most pertinent one 
>> being a large plane surface centered at the origin. I want to cast a ray 
>> from a particular point at a particular angle inside the scene and get a 
>> list of everything it intersects—both the point of intersection and the 
>> Node object. Most examples of using intersectors involve picking from the 
>> window, so I haven't seen exactly what I wanted. But from what I've read, 
>> the following should at least be close:
>>
>> Vec3d start( 0.0, 0.0, 100.0 );
>> Vec3d end( 0.0, 0.0, -100.0 );
>> ref_ptr intsec = new LineSegmentIntersector( 
>> Intersector::MODEL, start, end );
>> IntersectionVisitor iv( intsec.get() );
>> viewer.getCamera()->accept( iv );
>> cout << intsec->containsIntersections() << endl;
>>
>> My start and end points in this snippet are well above and well below the 
>> surface object. So that plane object should definitely be intersected by a 
>> line running between them. However the containsIntersections function 
>> always returns false.
>>
>> Immediately after making this preliminary test pick, the program calls 
>> viewer.run() so I know everything is arranged as expected in the scene. So 
>> my guess is that I'm missunderstanding how the visitor works. Perhaps the 
>> accept() function is not what I should be using to execute the intersector?
>>
>>  ~ Chris
>>
>>
>>
>> -- 
>> 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-...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/osg-users/58d20034-cb65-4bef-937f-f85a1fa92030%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/osg-users/58d20034-cb65-4bef-937f-f85a1fa92030%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> ___
>> osg-users mailing list
>> osg-...@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/36f90789-908b-452a-b629-19c7bd55d43a%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGraph-3.6.5 relased!

2020-02-02 Thread OpenSceneGraph Users

Thanks Stuart, I'm sure it'll be helpful to lots of users.

On Sun, 2 Feb 2020 at 02:41, OpenSceneGraph Users <
osg-users@lists.openscenegraph.org> wrote:

> Hello OSG Community,
>
> OpenSceneGraph 3.6.5 Windows binaries are now up at the Objexx Engineering
> OSG page at:
> https://objexx.com/OpenSceneGraph.html
>
> There are debug and release packages built with Visual C++ 2019 which
> should be binary compatible with Visual C++ 2017 or 2019 application builds.
>
> Let me know if any questions or problems arise or if you would like to see
> additional build types and/or plugins added in the future.
>
> Enjoy,
> Stuart
>
> --
> 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/36bbb1ac-e338-4269-9186-709a00fc20e8%40googlegroups.com
> <https://groups.google.com/d/msgid/osg-users/36bbb1ac-e338-4269-9186-709a00fc20e8%40googlegroups.com?utm_medium=email_source=footer>
> .
> ___
> 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.67799.1580679680.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.67799.1580679680.7169.osg-users-openscenegraph.org%40lists.openscenegraph.org.

[osg-users] Some issues with osgText / Signed Distance Field rendering

2020-02-07 Thread OpenSceneGraph Users

Hello Robert,

I toyed around with SDF and discovered some problems in the fragment shader
that I managed to solve.

There seems to be a bug in the multisampling/blending code. Affected are
semi-transparent texts. It’s most obvious for glyphs with a big fill area,
like e.g. for the bullet character. In the attached picture, the upper
bullet character was rendered with the original shader and an alpha value
of 0.2. It looks totally wrong. For comparison, the second line was
rendered with an alpha value of 1 and is fine.

In order to find out what’s wrong I rewrote the code applying the basic
blending “trick” – doing linear combinations of colours with premultiplied
alpha only. (Let’s call them colours in pma format, the transform function
being pma[ (r,g,b,a) ] -> (r*a,g*a,b*a,a).) This resolved the issue for me,
semi-transparent characters now render visually correct.

So, what I did, is:

1. Apply pma transformation to the source colours (vertex colour, border
colour)
2. Do the multisampling. Simply calculate the mean of the sampled
colours. Each sampled colour is a linear combination of the source colours,
so too in pma format.
3. Apply inverse pma transformation for to get the resulting fragment
colour (to be blended with default blend mode (GL_SRC_ALPHA,
GL_ONE_MINUS_SRC_ALPHA)).

This algorithm can be simplified. Obviously, the resulting fragment colour
too is just a linear combination of the source colours. So, I changed the
multisampling loop to only sample the coefficients for the source
colours.(It’s applying distributive law.) This in turn made me get rid of
the pma and inverse pma transformations.

And it also helped resolving the second issue that I had with the shader:
Shadow backdrops were not rendered correctly. The problem was caused but
following lines of code:

total_color.rgb /= total_color.a;

total_color.a *= scale;

return total_color;

I think the division could turn out to be 0.0 / 0.0 which may have produced
NaNs or unspecified results.

A minor issue I encountered that prevented the shader to compile on my GLSL
ES 1.0 system.

The function texture2DLod is specified by the GLSL ES 1.0, GLSL 1.1, GLSL
1.2 specifications only for use in vertex shader. It may be available
though. In my case it wasn’t, but the extension texture2DLodEXT was.

So I made an extra check to prefer that extension, if available, for GLSL
ES 1.0 only.

I experienced another issue that I wasn’t able to solve so far.

On my embedded ES 2.0 system, the GL_OES_standard_derivatives extension is
available but the functions dFdx / dFdy just seem to deliver bad results.

I don’t know why. Could it be non-conforming usage? A driver or GPU bug? As
a workaround, I’ve switched to using a simpler shader for that system only,
which doesn’t do multisampling. The result seems still fine.

Please check out my changes. I’ll do a pull request. I hope this is
helpful, SDF is really a cool feature.

The shader could surely further be simplified when adapting it to blend
mode (GL_ONE, GL_ONE_MINUS_SRC_ALPHA), which would be a bit easier to deal
with.

I also wondered if the extensive bounds checking for smoothstep when
sampling the colours/coefficients is still adequate for performance.

Regards,

Hannes

--
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/575dbd7a-cac9-418f-86da-a9f14ff1d9f3%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] RTX Raytracing now past of VulkanSceneGraph master!

2020-02-07 Thread OpenSceneGraph Users

My "other" scene graph is progressively nicely, lots of work on RTX Ray 
Tracing support and Viewer functionality are now merged with master.  Cross 
posting here as I know quite a few folk are curious about Ray Tracing but 
can't access it from OpenGL/OSG.

https://github.com/vsg-dev/VulkanSceneGraph

I explain some details of the work in the vsg-users thread:

https://groups.google.com/forum/#!topic/vsg-users/McE4lom67qM 
<https://groups.google.com/forum/#!topic/vsg-users/McE4lom67qM>

The is also GL->Vulkan integration in the works as part of the osg2vsg 
project, so potentially you'd be able to use the RTX functionality in 
Vulkan/VSG and then use the results in your OpenGL/OSG application.

-- 
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/9430f885-8db2-4ae5-9e7a-936c9066a2b9%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Export GLTF from OSG?

2020-02-07 Thread OpenSceneGraph Users

Has anybody worked on exporting GLTF Animations from OSG?

I'd like to save my dynamic OSG scene to disk, and don't want to save the
static geometry each frame. GLTF lets me export the geometry once, and
animate it each frame thereafter.

Curious if anybody has tried something similar, or if there is existing
code to do this.

-- 
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/CAM8Fz%2Bn2sT%2BrXZn0VhHYC1Zm95%3D60g73H9ebsUdCc74iCP6tNQ%40mail.gmail.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

Hi Fabian & Chris,

I was curious about the clean up of the global getGlobalReferencedMutex()
so I added some debug messages to OpenThreads and to relevant calls in the
OSG to track the creation and clean up of mutexes.  I tried an alternative
means of static initialization of the static getGlobalReferencedMutex() and
got the same behavior for before and after results so I don't think the
version in the 3.6 branch is likley to be be a source of problem, even if
it's not particular clean.  Below is diff of the changes I made.

Robert

$ git diff
diff --git a/src/OpenThreads/pthreads/PThreadMutex.cpp
b/src/OpenThreads/pthreads/PThreadMutex.cpp
index 3a3d1c338..d122fc67c 100644
--- a/src/OpenThreads/pthreads/PThreadMutex.cpp
+++ b/src/OpenThreads/pthreads/PThreadMutex.cpp
@@ -22,6 +22,8 @@
 #include 
 #include "PThreadMutexPrivateData.h"

+#include 
+
 using namespace OpenThreads;

 //
@@ -33,7 +35,7 @@ using namespace OpenThreads;
 Mutex::Mutex(MutexType type):
 _mutexType(type)
 {
-
+printf("Mutex::Mutex(%d) %p\n", type, this);
 pthread_mutexattr_t mutex_attr;
 pthread_mutexattr_init( _attr );

@@ -107,6 +109,8 @@ Mutex::Mutex(MutexType type):
 //
 Mutex::~Mutex() {

+printf("Mutex::~Mutex() %p\n", this);
+
 PThreadMutexPrivateData *pd =
 static_cast(_prvData);

diff --git a/src/osg/Referenced.cpp b/src/osg/Referenced.cpp
index 95b665c57..267bda310 100644
--- a/src/osg/Referenced.cpp
+++ b/src/osg/Referenced.cpp
@@ -79,11 +79,16 @@ struct ResetPointer
 };

 typedef ResetPointer DeleteHandlerPointer;
+
+#if 1
+#include 
+
 typedef ResetPointer GlobalMutexPointer;

 OpenThreads::Mutex* Referenced::getGlobalReferencedMutex()
 {
 static GlobalMutexPointer s_ReferencedGlobalMutext = new
OpenThreads::Mutex;
+printf("Referenced::getGlobalReferencedMutex() %p\n",
(s_ReferencedGlobalMutext.get()));
 return s_ReferencedGlobalMutext.get();
 }

@@ -96,6 +101,17 @@ struct InitGlobalMutexes
 }
 };
 static InitGlobalMutexes s_initGlobalMutexes;
+#else
+
+#include 
+
+static OpenThreads::Mutex s_ReferencedGlobalMutex;
+OpenThreads::Mutex* Referenced::getGlobalReferencedMutex()
+{
+printf("Referenced::getGlobalReferencedMutex() %p\n",
(_ReferencedGlobalMutex));
+return _ReferencedGlobalMutex;
+}
+#endif

 // static std::auto_ptr s_deleteHandler(0);
 static DeleteHandlerPointer s_deleteHandler(0);
diff --git a/src/osg/StateAttribute.cpp b/src/osg/StateAttribute.cpp
index e239fb3aa..c7df40894 100644
--- a/src/osg/StateAttribute.cpp
+++ b/src/osg/StateAttribute.cpp
@@ -39,6 +39,8 @@ void StateAttribute::removeParent(osg::StateSet* object)

 ParentList::iterator pitr =
std::find(_parents.begin(),_parents.end(),object);
 if (pitr!=_parents.end()) _parents.erase(pitr);
+
+printf("StateAttribute::removeParent()\n");
 }
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

Hi Fabian,

Link-time optimisation should be fine - we do it on release builds with no 
problems. It's either something you've changed, or it's the static linking.

We still don't know exactly which version of OpenMW and OSG you've built, 
though. It's pretty obviously not the RC this thread is discussing if 
you're using an existing OpenMW release or something you got from the 
master branch with no local changes, as OpenMW literally won't build 
without unofficial changes yet. Can you get back to us with a specific 
answer?

Cheers,

Chris

On Tuesday, 28 January 2020 23:13:47 UTC, Fabian Roth wrote:
>
>
>
> On Tuesday, January 28, 2020 at 10:11:49 AM UTC+1, OpenSceneGraph Users 
> wrote:
>>
>> Hi Fabian,
>>  
>>
>>> My build is using static osg, static osg-plugins and link time 
>>> optimization.
>>> I created an address sanitizer enabled build.
>>> It exhibits a heap-use-after-free.
>>> I will try to further investigate this week.
>>>
>>> =
>>> ==11872==ERROR: AddressSanitizer: heap-use-after-free on address 
>>> 0x603082c0 at pc 0x55b4b9659551 bp 0x7ffdf8a9c190 sp 0x7ffdf8a9c180
>>> READ of size 8 at 0x603082c0 thread T0
>>> #0 0x55b4b9659550 in 
>>> OpenThreads::ScopedPointerLock::ScopedPointerLock(OpenThreads::Mutex*)
>>>  
>>> ./openmw/extern-git/OpenSceneGraph/include/OpenThreads/ScopedLock:54
>>> #1 0x55b4b9659550 in 
>>> osg::StateAttribute::removeParent(osg::StateSet*) 
>>> ./openmw/extern-git/OpenSceneGraph/src/osg/StateAttribute.cpp:38
>>> #2 0x55b4b965a033 in osg::StateSet::clear() 
>>> ./openmw/extern-git/OpenSceneGraph/src/osg/StateSet.cpp:734
>>>
>>
>> Given the stack trace it kinda looks like the getRefMutex() call in 
>> StateAttribute.cpp is the where things might be going astray (note the 
>> comment I've added below):
>>
>> void StateAttribute::removeParent(osg::StateSet* object)
>> {
>> OpenThreads::ScopedPointerLock 
>> lock(getRefMutex()); // calls the base classes Referenced::getRefMutex() 
>> method that will map to Referenced::getGlobalReferencedMutex
>>
>> ParentList::iterator pitr = 
>> std::find(_parents.begin(),_parents.end(),object);
>> if (pitr!=_parents.end()) _parents.erase(pitr);
>> }
>>
>> The Referenced::getGlobalReferencedMutex() implementation in 
>> Referenced.cpp is:
>>
>> OpenThreads::Mutex* Referenced::getGlobalReferencedMutex()
>> {
>> static GlobalMutexPointer s_ReferencedGlobalMutext = new 
>> OpenThreads::Mutex;
>> return s_ReferencedGlobalMutext.get();
>> }
>>
>> // helper class for forcing the global mutex to be constructed when the 
>> library is loaded.
>> struct InitGlobalMutexes
>> {
>> InitGlobalMutexes()
>> {
>> Referenced::getGlobalReferencedMutex();
>> }
>> };
>> static InitGlobalMutexes s_initGlobalMutexes;
>>
>> Which is all a bit hacky way of trying to get a singleton's 
>> _ReferencedGlobalMutext to construct before any other code calling 
>> getGlobalReferencedMutex() gets called.
>>
>> I don't really know why a pointer is even being used here, it's not how 
>> I'd write the code these days, but off the top of my head don't recall the 
>> derivation and motivations between all this code as it dates back to the 
>> earliest days of the OSG project, so almost two decades :-)
>>
>> What I'd write today would simply be:
>>
>> static OpenThreads::Mutex s_ReferencedGlobalMutex;
>> OpenThreads::Mutex* Referenced::getGlobalReferencedMutex()
>> {
>> return _ReferencedGlobalMutex;
>> }
>>
>> You could try substituting this in.  I will try a build here just to make 
>> sure the above works fine for standard OSG work.  I don't expect this 
>> change to have any affect on your own code, if it does it suggest there is 
>> some issue with order of clean up of statics.
>>
>> Robert.
>>
>
> Hi Robert,
> Using your suggested changes i get a crash on start.
> I forgot to mention i also link OpenThreads statically.
> I am starting to suspect the static linking and optimization surfaces 
> undefined behavior.
>
> Greetings,
> Fabian
>
> ASAN:DEADLYSIGNAL
> =
> ==19668==ERROR: AddressSanitizer: SEGV on unknown address 0x0010 
> (pc 0x5597ebadb5ac bp 0x60c00b80 sp 0x7ffce8efbba0 T0)
> ==19668==The signal is caused by a READ memory access.

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

Hi Chris,
I am using the latest openmw master with the compatibility patch from the 
pull request cherry picked, my build changes and minor other tweaks.
I use the osg rc with a only a cmake version change.
The branches are here:
https://github.com/Eli2/openmw/tree/eli2-openmw-static
https://github.com/Eli2/OpenSceneGraph/tree/eli2-openmw-static

By now i strongly suspect i run into the "Static Initialization Order 
Fiasco", as described here:
https://cryptopp.com/wiki/Static_Initialization_Order_Fiasco

I am currently looking into why my build uses the default font.

Greetings,
Fabian

On Wednesday, January 29, 2020 at 12:34:20 AM UTC+1, Chris Djali / 
AnyOldName3 wrote:
>
> Hi Fabian,
>
> Link-time optimisation should be fine - we do it on release builds with no 
> problems. It's either something you've changed, or it's the static linking.
>
> We still don't know exactly which version of OpenMW and OSG you've built, 
> though. It's pretty obviously not the RC this thread is discussing if 
> you're using an existing OpenMW release or something you got from the 
> master branch with no local changes, as OpenMW literally won't build 
> without unofficial changes yet. Can you get back to us with a specific 
> answer?
>
> Cheers,
>
> Chris
>
> On Tuesday, 28 January 2020 23:13:47 UTC, Fabian Roth wrote:
>>
>>
>>
>> On Tuesday, January 28, 2020 at 10:11:49 AM UTC+1, OpenSceneGraph Users 
>> wrote:
>>>
>>> Hi Fabian,
>>>  
>>>
>>>> My build is using static osg, static osg-plugins and link time 
>>>> optimization.
>>>> I created an address sanitizer enabled build.
>>>> It exhibits a heap-use-after-free.
>>>> I will try to further investigate this week.
>>>>
>>>> =
>>>> ==11872==ERROR: AddressSanitizer: heap-use-after-free on address 
>>>> 0x603082c0 at pc 0x55b4b9659551 bp 0x7ffdf8a9c190 sp 0x7ffdf8a9c180
>>>> READ of size 8 at 0x603082c0 thread T0
>>>> #0 0x55b4b9659550 in 
>>>> OpenThreads::ScopedPointerLock::ScopedPointerLock(OpenThreads::Mutex*)
>>>>  
>>>> ./openmw/extern-git/OpenSceneGraph/include/OpenThreads/ScopedLock:54
>>>> #1 0x55b4b9659550 in 
>>>> osg::StateAttribute::removeParent(osg::StateSet*) 
>>>> ./openmw/extern-git/OpenSceneGraph/src/osg/StateAttribute.cpp:38
>>>> #2 0x55b4b965a033 in osg::StateSet::clear() 
>>>> ./openmw/extern-git/OpenSceneGraph/src/osg/StateSet.cpp:734
>>>>
>>>
>>> Given the stack trace it kinda looks like the getRefMutex() call in 
>>> StateAttribute.cpp is the where things might be going astray (note the 
>>> comment I've added below):
>>>
>>> void StateAttribute::removeParent(osg::StateSet* object)
>>> {
>>> OpenThreads::ScopedPointerLock 
>>> lock(getRefMutex()); // calls the base classes Referenced::getRefMutex() 
>>> method that will map to Referenced::getGlobalReferencedMutex
>>>
>>> ParentList::iterator pitr = 
>>> std::find(_parents.begin(),_parents.end(),object);
>>> if (pitr!=_parents.end()) _parents.erase(pitr);
>>> }
>>>
>>> The Referenced::getGlobalReferencedMutex() implementation in 
>>> Referenced.cpp is:
>>>
>>> OpenThreads::Mutex* Referenced::getGlobalReferencedMutex()
>>> {
>>> static GlobalMutexPointer s_ReferencedGlobalMutext = new 
>>> OpenThreads::Mutex;
>>> return s_ReferencedGlobalMutext.get();
>>> }
>>>
>>> // helper class for forcing the global mutex to be constructed when the 
>>> library is loaded.
>>> struct InitGlobalMutexes
>>> {
>>> InitGlobalMutexes()
>>> {
>>> Referenced::getGlobalReferencedMutex();
>>> }
>>> };
>>> static InitGlobalMutexes s_initGlobalMutexes;
>>>
>>> Which is all a bit hacky way of trying to get a singleton's 
>>> _ReferencedGlobalMutext to construct before any other code calling 
>>> getGlobalReferencedMutex() gets called.
>>>
>>> I don't really know why a pointer is even being used here, it's not how 
>>> I'd write the code these days, but off the top of my head don't recall the 
>>> derivation and motivations between all this code as it dates back to the 
>>> earliest days of the OSG project, so almost two decades :-)
>>>
>>> What I'd write today would simply be:
>>>
>>> static OpenThreads::Mutex s_

Re: [osg-users] Osg Text issues

Hi Dan,

Thanks for all the details.  Seeing a difference between the same scene 
graph in our Qt based viewer vs OSG suggests that the Qt side is changing 
OpenGL state, or setting up the graphics context+frame buffers in a 
different way to the OSG does.

I don't have any Qt expertise so can't help with that side of things, 
perhaps other OSG/Qt users can help, or perhaps the Qt community can 
provide guidance on what OpenGL state it sets.  The OSG can't change OpenGL 
state that it isn't aware of, but if you can tell the OSG about this state 
via the osg::State::haveApplied*() calls:


   /** Mode has been set externally, update state to reflect this 
setting.*/
void haveAppliedMode(StateAttribute::GLMode 
mode,StateAttribute::GLModeValue value);

/** Mode has been set externally, therefore dirty the associated 
mode in osg::State
  * so it is applied on next call to osg::State::apply(..)*/
void haveAppliedMode(StateAttribute::GLMode mode);

/** Attribute has been applied externally, update state to reflect 
this setting.*/
void haveAppliedAttribute(const StateAttribute* attribute);

/** Attribute has been applied externally,
  * and therefore this attribute type has been dirtied
  * and will need to be re-applied on next osg::State.apply(..).
  * note, if you have an osg::StateAttribute which you have applied 
externally
  * then use the have_applied(attribute) method as this will cause 
the osg::State to
  * track the current state more accurately and enable lazy state 
updating such
  * that only changed state will be applied.*/
void haveAppliedAttribute(StateAttribute::Type type, unsigned int 
member=0);

At a guess I'd suggest it's the blending or texture filter that could amiss.

Robert.

-- 
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/5e1fdbad-48f0-4a9e-8df8-42a9330cd3c5%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

Hi Fabian,

On Wednesday, 29 January 2020 00:24:35 UTC, Fabian Roth wrote:
>
> Hi Chris,
> I am using the latest openmw master with the compatibility patch from the 
> pull request cherry picked, my build changes and minor other tweaks.
> I use the osg rc with a only a cmake version change.
> The branches are here:
> https://github.com/Eli2/openmw/tree/eli2-openmw-static
> https://github.com/Eli2/OpenSceneGraph/tree/eli2-openmw-static
>
> By now i strongly suspect i run into the "Static Initialization Order 
> Fiasco", as described here:
> https://cryptopp.com/wiki/Static_Initialization_Order_Fiasco
>
> I am currently looking into why my build uses the default font.
>

The way that the singleton methods are done is an attempt to resolve the 
construction order issue, but l don't recall a focus on the destruction 
side.  It could well be an issue.

One workaround might be to add a mutex directly to the Font objects that 
are being destructed rather than using the global one.  Or, to explicitly 
clear the ObjectCache on destruction rather than leaving it to static clean 
up.  The later would be my preferred approach.

A call to:

   osgDB::Registry::instance()->getObjectCache()->clear();

In application clean up should be sufficient, or force the destruction of 
the Registry singleton:

   osgDB::Registry::instance(true);   // passing in true forces the 
destruction, yes a bit hacky... the OSG has a long history so can't recall 
the circumstances of that addition...

I will hold the 3.6.5 release back till we have some conclusion on this 
issue, in case we need to make changes to the core OSG.

Cheers,
Robert.

-- 
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/dff4e0d7-343b-4893-bdeb-23e60528f42d%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Cannot render and load OBJ when using QOpenGLWidget with osgViewer::GraphicsWindowEmbedded on OSG 3.5.6 rc2 and 3.6.4

2020-02-04 Thread OpenSceneGraph Users

HI,
I've tried to export the scene to osgt file and I found that it writes the 
structure of the node i.e. Geode s Geometries vertexes colors..etc. but the 
with all values set to zero. That's why they're not seen. 


On Thursday, January 30, 2020 at 5:50:37 PM UTC+1, mohamed selim wrote:
>
> I will try, but I doubt it would be of insight, I am not running two 
> different code, it's just launching the application using debugger or 
> without (that's it), with the debugger application always is able to render 
> the obj file, otherwise nothing is rendered.
>
>
> On Thursday, January 30, 2020 at 5:40:51 PM UTC+1, OpenSceneGraph Users 
> wrote:
>>
>> Maybe you can try to write out the Node to .osgt just after you read it, 
>> and compare the result between the working and non working version.
>> Also to try: write out the options string; maybe other options have 
>> changed as well?
>> The change in options suggests that you are somehow running different 
>> code, or have different environment settings (OSG_OPTIMIZER=OFF maybe?).
>> I know very little about Qt and cannot reproduce your problem, I can do 
>> little more than provide hints for you to search on.
>> Laurens.
>>
>> On Thu, Jan 30, 2020 at 5:07 PM OpenSceneGraph Users <
>> osg-...@lists.openscenegraph.org> wrote:
>>
>>>  
>>> Hi  laurens,
>>> I've tried osgDB::Options("noTriStripPolygons")
>>> and now I can see 
>>>
>>> VertexCacheVisitor searching all triangles
>>> but nothing is rendered.
>>>
>>> -- 
>>> 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-...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/osg-users/0052c00e-6e19-4f63-b9af-4a116cee872b%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/osg-users/0052c00e-6e19-4f63-b9af-4a116cee872b%40googlegroups.com?utm_medium=email_source=footer>
>>> .
>>> ___
>>> osg-users mailing list
>>> osg-...@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/a63233f6-202d-46a4-a7bf-5502a52ede72%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Cannot render and load OBJ when using QOpenGLWidget with osgViewer::GraphicsWindowEmbedded on OSG 3.5.6 rc2 and 3.6.4

 
Hi  laurens,
I've tried osgDB::Options("noTriStripPolygons")
and now I can see 

VertexCacheVisitor searching all triangles
but nothing is rendered.

-- 
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/0052c00e-6e19-4f63-b9af-4a116cee872b%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Cannot render and load OBJ when using QOpenGLWidget with osgViewer::GraphicsWindowEmbedded on OSG 3.5.6 rc2 and 3.6.4

When using *QOpenGLWidget *with *osgViewer::GraphicsWindowEmbedded *to 
render and load *OBJ *file nothing is being rendered, I am using latest osg 
3.6.5 rc2 on ubuntu 19.10 with Inel graphics Card hd 620 using Mesa 19.3. 
When I create a passive osgViewer::GraphicsWindowEmbedded along 
QOpenGLWidget to render any geometrical shapes using normal 
osg::ShapeDrawable and osg Geode and it works fine, if I use 
osgDB::readNodeFile instead to load mesh objects using STL formats it works 
fine, but if I opt for OBJ format, it won't render anything I am attaching 
a working example 
<https://drive.google.com/open?id=1Hnc6QpOHf-i9jxXoHW1q7HjaGY2tPDJN>


I am extending a QOpenGLWidget using... class QtOSGWidget : public 
QOpenGLWidget and ovveriding necessary virtual functions and having normal 
passive osg embedded viewer withing QOpenGLWidget. The strange thing this 
workflow works for me without a problem on windows 10, what's more stranger 
if I opt for normal osgViewer::Viewer without the Qt QOpenGLWidget it works 
fine and loads and renders the obj file perfectly.

I've attached debug output of osg using OSG_NOTIFY_LEVEL set to DEBUG. I am 
using Qt 5.14 and I also tried Qt 5.12, 5.9 and 5.7 and I got the same 
result.
Also using Qt Creator 4.11, also I discovered that when I launch the 
application using the debugger right from Qt creator I would be able to 
render it normally, if I launch the application normally without Qt 
creator's debugger nothing is rendered, same result with release and debug 
and also launching application from bash cmd line.

I would like to draw the attention to the fact that the OBJ sounds normal 
tried it with osg 3.6.5 rc2 and 3.6.4 on windows and above scenario works 
fine, no problem with location obj file or anything like that. I believe 
that the problem is coupled only with QOpenGLWidget and 
osgViewer::GraphicsWindowEmbedded to load OBJ file(only) on linux (ubuntu 
19.10, xubunu 18.10).

-- 
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/43a9d8de-b692-4046-bb9f-3645cae0204c%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Cannot render and load OBJ when using QOpenGLWidget with osgViewer::GraphicsWindowEmbedded on OSG 3.5.6 rc2 and 3.6.4

Hi Laurens,
thanks for the reply, I've noticed that also, that mean the Qt creator 
along with is triggering something (OpenGL related maybe) that in turns 
triggers this option switch in both cases.


On Thursday, January 30, 2020 at 3:49:22 PM UTC+1, OpenSceneGraph Users 
wrote:
>
> Hi Mohamed,
> there seems to be a difference in options between "works.txt" and 
> "doesntwork.txt",
> doesntwork seems to run with "noTriStripPolygons" option, NOT generating a 
> message "VertexCacheVisitor searching all triangles"
>
> Laurens.
>
>
>
>
> On Thu, Jan 30, 2020 at 2:59 PM OpenSceneGraph Users <
> osg-...@lists.openscenegraph.org > wrote:
>
>> When using *QOpenGLWidget *with *osgViewer::GraphicsWindowEmbedded *to 
>> render and load *OBJ *file nothing is being rendered, I am using latest 
>> osg 3.6.5 rc2 on ubuntu 19.10 with Inel graphics Card hd 620 using Mesa 
>> 19.3. When I create a passive osgViewer::GraphicsWindowEmbedded along 
>> QOpenGLWidget to render any geometrical shapes using normal 
>> osg::ShapeDrawable and osg Geode and it works fine, if I use 
>> osgDB::readNodeFile instead to load mesh objects using STL formats it works 
>> fine, but if I opt for OBJ format, it won't render anything I am attaching 
>> a working example 
>> <https://drive.google.com/open?id=1Hnc6QpOHf-i9jxXoHW1q7HjaGY2tPDJN>
>>
>>
>> I am extending a QOpenGLWidget using... class QtOSGWidget : public 
>> QOpenGLWidget and ovveriding necessary virtual functions and having normal 
>> passive osg embedded viewer withing QOpenGLWidget. The strange thing this 
>> workflow works for me without a problem on windows 10, what's more stranger 
>> if I opt for normal osgViewer::Viewer without the Qt QOpenGLWidget it works 
>> fine and loads and renders the obj file perfectly.
>>
>> I've attached debug output of osg using OSG_NOTIFY_LEVEL set to DEBUG. I 
>> am using Qt 5.14 and I also tried Qt 5.12, 5.9 and 5.7 and I got the same 
>> result.
>> Also using Qt Creator 4.11, also I discovered that when I launch the 
>> application using the debugger right from Qt creator I would be able to 
>> render it normally, if I launch the application normally without Qt 
>> creator's debugger nothing is rendered, same result with release and debug 
>> and also launching application from bash cmd line.
>>
>> I would like to draw the attention to the fact that the OBJ sounds normal 
>> tried it with osg 3.6.5 rc2 and 3.6.4 on windows and above scenario works 
>> fine, no problem with location obj file or anything like that. I believe 
>> that the problem is coupled only with QOpenGLWidget and 
>> osgViewer::GraphicsWindowEmbedded to load OBJ file(only) on linux (ubuntu 
>> 19.10, xubunu 18.10).
>>
>> -- 
>> 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-...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/osg-users/43a9d8de-b692-4046-bb9f-3645cae0204c%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/osg-users/43a9d8de-b692-4046-bb9f-3645cae0204c%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> ___
>> osg-users mailing list
>> osg-...@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/1dfe5634-e45e-4405-ae24-36d32d77cbfe%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

Hi Chris,

I slowly closing in on the cause of the Font issue, currently it looks like
the removeView() is behaving differently form the CompositeViewer
destructor and not handling clean up of contexts correctly.  I need to
refactor how things are done internally, but expect to have a solution
checked in this afternoon.

This fix might remove the issue with the static initialization by cleaning
up Font GL objects before the viewers are entirely destroyed and prior to
static clean up.

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

> Also, Robert, I'm assuming you don't have a copy of Morrowind to test
> OpenMW with. Right now, Steam, GreenManGaming and Fanatical are all
> offering it for less than £4, but at least one of those sales ends in less
> than twenty hours. If you're not keen, £4 is a reasonable investment for me
> to make to increase cooperation between our projects, but it would help if
> you got back to me quickly.
>

Thanks for the tip.  I am not a gamer these days, way too many other things
competing with my time.  I also have enough dev work that I really don't
want to get sucked into another open source project, there really are too
many projects that use the OSG for me to start providing direct support for
these projects beyond what I can provide through the OSG forum/mailing
list.  Please remember there is one of me vs many OSG users/projects.

Cheers,
Robert.

-- 
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.67741.1580395136.7167.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.67741.1580395136.7167.osg-users-openscenegraph.org%40lists.openscenegraph.org.

Re: [osg-users] Cannot render and load OBJ when using QOpenGLWidget with osgViewer::GraphicsWindowEmbedded on OSG 3.5.6 rc2 and 3.6.4

Hi Mohamed,
there seems to be a difference in options between "works.txt" and
"doesntwork.txt",
doesntwork seems to run with "noTriStripPolygons" option, NOT generating a
message "VertexCacheVisitor searching all triangles"

Laurens.




On Thu, Jan 30, 2020 at 2:59 PM OpenSceneGraph Users <
osg-users@lists.openscenegraph.org> wrote:

> When using *QOpenGLWidget *with *osgViewer::GraphicsWindowEmbedded *to
> render and load *OBJ *file nothing is being rendered, I am using latest
> osg 3.6.5 rc2 on ubuntu 19.10 with Inel graphics Card hd 620 using Mesa
> 19.3. When I create a passive osgViewer::GraphicsWindowEmbedded along
> QOpenGLWidget to render any geometrical shapes using normal
> osg::ShapeDrawable and osg Geode and it works fine, if I use
> osgDB::readNodeFile instead to load mesh objects using STL formats it works
> fine, but if I opt for OBJ format, it won't render anything I am attaching
> a working example
> <https://drive.google.com/open?id=1Hnc6QpOHf-i9jxXoHW1q7HjaGY2tPDJN>
>
>
> I am extending a QOpenGLWidget using... class QtOSGWidget : public
> QOpenGLWidget and ovveriding necessary virtual functions and having normal
> passive osg embedded viewer withing QOpenGLWidget. The strange thing this
> workflow works for me without a problem on windows 10, what's more stranger
> if I opt for normal osgViewer::Viewer without the Qt QOpenGLWidget it works
> fine and loads and renders the obj file perfectly.
>
> I've attached debug output of osg using OSG_NOTIFY_LEVEL set to DEBUG. I
> am using Qt 5.14 and I also tried Qt 5.12, 5.9 and 5.7 and I got the same
> result.
> Also using Qt Creator 4.11, also I discovered that when I launch the
> application using the debugger right from Qt creator I would be able to
> render it normally, if I launch the application normally without Qt
> creator's debugger nothing is rendered, same result with release and debug
> and also launching application from bash cmd line.
>
> I would like to draw the attention to the fact that the OBJ sounds normal
> tried it with osg 3.6.5 rc2 and 3.6.4 on windows and above scenario works
> fine, no problem with location obj file or anything like that. I believe
> that the problem is coupled only with QOpenGLWidget and
> osgViewer::GraphicsWindowEmbedded to load OBJ file(only) on linux (ubuntu
> 19.10, xubunu 18.10).
>
> --
> 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/43a9d8de-b692-4046-bb9f-3645cae0204c%40googlegroups.com
> <https://groups.google.com/d/msgid/osg-users/43a9d8de-b692-4046-bb9f-3645cae0204c%40googlegroups.com?utm_medium=email_source=footer>
> .
> ___
> 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] LineSegmentIntersector and MODEL Frame

2020-02-01 Thread OpenSceneGraph Users

I have a scene built with a few objects loaded, the most pertinent one 
being a large plane surface centered at the origin. I want to cast a ray 
from a particular point at a particular angle inside the scene and get a 
list of everything it intersects—both the point of intersection and the 
Node object. Most examples of using intersectors involve picking from the 
window, so I haven't seen exactly what I wanted. But from what I've read, 
the following should at least be close:

Vec3d start( 0.0, 0.0, 100.0 );
Vec3d end( 0.0, 0.0, -100.0 );
ref_ptr intsec = new LineSegmentIntersector( 
Intersector::MODEL, start, end );
IntersectionVisitor iv( intsec.get() );
viewer.getCamera()->accept( iv );
cout << intsec->containsIntersections() << endl;

My start and end points in this snippet are well above and well below the 
surface object. So that plane object should definitely be intersected by a 
line running between them. However the containsIntersections function 
always returns false.

Immediately after making this preliminary test pick, the program calls 
viewer.run() so I know everything is arranged as expected in the scene. So 
my guess is that I'm missunderstanding how the visitor works. Perhaps the 
accept() function is not what I should be using to execute the intersector?

 ~ Chris



-- 
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/58d20034-cb65-4bef-937f-f85a1fa92030%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Export GLTF from OSG?

Hi Robert,

The animations are reading live data and rendering them - so it's not a 
simple format, but can be represented by gltf well: the mesh models are 
static, but can appear and disappear and can have arbitrary transformations 
applied to them.

My vision is an exporter that exports each unique Geode exactly once, and 
everything else in the scenegraph exported each frame. That would work well 
for a wide range of OSG-based applications, it seems, and GLTF seems 
well-suited for this.

On Monday, February 17, 2020 at 1:01:48 PM UTC-5, Robert Osfield wrote:
>
> Hi Armin?
>
> On Friday, 7 February 2020 19:06:19 UTC, Armin Samii wrote:
>>
>> Has anybody worked on exporting GLTF Animations from OSG?
>>
>> I'd like to save my dynamic OSG scene to disk, and don't want to save the 
>> static geometry each frame. GLTF lets me export the geometry once, and 
>> animate it each frame thereafter.
>>
>> Curious if anybody has tried something similar, or if there is existing 
>> code to do this.
>>
>
> I don't know of any open sourced GLTF importers or exporters for the OSG.
>
> What form do your animations take?
>  
>

-- 
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/f8f1a09c-8725-4135-9ece-ab1ae0627d9c%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] osgQt::GLWidget Scroll Bug

Hi Scott,

I don't know where the issue lies, but most likely it's in the windowing 
integration side rather than the core OSG as it doesn't look like you'll be 
relying on any of the OSG's native windowing/event handling.  There might 
be an issue with osgQt, but I'm not the author of maintainer for it so will 
have to defer to others on this.  Or it could be an issue with osgEarth.

The best I can suggest is that you build the OSG, osgEarth, osgQt and your 
application in debug mode, then step through the code in a debugger to see 
where the control flow passes when the wheelEvent happens.

Cheers,
Robert.

On Thursday, 13 February 2020 07:58:17 UTC, Scott Shaw wrote:
>
> I think I'm running into a bug in OSG.  I've implemented my own versions 
> of mouse events in a sub-classed osgQt::GLWidget so I can redraw the 3D 
> view only when necessary:
>
> void Osg3dViewCM::mousePressEvent(QMouseEvent* event)
> {
> m_mouseDown = true;
>
> if (_cameraManipulator.valid())
> {
> osgQt::GLWidget::mousePressEvent(event);
>
> frame();
> }
> }
>
> void Osg3dViewCM::mouseReleaseEvent(QMouseEvent* event)
> {
> m_mouseDown = false;
>
> if (_cameraManipulator.valid())
> {
> osgQt::GLWidget::mouseReleaseEvent(event);
>
> frame();
> }
>
> emit cameraChanged(_cameraManipulator->getInverseMatrix());
> }
>
> void Osg3dViewCM::mouseMoveEvent(QMouseEvent* event)
> {
> if (_cameraManipulator.valid() && m_mouseDown)
> {
> osgQt::GLWidget::mouseMoveEvent(event);
>
> frame();
> }
> }
>
> void Osg3dViewCM::wheelEvent(QWheelEvent *event)
> {
> if (_cameraManipulator.valid())
> {
> osgQt::GLWidget::wheelEvent(event);
>
> frame();
> }
> }
>
> I'm using a default osgEarth::Util::EarthManipulator and clicking and 
> dragging on the view updates it without an issue rotating or panning 
> properly.  For some reason, when I scroll the wheel, the frame function 
> doesn't update the view.  If I click on the view after scrolling, it gets 
> updated with the zoom operation applied.  Am I missing something?
>
> Thank you,
> Scott
>

-- 
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/a280cec0-b302-44e1-8a4d-b27dedc82164%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Export GLTF from OSG?

Hi Armin?

On Friday, 7 February 2020 19:06:19 UTC, Armin Samii wrote:
>
> Has anybody worked on exporting GLTF Animations from OSG?
>
> I'd like to save my dynamic OSG scene to disk, and don't want to save the 
> static geometry each frame. GLTF lets me export the geometry once, and 
> animate it each frame thereafter.
>
> Curious if anybody has tried something similar, or if there is existing 
> code to do this.
>

I don't know of any open sourced GLTF importers or exporters for the OSG.

What form do your animations take?
 

-- 
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/86deea75-2982-4ef3-96ae-61ad25f15741%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Export GLTF from OSG?

We have a gltf importer/exporter that we use in osgearth based on
tinygltf.   It works really well although we're really only targetting gltf
files produced to support rendering 3d tiles datasets.  So for example we
havent done anything with animation since that's not a big part of
3dtiles.   Give it a look and see if you might be able to use it.


Jason

On Mon, Feb 17, 2020, 2:46 PM OpenSceneGraph Users <
osg-users@lists.openscenegraph.org> wrote:

> Hi Robert,
>
> The animations are reading live data and rendering them - so it's not a
> simple format, but can be represented by gltf well: the mesh models are
> static, but can appear and disappear and can have arbitrary transformations
> applied to them.
>
> My vision is an exporter that exports each unique Geode exactly once, and
> everything else in the scenegraph exported each frame. That would work well
> for a wide range of OSG-based applications, it seems, and GLTF seems
> well-suited for this.
>
> On Monday, February 17, 2020 at 1:01:48 PM UTC-5, Robert Osfield wrote:
>>
>> Hi Armin?
>>
>> On Friday, 7 February 2020 19:06:19 UTC, Armin Samii wrote:
>>>
>>> Has anybody worked on exporting GLTF Animations from OSG?
>>>
>>> I'd like to save my dynamic OSG scene to disk, and don't want to save
>>> the static geometry each frame. GLTF lets me export the geometry once, and
>>> animate it each frame thereafter.
>>>
>>> Curious if anybody has tried something similar, or if there is existing
>>> code to do this.
>>>
>>
>> I don't know of any open sourced GLTF importers or exporters for the OSG.
>>
>> What form do your animations take?
>>
>>
> --
> 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/f8f1a09c-8725-4135-9ece-ab1ae0627d9c%40googlegroups.com
> <https://groups.google.com/d/msgid/osg-users/f8f1a09c-8725-4135-9ece-ab1ae0627d9c%40googlegroups.com?utm_medium=email_source=footer>
> .
> ___
> 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] Export GLTF from OSG?

2020-02-18 Thread OpenSceneGraph Users

We have a gltf importer/exporter that we use in osgearth based on 
tinygltf.   It works really well although we're really only targeting gltf 
files produced to support rendering 3d tiles datasets.  So for example we 
havent done anything with animation since that's not a big part of 
3dtiles.   Give it a look and see if you might be able to use it.

It's in the in development 3.0 version of osgearth here:  
https://github.com/gwaldron/osgearth/tree/3.0/src/osgEarthDrivers/gltf

Jason



On Monday, February 17, 2020 at 1:29:28 PM UTC-5, Armin Samii wrote:
>
> Hi Robert,
>
> The animations are reading live data and rendering them - so it's not a 
> simple format, but can be represented by gltf well: the mesh models are 
> static, but can appear and disappear and can have arbitrary transformations 
> applied to them.
>
> My vision is an exporter that exports each unique Geode exactly once, and 
> everything else in the scenegraph exported each frame. That would work well 
> for a wide range of OSG-based applications, it seems, and GLTF seems 
> well-suited for this.
>
> On Monday, February 17, 2020 at 1:01:48 PM UTC-5, Robert Osfield wrote:
>>
>> Hi Armin?
>>
>> On Friday, 7 February 2020 19:06:19 UTC, Armin Samii wrote:
>>>
>>> Has anybody worked on exporting GLTF Animations from OSG?
>>>
>>> I'd like to save my dynamic OSG scene to disk, and don't want to save 
>>> the static geometry each frame. GLTF lets me export the geometry once, and 
>>> animate it each frame thereafter.
>>>
>>> Curious if anybody has tried something similar, or if there is existing 
>>> code to do this.
>>>
>>
>> I don't know of any open sourced GLTF importers or exporters for the OSG.
>>
>> What form do your animations take?
>>  
>>
>

-- 
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/6348c881-2838-4a01-b744-73366941bd7d%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] osgShadow 3.6.3

2020-02-18 Thread OpenSceneGraph Users

Hi,

We are trying to test the shadows using OSG, We have multiple lights, but
for now we are playing with only one light, a point source light type. We
are some weird effects, the shadows are cut, a mirror scene as shadow
behind the light. See the video.

https://www.youtube.com/watch?v=hyFBX0jGjaw

osg::ref_ptr shadowedScene = new
osgShadow::ShadowedScene;

shadowedScene->getShadowSettings()->setLightNum(1);
shadowedScene->setReceivesShadowTraversalMask(GetShadowNodeMask());
shadowedScene->setCastsShadowTraversalMask(GetShadowNodeMask());

osg::ref_ptr st = new osgShadow::SoftShadowMap;
st->clearShaderList();
st->setAmbientBias(osg::Vec2(0.5,1.0 - 0.5));

shadowedScene->setShadowTechnique(st.get());

view->addChild(shadowedScene);
shadowedScene->addChild(scene);

// Set the Scene Data
mViewer->setSceneData(view);

Any points that you may have, might help us.

Does osgShadow supports multiple lights?

Greetings,
Catalin

-- 
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.70892.1582030546.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.70892.1582030546.7169.osg-users-openscenegraph.org%40lists.openscenegraph.org.

Re: [osg-users] [Performance] Update dynamic vertices in drawable by external incoming data

HI Yuan,

There a number of ways to go about this type of task, which route to take 
will depend on your needs/hardware available.

In principle pass 400-800 points each frame is not a large and should work 
easily at 60fps without any issues.  One most efficient way to do this is 
to create an array which is large enough for the maximum number of points 
you'll need and allocate this at the start, then just fill in the parts of 
the array that you need, and set the DrawArrays to just reference the 
portion you need.  For instance you could allocate an osg::Vec3Array of 
1000 vertices at setup, then never resize it.  Each time you update the 
data you'll need to call array->dirty() to force the VBO to be updated.

Also when doing bechmarking mark sure you are using a release build of the 
OSG and your application as this can make a huge difference.

Cheers,
Robert.

-- 
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/2fbde036-08a2-4866-b352-9666eff515f6%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [Performance] Update dynamic vertices in drawable by external incoming data

Hi Robert,

thank you for your advice about initial setup of a big array. That is a big 
help.

As you said:*"There a number of ways to go about this type of task, 
which route to take will depend on your needs/hardware available."*

My hardware is a window10 PC with intel i7 8550U CPU and intel Graphics 
620.   

Later I will add more objects(e.g bounding box, point cloud maybe) to 
render in my program and I am not aware of how much computation it will 
demand. Could you please point out one link or reference of "a number of 
ways"?  I would really appreciate that.

Regards,
Yuan

Am Mittwoch, 19. Februar 2020 14:34:05 UTC+1 schrieb Robert Osfield:
>
> HI Yuan,
>
> There a number of ways to go about this type of task, which route to take 
> will depend on your needs/hardware available.
>
> In principle pass 400-800 points each frame is not a large and should work 
> easily at 60fps without any issues.  One most efficient way to do this is 
> to create an array which is large enough for the maximum number of points 
> you'll need and allocate this at the start, then just fill in the parts of 
> the array that you need, and set the DrawArrays to just reference the 
> portion you need.  For instance you could allocate an osg::Vec3Array of 
> 1000 vertices at setup, then never resize it.  Each time you update the 
> data you'll need to call array->dirty() to force the VBO to be updated.
>
> Also when doing bechmarking mark sure you are using a release build of the 
> OSG and your application as this can make a huge difference.
>
> Cheers,
> Robert.
>

-- 
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/f6a44fc4-9006-43cf-be9c-3ef823815dff%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] AutoTransform cannot be picked up correctly

Thanks tor the test program. I've got it compile on my Linux system with
just removing the Windows headers you added, why were these added?

I can confirm the problem, I can pick the cessna without the AutoTransform
by zooming in but not the one under the AutoTransform. I haven't yet had a
chance to look into why this happening. I'm really busy with other work
right now so can't look into this right away. If you want to look into it
yourself I'd recommend stepping through how the
osgUtil::IntersectionTraversal is handling the AutoTransform. It'll be a
bit non standard as the AutoTransform is view dependent, which the
IntersectionTraversal isn't view dependent so there is potential for the
two different traversals have differing solutions. In your usage case your
wanting it to behave like IntersectiinTraversal assumes the same matrix
that that was computed for the rendering, however, this isn't the general
case, intersections can potentially can happen for any direction, or any
one of multiple views.

--
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/4ec7ed63-3add-4cce-89f4-dfb7a2c3174c%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] ProgramBinary and shader composition - does it work?

2020-02-20 Thread OpenSceneGraph Users

Hi Glenn,

On Wed, 19 Feb 2020 at 17:56, OpenSceneGraph Users <
osg-users@lists.openscenegraph.org> wrote:

> I was looking in the glProgramBinary support in osg::Program. I don't
> *think* it is integrated with your "pragmatic" define-based shader
> composition system. Specifically there doesn't seem to be a way to
> associate a ProgramBinary with a particular defineString at the
> PerContextProgram level.
>
> Am I right? And if so will you consider a submission to make this work?
>

When writing the #pragma(tic) shader composition functionality I was just
focused on conventional GLSL compiled shaders, I didn't consider
glProgramBinary, so no idea of how it might interact, I don't expect it
would would work though as the main task of shader composition is
compositing the shaders to compile and compiling these at runtime.

Is there a reason why you are trying to the the glProgramBinary path?

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

[osg-users] osgQt aspect ratio issue when inside QMainWindow

2020-02-20 Thread OpenSceneGraph Users

Hi,
I am trying to put an osgQOpenGLWidget inside a QMainWindow. I managed to 
made it quite easily but the resulting image is stretched and I cannot 
change its aspect ratio to made it right (the cow.osg is really stretched).
Can you help me, please? I have been struggling with this few lines of code 
for 5 days now.

I can provide source code as follows...

Thank you so much

#include "mainwindow.h"

MainWindow::MainWindow(QWidget *parent)
: QMainWindow(parent)
{
QSurfaceFormat format = QSurfaceFormat::defaultFormat();
format.setVersion(2, 0);
format.setProfile(QSurfaceFormat::CompatibilityProfile);
format.setRenderableType(QSurfaceFormat::OpenGL);
format.setOption(QSurfaceFormat::DebugContext);
format.setDepthBufferSize(24);
format.setSamples(8);
format.setStencilBufferSize(8);
format.setSwapBehavior(QSurfaceFormat::DoubleBuffer);
QSurfaceFormat::setDefaultFormat(format);

osgWidget = new osgQOpenGLWidget(this);
QObject::connect(osgWidget, ::initialized, this, 
::setupOsgView);

setCentralWidget(osgWidget);
osgWidget->show();
}

void MainWindow::setupOsgView() {

osgWidget->getOsgViewer()->setCameraManipulator(new 
osgGA::TerrainManipulator());
osgWidget->getOsgViewer()->addEventHandler(new 
osgGA::StateSetManipulator(osgWidget->getOsgViewer()->getCamera()->getOrCreateStateSet()));
osgWidget->getOsgViewer()->addEventHandler(new osgViewer::ThreadingHandler);
osgWidget->getOsgViewer()->addEventHandler(new 
osgViewer::WindowSizeHandler);
osgWidget->getOsgViewer()->addEventHandler(new osgViewer::StatsHandler);
osgWidget->getOsgViewer()->addEventHandler(new 
osgViewer::RecordCameraPathHandler);
osgWidget->getOsgViewer()->addEventHandler(new osgViewer::LODScaleHandler);
osgWidget->getOsgViewer()->addEventHandler(new 
osgViewer::ScreenCaptureHandler);

osg::ref_ptr loadedModel = osgDB::readRefNodeFile("cow.osg");
if(!loadedModel) {
std::cout << "No data loaded" << std::endl;
}

osgUtil::Optimizer optimizer;
optimizer.optimize(loadedModel);

osgWidget->getOsgViewer()->setSceneData(loadedModel);
}

MainWindow::~MainWindow()
{

}

-- 
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/af2c229c-e76e-4b27-9a22-06d3ecd5935a%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [Performance] Update dynamic vertices in drawable by external incoming data

2020-02-20 Thread OpenSceneGraph Users

On Wed, 19 Feb 2020 at 14:26, OpenSceneGraph Users <
osg-users@lists.openscenegraph.org> wrote:

> thank you for your advice about initial setup of a big array. That is a
> big help.
>
> As you said:*"There a number of ways to go about this type of task,
> which route to take will depend on your needs/hardware available."*
>
> My hardware is a window10 PC with intel i7 8550U CPU and intel Graphics
> 620.
>
> Later I will add more objects(e.g bounding box, point cloud maybe) to
> render in my program and I am not aware of how much computation it will
> demand. Could you please point out one link or reference of "a number of
> ways"?  I would really appreciate that.
>

The different ways are in my head rather than a reference I can provide
:-)  This type of topic has been discussed in various ways on osg-users
over the years so you might find more info via a search.

If the fixed size array gives you the performance you want then our job is
done.  If not then we had start looking at other ways, or why you aren't
getting the performance you want.

-- 
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.71772.1582207776.7167.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.71772.1582207776.7167.osg-users-openscenegraph.org%40lists.openscenegraph.org.

[osg-users] ProgramBinary and shader composition - does it work?

Hello Robert,

I was looking in the glProgramBinary support in osg::Program. I don't
*think* it is integrated with your "pragmatic" define-based shader
composition system. Specifically there doesn't seem to be a way to
associate a ProgramBinary with a particular defineString at the
PerContextProgram level.

Am I right? And if so will you consider a submission to make this work?

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

Re: [osg-users] Scale model node to specific size

2020-02-11 Thread OpenSceneGraph Users

Thanks Alberto. The answer helped me to resize the model as required.

On Thursday, September 12, 2013 at 8:04:52 PM UTC+8, Alberto Luaces wrote:
>
> "Zev Lix" writes: 
>
> > Hi, I wonder if there is a way of scaling a model to a specific size? 
> > So if i have two models that have different sizes when loaded into 
> > osg, i want to scale these two models so that they have the same 
> > lenght or width. 
> > 
> > Example if i have two models of cars they should both have X length in 
> > my osg application regardless of how big they were when created in 
> > some model program. 
> > 
> > I know i could just create the models in the right size to start 
> > with. but this is a problem when adding models made by other people. 
>
> Hi Zev, you can get the total dimensions with the osg::BoundingBox of 
> the object.  Later you can scale it to the right size placing it under a 
> osg::MatrixTransform node with a scale matrix. 
>
> -- 
> Alberto 
>
> ___ 
> osg-users mailing list 
> osg-...@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/17dff320-6f27-4d59-8b7d-ef3537a1fd35%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] How to scale/rotate/move an asset in OpenSceneGraph

2020-02-11 Thread OpenSceneGraph Users



I am totally new with OpenSceneGraph

I can open and save an OSG asset. I need to do some simple transformations 
on it, like dimension scaling/rotation/translation.

It seems a pretty easy task, anyway I can't find any quick documentation :/

osg::ref_ptr rectangle = 
osgDB::readNodeFile("../../inputs/Rectangle.osg");
// define simple transformation matrix// apply  simple trnasformation matrix

osgDB::writeNodeFile(*rectangle, "../../outputs/saved.osg");

Any hint?

-- 
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/a6df11c6-2805-44e4-af15-62aa8a77dabb%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] How to scale/rotate/move an asset in OpenSceneGraph

2020-02-11 Thread OpenSceneGraph Users

Check out the examples directory.
One example:
https://github.com/openscenegraph/OpenSceneGraph/blob/master/examples/osganimate/osganimate.cpp#L247
1. Create a MatrixTransform
2. Add your rectangle as a child of that transform
3. Save the MatrixTransform node

On Tue, Feb 11, 2020 at 11:29 AM Luca Costantino 
wrote:

> I am totally new with OpenSceneGraph
>
> I can open and save an OSG asset. I need to do some simple transformations
> on it, like dimension scaling/rotation/translation.
>
> It seems a pretty easy task, anyway I can't find any quick documentation :/
>
> osg::ref_ptr rectangle = 
> osgDB::readNodeFile("../../inputs/Rectangle.osg");
> // define simple transformation matrix// apply  simple trnasformation matrix
>
> osgDB::writeNodeFile(*rectangle, "../../outputs/saved.osg");
>
> Any hint?
>
> --
> 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/a6df11c6-2805-44e4-af15-62aa8a77dabb%40googlegroups.com
> <https://groups.google.com/d/msgid/osg-users/a6df11c6-2805-44e4-af15-62aa8a77dabb%40googlegroups.com?utm_medium=email_source=footer>
> .

-- 
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/CAJFSWeRt5250LuWy-2i4yhv3-wOGxEXMkKF%2BQ8RtMrzSM7Z1Sg%40mail.gmail.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] AutoTransform cannot be picked up correctly

2020-02-16 Thread OpenSceneGraph Users

OSG version is 3.6.4

在 2020年2月14日星期五 UTC+8下午4:29:10，OpenSceneGraph Users写道：
>
> Hi, All
> AutoTransform cannot be picked up correctly when it is a child node of 
> LOD. Does anyone have the same problem as me? How did it work out? 
> Thanks
>
>
>  
>

-- 
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/a41ded24-76b9-42f7-8eb4-eb8f70b15103%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] AutoTransform cannot be picked up correctly

2020-02-22 Thread OpenSceneGraph Users

Thanks for your reply. I changed it based on osgPick, and since I only use 
OSG on Windows, I added those headers.

At present, I have no time to find out the problem. I have avoided this 
problem, and I will study it when I have time. Thanks again.

在 2020年2月19日星期三 UTC+8下午10:39:47，Robert Osfield写道：
>
> Thanks tor the test program. I've got it compile on my Linux system with 
> just removing the Windows headers you added, why were these added?
>
> I can confirm the problem, I can pick the cessna without the AutoTransform 
> by zooming in but not the one under the AutoTransform.  I haven't yet had a 
> chance to look into why this happening.  I'm really busy with other work 
> right now so can't look into this right away.   If you want to look into it 
> yourself I'd recommend stepping through how the 
> osgUtil::IntersectionTraversal is handling the AutoTransform.  It'll be a 
> bit non standard as the AutoTransform is view dependent, which the 
> IntersectionTraversal isn't view dependent so there is potential for the 
> two different traversals have differing solutions.  In your usage case your 
> wanting it to behave like IntersectiinTraversal assumes the same matrix 
> that that was computed for the rendering, however, this isn't the general 
> case, intersections can potentially can happen for any direction, or any 
> one of multiple views.
>

-- 
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/0bb33e95-8032-458a-96c7-27e8eb09ff85%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] opengl version and graphics card

2020-02-14 Thread OpenSceneGraph Users

hii...
i am new to opengl and openscenegraph. i am doing mtech in avionics stream.
my mtech project is related to aircraft HUD symbology and Terrain creation 
and terrain rendering.

in my computer the opengl version is 1.1
how can i upgrade this version and is it depends on os or graphics card.

To creat terrain using textures and elevation data, which graphics card is 
sufficient?

please help me...
my system properties are given in below image:

[image: opengl version.JPG]



-- 
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/d32b1b85-b80a-400f-8fb7-d01e9754ecbc%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] opengl version and graphics card

2020-02-15 Thread OpenSceneGraph Users

Hi Nagendra?

On Saturday, 15 February 2020 05:37:53 UTC, Nagendra Babu Yeruva wrote:
>
> hii...
> i am new to opengl and openscenegraph. i am doing mtech in avionics stream.
> my mtech project is related to aircraft HUD symbology and Terrain creation 
> and terrain rendering.
>
> in my computer the opengl version is 1.1
> how can i upgrade this version and is it depends on os or graphics card.
>
> To creat terrain using textures and elevation data, which graphics card is 
> sufficient?
>

Microsoft only provide out of date OpenGL headers because... well they are 
monopoly and get to make it hard for competitors to work well on Windows.  

There are workarounds, and the OSG builds these in so where the modern 
OpenGL features are missing from the headers the OSG defines these 
automatically for you, and also at runtime queries for the modern 
features+extensions, this means you can effectively use all the features of 
the hardware without worrying about the limitations of what Microsoft 
provides.

The properties dialog you provide doesn't mention that actual hardware you 
have so there is no way for me to provide advice on just how capable it 
is.  All modern hardware is capable of running quite advanced OpenGL 
features, included embedded GPUs, some OpenGL drivers provided by the 
hardware manufactures can be a buggy though.  

Mostly I think you should be OK, just try our applications that have the 
features you want and if they work on your hardware you are good to go.  If 
you hardware is a real limit that using a add in card from NVidia or AMD is 
a way to go.  

Cheers,
Robert.

-- 
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/fa7bbf86-c79f-44db-ad5d-9bd3c9330d48%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] AutoTransform cannot be picked up correctly

2020-02-14 Thread OpenSceneGraph Users

Hi, All
AutoTransform cannot be picked up correctly when it is a child node of LOD. 
Does anyone have the same problem as me? How did it work out? 
Thanks/* OpenSceneGraph example, osgpick.
*
*  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.
*/

/* osgpick sample - Mouse picking in a 3d scene,
*/
#include 
#include "../SoEOsgPragma.h"
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 

#include 

#include 

// class to handle events with a pick
class PickHandler : public osgGA::GUIEventHandler {
public:

PickHandler(osgText::Text* updateText):
_updateText(updateText) {}

~PickHandler() {}

bool handle(const osgGA::GUIEventAdapter& ea,osgGA::GUIActionAdapter& aa);

virtual void pick(osgViewer::View* view, const osgGA::GUIEventAdapter& ea);

void setLabel(const std::string& name)
{
if (_updateText.get()) _updateText->setText(name);
}

protected:

osg::ref_ptr  _updateText;
};

bool PickHandler::handle(const osgGA::GUIEventAdapter& 
ea,osgGA::GUIActionAdapter& aa)
{
switch(ea.getEventType())
{
case(osgGA::GUIEventAdapter::PUSH):
{
osgViewer::View* view = dynamic_cast();
if (view) pick(view,ea);
return false;
}
case(osgGA::GUIEventAdapter::KEYDOWN):
{
if (ea.getKey()=='c')
{
osgViewer::View* view = dynamic_cast();
osg::ref_ptr event = new 
osgGA::GUIEventAdapter(ea);
event->setX((ea.getXmin()+ea.getXmax())*0.5);
event->setY((ea.getYmin()+ea.getYmax())*0.5);
if (view) pick(view,*event);
}
return false;
}
default:
return false;
}
}

void PickHandler::pick(osgViewer::View* view, const osgGA::GUIEventAdapter& ea)
{
osgUtil::LineSegmentIntersector::Intersections intersections;

std::string gdlist="";

if (view->computeIntersections(ea,intersections))
{
for(osgUtil::LineSegmentIntersector::Intersections::iterator hitr = 
intersections.begin();
hitr != intersections.end();
++hitr)
{
std::ostringstream os;
if (!hitr->nodePath.empty() && 
!(hitr->nodePath.back()->getName().empty()))
{
// the geodes are identified by name.
os<<"Object 
\""getName()<<"\""className()<<"\""setMode(GL_LIGHTING,osg::StateAttribute::OFF);
stateset->setMode(GL_DEPTH_TEST,osg::StateAttribute::OFF);
geode->setName("simple");
hudCamera->addChild(geode);

osgText::Text* text = new  osgText::Text;
geode->addDrawable( text );

text->setFont(timesFont);
text->setText("Picking in Head Up Displays is simple!");
text->setPosition(position);

position += delta;
}


for (int i=0; i<5; i++) {
osg::Vec3 dy(0.0f,-30.0f,0.0f);
osg::Vec3 dx(120.0f,0.0f,0.0f);
osg::Geode* geode = new osg::Geode();
osg::StateSet* stateset = geode->getOrCreateStateSet();
const char *opts[]={"One", "Two", "Three", "January", "Feb", "2003"};
osg::Geometry *quad=new osg::Geometry;
stateset->setMode(GL_LIGHTING,osg::StateAttribute::OFF);
stateset->setMode(GL_DEPTH_TEST,osg::StateAttribute::OFF);
std::string name="subOption";
name += " ";
name += std::string(opts[i]);
geode->setName(name);
osg::Vec3Array* vertices = new osg::Vec3Array(4); // 1 quad
osg::Vec4Array*

Re: [osg-users] OSG 3.0.1 Windows Binaries