Re: [osg-users] osgText: problem with SCREEN_COORDS mode

2018-05-21 Thread Robert Osfield
Thanks Glenn, PR merged with master and the 3.6 branch.

On 21 May 2018 at 18:28, Glenn Waldron  wrote:
> Robert,
> Thanks for looking into this. Your update works well.
>
> I have one additional request: the computing of the origin, left, and up
> vectors (lines 517-519) need to be done in double-precision. In my graticule
> example, the text jitters as you manipulate the scene; changing those lines
> to use osg::Vec3d resolves the issue. I have submitted a PR.
>
> Glenn Waldron / osgEarth
>
>
> On Sun, May 20, 2018 at 8:34 AM Robert Osfield 
> wrote:
>>
>> Hi Glenn,
>>
>> I have tried various ways to try and make the scale of the text
>> consistent when using CharacterSizeMode is SCREEN_COORDS whle
>> AxisAlignment is not SCREEN but in the end found the only solution
>> that produces consistent results was to apply the same maths as was
>> being use for the auto rotate case, except the auto-rotation itself is
>> ignored when generating the final matrix.
>>
>> What I have checked in is:
>>
>> https://github.com/openscenegraph/OpenSceneGraph/commit/55c0afbe3ad2c6587f8c329a7dcc61284d8d18b9
>>
>> This is also checked into OSG master.
>>
>> To help test the various possibilities out I amend you test example to
>> have --xy, --xz, --screen etc. command line options for setting how to
>> set the axis alignment of the text.  This amended version is attached.
>> With the above fix everything looks to be working fine, at least for
>> the case of this test, the tests that other users have posted and
>> osgtext.  Fingers crossed this means that osgText is now working
>> solidly for 3.6.1.
>>
>> 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
>
___
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.1 release candidate 5 is tagged

2018-05-21 Thread Daniel Emminizer, Code 5773
Hi Robert,

Looks good on my side.  I ran it through all of my applications and I do not 
spy any regressions from this change.  Phew!

Thanks for the support.  I'm actually getting pretty excited about the Text now 
with our update to OSG 3.6.


If it's helpful -- I am also seeing the problem with precision that Glenn 
reported a few minutes ago with PR #548.  I can also vouch that his PR fixes 
the problem, and does not introduce any other issues in my applications.

 - Dan


> -Original Message-
> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> Behalf Of Robert Osfield
> Sent: Monday, May 21, 2018 1:16 PM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] OpenSceneGraph-3.6.1 release candidate 5 is tagged
> 
> Hi Dan,
> 
> I have checked in a fix to the OpenSceneGraph-3.6 branch:
> 
> 
> https://github.com/openscenegraph/OpenSceneGraph/commit/eae5f9b958
> 59e0dd4f6c580bfc9b6f5efc623aed
> 
> Fingers crossed this doesn't introduce any new regressions...
> 
> Robert.

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


Re: [osg-users] osgText: problem with SCREEN_COORDS mode

2018-05-21 Thread Glenn Waldron
Robert,
Thanks for looking into this. Your update works well.

I have one additional request: the computing of the origin, left, and up
vectors (lines 517-519) need to be done in double-precision. In my
graticule example, the text jitters as you manipulate the scene; changing
those lines to use osg::Vec3d resolves the issue. I have submitted a PR.

Glenn Waldron / osgEarth


On Sun, May 20, 2018 at 8:34 AM Robert Osfield 
wrote:

> Hi Glenn,
>
> I have tried various ways to try and make the scale of the text
> consistent when using CharacterSizeMode is SCREEN_COORDS whle
> AxisAlignment is not SCREEN but in the end found the only solution
> that produces consistent results was to apply the same maths as was
> being use for the auto rotate case, except the auto-rotation itself is
> ignored when generating the final matrix.
>
> What I have checked in is:
>
> https://github.com/openscenegraph/OpenSceneGraph/commit/55c0afbe3ad2c6587f8c329a7dcc61284d8d18b9
>
> This is also checked into OSG master.
>
> To help test the various possibilities out I amend you test example to
> have --xy, --xz, --screen etc. command line options for setting how to
> set the axis alignment of the text.  This amended version is attached.
> With the above fix everything looks to be working fine, at least for
> the case of this test, the tests that other users have posted and
> osgtext.  Fingers crossed this means that osgText is now working
> solidly for 3.6.1.
>
> 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] OpenSceneGraph-3.6.1 release candidate 5 is tagged

2018-05-21 Thread Robert Osfield
Hi Dan,

I have checked in a fix to the OpenSceneGraph-3.6 branch:

   
https://github.com/openscenegraph/OpenSceneGraph/commit/eae5f9b95859e0dd4f6c580bfc9b6f5efc623aed

Fingers crossed this doesn't introduce any new regressions...

Robert.

On 21 May 2018 at 16:40, Daniel Emminizer, Code 5773
 wrote:
> Hi Robert,
>
> Attached is an example based off the osgtext example, along with a screenshot 
> of what I see when I run it.  Making the window taller will "fix" the scaling.
>
> This is very similar to one of the issues reported a few weeks back; except 
> this is only affecting rotated text.  I've found that this problem seems to 
> occur most when a projection matrix is set to ortho2d, and the aspect ratio 
> of the projection matrix does not match the viewport's aspect ratio.  My 
> ortho matrix is set from 0,0 to 1,1 in this application, so it's always 1:1 
> aspect ratio.  Viewport aspect ratio varies as user resizes the window; the 
> example starts at 800x300 (8:3).
>
> The screenshot is against OpenSceneGraph-3.6, most recent push.
>
>  - Dan
>
>
>> -Original Message-
>> From: Daniel Emminizer, Code 5773
>> Sent: Monday, May 21, 2018 11:09 AM
>> To: OpenSceneGraph Users
>> Subject: RE: [osg-users] OpenSceneGraph-3.6.1 release candidate 5 is tagged
>>
>> Hi Robert,
>>
>> I'm using the latest OpenSceneGraph-3.6 with the scaling changes that just
>> got pushed out.
>>
>> I'm getting a bad scaling on a label that is rotated that used to work in OSG
>> 3.4, and used to work prior to
>> https://github.com/openscenegraph/OpenSceneGraph/commit/76d1b85
>>
>> Note that 76d1b85 DOES help with the osgEarth bug -- we're also using
>> osgEarth and that makes the earth graticules a lot better.  But it's breaking
>> this rotated text case.
>>
>> Attached is a screenshot of the display on current OpenSceneGraph-3.6
>> (BadScaleRotated.png).  I backed out 76d1b85 and re-ran and got
>> BackedOut76d1b85.png, which looks correct.
>>
>> I'm working on a minimal reproducible example now.  Once I get it I will
>> respond to this email with a .cpp file.  Thanks,
>>
>>  - Dan
>>
>>
>>
>> > -Original Message-
>> > From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
>> > Behalf Of Robert Osfield
>> > Sent: Sunday, May 20, 2018 8:48 AM
>> > To: OpenSceneGraph Users
>> > Subject: [osg-users] OpenSceneGraph-3.6.1 release candidate 5 is
>> > tagged
>> >
>> > Hi All,
>> >
>> > I have fixed an issue with text SCREEN_COORDS scaling so this means
>> > all the issues I'm aware of are now resolved.  To wrap this up I've
>> > tagged 3.6.1-rc5.
>> >
>> >
>> >
>> https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGr
>> > aph-3.6.1-rc5
>> >
>> > As before please test build or the platforms you have available and
>> > against your own applications. If you have success or issues please
>> > report them here so we get a feel of whether things have converged now
>> > and we are ready of tagging 3.6.1 itself.
>> >
>> > 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] Draw two translucent geometries in specific order

2018-05-21 Thread Robert Osfield
Hi Kristofer,

StateSet::serRenderingHint pre-dates StateSet::setRenderBinDetails()
and was kept for backwards compatibility and ease of use, as you say
it overrides previous calls to RenderBinDetails as it actually calls
RenderBinDetails itself.

Robert.

On 21 May 2018 at 16:29, Kristofer Krus  wrote:
> Hi Robert,
>
> Thanks for your reply.
>
> The problem was that setRenderingHint(osg::StateSet::TRANSPARENT_BIN) was 
> called after I called setRenderBinDetails. While I checked that 
> setRenderBinDetails was not called anywhere else in the code, I didn't know 
> that you could also choose render bin through the setRenderingHint method. 
> Removing the calls to setRenderingHint resolved the problem.
>
> Cheers,
> Kristofer
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=73698#73698
>
>
>
>
>
> ___
> 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.1 release candidate 5 is tagged

2018-05-21 Thread Daniel Emminizer, Code 5773
Hi Robert,

Attached is an example based off the osgtext example, along with a screenshot 
of what I see when I run it.  Making the window taller will "fix" the scaling.

This is very similar to one of the issues reported a few weeks back; except 
this is only affecting rotated text.  I've found that this problem seems to 
occur most when a projection matrix is set to ortho2d, and the aspect ratio of 
the projection matrix does not match the viewport's aspect ratio.  My ortho 
matrix is set from 0,0 to 1,1 in this application, so it's always 1:1 aspect 
ratio.  Viewport aspect ratio varies as user resizes the window; the example 
starts at 800x300 (8:3).

The screenshot is against OpenSceneGraph-3.6, most recent push.

 - Dan


> -Original Message-
> From: Daniel Emminizer, Code 5773
> Sent: Monday, May 21, 2018 11:09 AM
> To: OpenSceneGraph Users
> Subject: RE: [osg-users] OpenSceneGraph-3.6.1 release candidate 5 is tagged
> 
> Hi Robert,
> 
> I'm using the latest OpenSceneGraph-3.6 with the scaling changes that just
> got pushed out.
> 
> I'm getting a bad scaling on a label that is rotated that used to work in OSG
> 3.4, and used to work prior to
> https://github.com/openscenegraph/OpenSceneGraph/commit/76d1b85
> 
> Note that 76d1b85 DOES help with the osgEarth bug -- we're also using
> osgEarth and that makes the earth graticules a lot better.  But it's breaking
> this rotated text case.
> 
> Attached is a screenshot of the display on current OpenSceneGraph-3.6
> (BadScaleRotated.png).  I backed out 76d1b85 and re-ran and got
> BackedOut76d1b85.png, which looks correct.
> 
> I'm working on a minimal reproducible example now.  Once I get it I will
> respond to this email with a .cpp file.  Thanks,
> 
>  - Dan
> 
> 
> 
> > -Original Message-
> > From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> > Behalf Of Robert Osfield
> > Sent: Sunday, May 20, 2018 8:48 AM
> > To: OpenSceneGraph Users
> > Subject: [osg-users] OpenSceneGraph-3.6.1 release candidate 5 is
> > tagged
> >
> > Hi All,
> >
> > I have fixed an issue with text SCREEN_COORDS scaling so this means
> > all the issues I'm aware of are now resolved.  To wrap this up I've
> > tagged 3.6.1-rc5.
> >
> >
> >
> https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGr
> > aph-3.6.1-rc5
> >
> > As before please test build or the platforms you have available and
> > against your own applications. If you have success or issues please
> > report them here so we get a feel of whether things have converged now
> > and we are ready of tagging 3.6.1 itself.
> >
> > Cheers,
> > Robert.
> >

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

#include 
#include 
#include 

#include 
#include 

#include 
#include 

osg::Group* createHUDText()
{
osg::Group* rootNode = new osg::Group;

osg::ref_ptr font = 
osgText::readRefFontFile("fonts/arial.ttf");
osg::Geode* geode  = new osg::Geode;
rootNode->addChild(geode);

osg::Vec4 layoutColor(1.0f,1.0f,0.0f,1.0f);
float layoutCharacterSize = 24.0f;

{
osgText::Text* text = new osgText::Text;
text->setFont(font);
text->setColor(layoutColor);
text->setCharacterSize(layoutCharacterSize);
text->setCharacterSizeMode(osgText::TextBase::SCREEN_COORDS);
text->setAxisAlignment(osgText::TextBase::SCREEN);
text->setPosition(osg::Vec3(0.125,0.1,0.0f));

text->setText("Horizontal Text");
geode->addDrawable(text);
}

{
osgText::Text* text = new osgText::Text;
text->setFont(font);
text->setColor(layoutColor);
text->setCharacterSize(layoutCharacterSize);
text->setCharacterSizeMode(osgText::TextBase::SCREEN_COORDS);
text->setAxisAlignment(osgText::TextBase::SCREEN);
text->setPosition(osg::Vec3(0.1, 0.1, 0.0f));
text->setRotation(osg::Quat(osg::PI_2, osg::Vec3(0, 0, 1)));

text->setText("Vertical Text");
geode->addDrawable(text);
}

return rootNode;
}


int main(int argc, char** argv)
{

Re: [osg-users] Draw two translucent geometries in specific order

2018-05-21 Thread Kristofer Krus
Hi Robert,

Thanks for your reply.

The problem was that setRenderingHint(osg::StateSet::TRANSPARENT_BIN) was 
called after I called setRenderBinDetails. While I checked that 
setRenderBinDetails was not called anywhere else in the code, I didn't know 
that you could also choose render bin through the setRenderingHint method. 
Removing the calls to setRenderingHint resolved the problem.

Cheers,
Kristofer

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





___
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.1 release candidate 5 is tagged

2018-05-21 Thread Daniel Emminizer, Code 5773
Hi Robert,

I'm using the latest OpenSceneGraph-3.6 with the scaling changes that just got 
pushed out.

I'm getting a bad scaling on a label that is rotated that used to work in OSG 
3.4, and used to work prior to 
https://github.com/openscenegraph/OpenSceneGraph/commit/76d1b85

Note that 76d1b85 DOES help with the osgEarth bug -- we're also using osgEarth 
and that makes the earth graticules a lot better.  But it's breaking this 
rotated text case.

Attached is a screenshot of the display on current OpenSceneGraph-3.6 
(BadScaleRotated.png).  I backed out 76d1b85 and re-ran and got 
BackedOut76d1b85.png, which looks correct.

I'm working on a minimal reproducible example now.  Once I get it I will 
respond to this email with a .cpp file.  Thanks,

 - Dan



> -Original Message-
> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> Behalf Of Robert Osfield
> Sent: Sunday, May 20, 2018 8:48 AM
> To: OpenSceneGraph Users
> Subject: [osg-users] OpenSceneGraph-3.6.1 release candidate 5 is tagged
> 
> Hi All,
> 
> I have fixed an issue with text SCREEN_COORDS scaling so this means
> all the issues I'm aware of are now resolved.  To wrap this up I've
> tagged 3.6.1-rc5.
> 
> 
> https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGr
> aph-3.6.1-rc5
> 
> As before please test build or the platforms you have available and
> against your own applications. If you have success or issues please
> report them here so we get a feel of whether things have converged now
> and we are ready of tagging 3.6.1 itself.
> 
> Cheers,
> Robert.
> 

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


[osg-users] Shader Program stops working after Changing Viewer GraphcsContext or Viewer

2018-05-21 Thread Eran Cohen
Hi,

I implemented a 'PausableViewer', to enable dynamically 'hiding' and 'showing' 
the window. I did it in the following way:
On pause, I set done to true, create a new GraphicsContext with the same traits 
of the previous GraphicsContext, stop the viewer threading and switch them - 

Code:
pause()
{
auto traits = new 
GraphicsContext::Traits(*getCamera()->getGraphicsContext()->getTraits());
auto gc = GraphicsContext::create(traits);

stopThreading();
getCamera()->setGraphicsContext(gc);
setDone(true);
}



On resume, I resume the threading and set done to false - 

Code:
resume()
{
setDone(false);
startThreading();
}




This works well, but when using with osgEarth's SkyNode as the scene data of 
the viewer, after the second context switch and onward, I get these errors in a 
loop:

glValidateProgram  FAILED  ""  id=4  contextID=0
glValidateProgram  FAILED  "SimpleSky Atmosphere"  id=7  contextID=0
Warning: detected OpenGL error 'invalid operation' at RenderBin::draw(..)


I can also recreate the error using a regular Viewer, by closing a Viewer but 
saving the scene data and giving it to a new Viewer:


Code:
ref_ptr root = new Group;
auto mapNode = new MapNode;
auto skyNode = SkyNode::create(mapNode);

skyNode->addChild(mapNode);
root->addChild(skyNode);

while (true)
{
Viewer viewer;
viewer.setCameraManipulator(new EarthManipulator);
viewer.setSceneData(root);
viewer.run();
}



I know that this problem might stem from the osgEarth side of things, and I've 
asked there, but I'm wondering if anyone might have a clue to why this happens.

Cheers,
Eran

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





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


Re: [osg-users] Please test OpenSceneGraph-3.6

2018-05-21 Thread Robert Osfield
On 21 May 2018 at 13:23, Daniel Emminizer, Code 5773
 wrote:
> Hi Robert,
>
> Looks good from my end for compiling on MSVC 2015.  Compiles and links 
> without problem, same with osgQt.

That's a relief.  Thanks for the testing.

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


Re: [osg-users] Please test OpenSceneGraph-3.6

2018-05-21 Thread Daniel Emminizer, Code 5773
Hi Robert,

Looks good from my end for compiling on MSVC 2015.  Compiles and links without 
problem, same with osgQt.

 - Dan


> -Original Message-
> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> Behalf Of Robert Osfield
> Sent: Monday, May 21, 2018 8:15 AM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] Please test OpenSceneGraph-3.6
> 
> Hi Dan,
> 
> On 21 May 2018 at 12:42, Daniel Emminizer, Code 5773
>  wrote:
> > Seems like a reasonable approach.  I'll rebuild on my side when you think
> you have something good.
> 
> I have checked in locally expanded version of the macro for
> GraphicsWindowWin32.cpp, and restored the macro to it's original
> location in the include/osg/GraphicsContext header:
> 
> 
> https://github.com/openscenegraph/OpenSceneGraph/commit/dce6684c59
> 698664771669ab7e21fbe4e26e5f42
> 
> I haven't tested under Windows thought so feedback would be very
> welcome.
> 
> 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] Please test OpenSceneGraph-3.6

2018-05-21 Thread Robert Osfield
Hi Dan,

On 21 May 2018 at 12:42, Daniel Emminizer, Code 5773
 wrote:
> Seems like a reasonable approach.  I'll rebuild on my side when you think you 
> have something good.

I have checked in locally expanded version of the macro for
GraphicsWindowWin32.cpp, and restored the macro to it's original
location in the include/osg/GraphicsContext header:


https://github.com/openscenegraph/OpenSceneGraph/commit/dce6684c59698664771669ab7e21fbe4e26e5f42

I haven't tested under Windows thought so feedback would be very welcome.

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


Re: [osg-users] Please test OpenSceneGraph-3.6

2018-05-21 Thread Daniel Emminizer, Code 5773
Hi Robert,

Seems like a reasonable approach.  I'll rebuild on my side when you think you 
have something good.

 - Dan



> -Original Message-
> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> Behalf Of Robert Osfield
> Sent: Monday, May 21, 2018 7:27 AM
> To: OpenSceneGraph Users
> Subject: Re: [osg-users] Please test OpenSceneGraph-3.6
> 
> Hi Dan,
> 
> 
> Two steps forward, one step back
> 
> For compatibility between various versions of the OSG and osgQt I am
> inclined to change the REGISTER_WINDOWINGSYSTEMINTERFACE
> implementation back to what it was and either introduce a new macro
> that adds the OSGVIEWER_EXPORT or  just have the
> GraphicsWindowWin32.cpp not use the this help marco at all, and just
> have it declare the extern and proxy objects directly in the code.
> 
> 
> Robert.
> 
> 
> On 21 May 2018 at 11:48, Daniel Emminizer, Code 5773
>  wrote:
> > Hi Robert,
> >
> > Getting a Windows build error on osgQt from the change on
> REGISTER_WINDOWINGSYSTEMINTERFACE() macro from last week.  Are you
> the right person to report the problem to?
> >
> > osgQt's GraphicsWindowQt.cpp includes the line:
> >
> >   #if 1
> >   REGISTER_WINDOWINGSYSTEMINTERFACE(Qt, QtWindowingSystem)
> >   ...
> >
> > With the change to the macro, it expands to:
> >   extern "C" OSGVIEWER_EXPORT void graphicswindow_qt(void) {} 
> >
> > where OSGVIEWER_EXPORT is defined as "__declspec(dllimport)"
> (because we're now in osgQt and not osgViewer)
> >
> >
> > One possible fix is to add a parameter to
> REGISTER_WINDOWINGSYSTEMINTERFACE to specify the export flavor, such
> as:
> >
> >   #define REGISTER_WINDOWINGSYSTEMINTERFACE(export_type, ext,
> classname) \
> > extern "C export_type void ...
> >
> >   REGISTER_WINDOWINGSYSTEMINTERFACE(OSGQT_EXPORT, Qt,
> QtWindowingSystem)
> >
> > Of course the down-side is that it would change the interface to the macro;
> but that seems better than the alternative of breaking on Windows.  I'm
> happy to test if you need.
> >
> >  - Dan
> >
> >
> >> -Original Message-
> >> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org]
> On
> >> Behalf Of Robert Osfield
> >> Sent: Friday, May 18, 2018 10:49 AM
> >> To: OpenSceneGraph Users
> >> Subject: [osg-users] Please test OpenSceneGraph-3.6
> >>
> >> Hi All,
> >>
> >> I have checked in a few fixes today, one of them I'm not confident
> >> that it'll work across all platforms so I won't make 3.6.1-rc5 today,
> >> instead I'll wait for feedback from the community.
> >>
> >> As usual please let us know via this thread about success or failures.
> >>
> >> Thanks for the testing,
> >> Robert.
> >>
> >
> > ___
> > osg-users mailing list
> > osg-users@lists.openscenegraph.org
> > http://lists.openscenegraph.org/listinfo.cgi/osg-users-
> openscenegraph.org
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


Re: [osg-users] Please test OpenSceneGraph-3.6

2018-05-21 Thread Robert Osfield
Hi Dan,


Two steps forward, one step back

For compatibility between various versions of the OSG and osgQt I am
inclined to change the REGISTER_WINDOWINGSYSTEMINTERFACE
implementation back to what it was and either introduce a new macro
that adds the OSGVIEWER_EXPORT or  just have the
GraphicsWindowWin32.cpp not use the this help marco at all, and just
have it declare the extern and proxy objects directly in the code.


Robert.


On 21 May 2018 at 11:48, Daniel Emminizer, Code 5773
 wrote:
> Hi Robert,
>
> Getting a Windows build error on osgQt from the change on 
> REGISTER_WINDOWINGSYSTEMINTERFACE() macro from last week.  Are you the right 
> person to report the problem to?
>
> osgQt's GraphicsWindowQt.cpp includes the line:
>
>   #if 1
>   REGISTER_WINDOWINGSYSTEMINTERFACE(Qt, QtWindowingSystem)
>   ...
>
> With the change to the macro, it expands to:
>   extern "C" OSGVIEWER_EXPORT void graphicswindow_qt(void) {} 
>
> where OSGVIEWER_EXPORT is defined as "__declspec(dllimport)" (because we're 
> now in osgQt and not osgViewer)
>
>
> One possible fix is to add a parameter to REGISTER_WINDOWINGSYSTEMINTERFACE 
> to specify the export flavor, such as:
>
>   #define REGISTER_WINDOWINGSYSTEMINTERFACE(export_type, ext, classname) \
> extern "C export_type void ...
>
>   REGISTER_WINDOWINGSYSTEMINTERFACE(OSGQT_EXPORT, Qt, QtWindowingSystem)
>
> Of course the down-side is that it would change the interface to the macro; 
> but that seems better than the alternative of breaking on Windows.  I'm happy 
> to test if you need.
>
>  - Dan
>
>
>> -Original Message-
>> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
>> Behalf Of Robert Osfield
>> Sent: Friday, May 18, 2018 10:49 AM
>> To: OpenSceneGraph Users
>> Subject: [osg-users] Please test OpenSceneGraph-3.6
>>
>> Hi All,
>>
>> I have checked in a few fixes today, one of them I'm not confident
>> that it'll work across all platforms so I won't make 3.6.1-rc5 today,
>> instead I'll wait for feedback from the community.
>>
>> As usual please let us know via this thread about success or failures.
>>
>> Thanks for the testing,
>> 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] Please test OpenSceneGraph-3.6

2018-05-21 Thread Daniel Emminizer, Code 5773
Hi Robert,

Getting a Windows build error on osgQt from the change on 
REGISTER_WINDOWINGSYSTEMINTERFACE() macro from last week.  Are you the right 
person to report the problem to?

osgQt's GraphicsWindowQt.cpp includes the line:

  #if 1
  REGISTER_WINDOWINGSYSTEMINTERFACE(Qt, QtWindowingSystem)
  ...

With the change to the macro, it expands to:
  extern "C" OSGVIEWER_EXPORT void graphicswindow_qt(void) {} 

where OSGVIEWER_EXPORT is defined as "__declspec(dllimport)" (because we're now 
in osgQt and not osgViewer)


One possible fix is to add a parameter to REGISTER_WINDOWINGSYSTEMINTERFACE to 
specify the export flavor, such as:

  #define REGISTER_WINDOWINGSYSTEMINTERFACE(export_type, ext, classname) \
extern "C export_type void ...

  REGISTER_WINDOWINGSYSTEMINTERFACE(OSGQT_EXPORT, Qt, QtWindowingSystem)

Of course the down-side is that it would change the interface to the macro; but 
that seems better than the alternative of breaking on Windows.  I'm happy to 
test if you need.

 - Dan


> -Original Message-
> From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On
> Behalf Of Robert Osfield
> Sent: Friday, May 18, 2018 10:49 AM
> To: OpenSceneGraph Users
> Subject: [osg-users] Please test OpenSceneGraph-3.6
> 
> Hi All,
> 
> I have checked in a few fixes today, one of them I'm not confident
> that it'll work across all platforms so I won't make 3.6.1-rc5 today,
> instead I'll wait for feedback from the community.
> 
> As usual please let us know via this thread about success or failures.
> 
> Thanks for the testing,
> Robert.
> 

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


Re: [osg-users] Draw two translucent geometries in specific order

2018-05-21 Thread Robert Osfield
Hi Kirs,

I'm afraid I'm too busy with other work right now to spend lots of
time reading other various posts on topic, or provide long essays on
here on the topic.

In short:

There is only one default RenderBin in the OSG, that's the main
RenderStage (subclasses from RenderBin).

The StateSet::setRenderBinDetails(BinNumber, "RenderBinPrototypeName")
sets the BinNumber and the "RenderBinPrototypeName" string hints to
the cull traversal what type of bin to create for that BinNumber if
one hasn't yet been created for it.  The strings match up to the list
I posted earlier - this RenderBinProtypeList maps the string to a
RenderBin that is cloned and stored in the rendering backend, and it's
into this bin that the subgraph below that StateSet are dropped into.

RenderBin's can be nested as many times as you want.  A RenderStage is
a RenderBin subclass that is used for high level stages in rendering
such as render to a texture or rendering to the main window, in this
case you have control over the clearing of buffers and any operations
that are done after the rendering.  The front end for controlling
RenderStage is osg::Camera.

Robert.

On 21 May 2018 at 10:34, Kristofer Krus  wrote:
> Hi again robertosfield, I took a look at the code you posted at this thread 
> (http://forum.openscenegraph.org/viewtopic.php?t=17289), and it gave me some 
> further questions.
>
> According to this code, there seems like there are six default rendering 
> bins, and I don't see that any numbers are associated with them. However, the 
> article (http://www.bricoworks.com/articles/stategraph/stategraph.html) I 
> linked to claims there are two default rendering bins, numbered 0 and 10. Why 
> does that article claim that, if the code seems to imply something very 
> different? Also, why would it say that the numbers used for those bins are 0 
> and 10? That seems kind of arbitrary to me and doesn't make much sense.
>
>
> robertosfield wrote:
>> subgraphA->getOrCrreateStateSet()->setRenderinBinDetails("RenderBin", 5); // 
>> or "DepthSortedBin" if you have mulitple transparent objects that need 
>> sorting
>> subgraphB->getOrCrreateStateSet()->setRenderinBinDetails("RenderBin", 6);
>
>
> There is no method called setRenderinBinDetails, but there is a method called 
> setRenderBinDetails. And the order of the arguments for this method is the 
> reversed compared to what you write, i.e. setRenderBinDetails(5, "RenderBin") 
> and setRenderBinDetails(6, "RenderBin").
>
> Also, what do the arguments do? When I use the code you suggested, A is now 
> always rendered after B, i.e. in the wrong order, no matter if I use the 
> numbers 5 and 6 or if I swap them so that I use the numbers 6 and 5. (This 
> seems to be independent of the direction I view the scene from, which is a 
> good thing, though.) I had the impression that render bins with higher 
> numbers would always be rendered later, and that the number we provide as an 
> argument to setRenderBinDetails is the number of the bin we want to put the 
> subgraph in, but this doesn't seem to be the case.
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=73687#73687
>
>
>
>
>
> ___
> 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] List render bins

2018-05-21 Thread Kristofer Krus
Hi,

I'm trying to gain a greater understanding of render bins, and I was thinking 
both, basically. I.e. both what render bins OSG created when the application 
started, and what render bins are created by the application I'm working with. 
This snippet of code was helpful, though, thanks.

I didn't expect there to be a method specifically for listing all render bins, 
but I imagine there must be some container or something they are stored in, and 
I wanted to loop through all elements in this container and print information 
about them.

Cheers,
Kristofer

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





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


Re: [osg-users] Draw two translucent geometries in specific order

2018-05-21 Thread Kristofer Krus
Hi again robertosfield, I took a look at the code you posted at this thread 
(http://forum.openscenegraph.org/viewtopic.php?t=17289), and it gave me some 
further questions.

According to this code, there seems like there are six default rendering bins, 
and I don't see that any numbers are associated with them. However, the article 
(http://www.bricoworks.com/articles/stategraph/stategraph.html) I linked to 
claims there are two default rendering bins, numbered 0 and 10. Why does that 
article claim that, if the code seems to imply something very different? Also, 
why would it say that the numbers used for those bins are 0 and 10? That seems 
kind of arbitrary to me and doesn't make much sense.


robertosfield wrote:
> subgraphA->getOrCrreateStateSet()->setRenderinBinDetails("RenderBin", 5); // 
> or "DepthSortedBin" if you have mulitple transparent objects that need sorting
> subgraphB->getOrCrreateStateSet()->setRenderinBinDetails("RenderBin", 6);


There is no method called setRenderinBinDetails, but there is a method called 
setRenderBinDetails. And the order of the arguments for this method is the 
reversed compared to what you write, i.e. setRenderBinDetails(5, "RenderBin") 
and setRenderBinDetails(6, "RenderBin").

Also, what do the arguments do? When I use the code you suggested, A is now 
always rendered after B, i.e. in the wrong order, no matter if I use the 
numbers 5 and 6 or if I swap them so that I use the numbers 6 and 5. (This 
seems to be independent of the direction I view the scene from, which is a good 
thing, though.) I had the impression that render bins with higher numbers would 
always be rendered later, and that the number we provide as an argument to 
setRenderBinDetails is the number of the bin we want to put the subgraph in, 
but this doesn't seem to be the case.

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





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


Re: [osg-users] Draw two translucent geometries in specific order

2018-05-21 Thread Kristofer Krus

Chris Hanson wrote:
> You might also look at OSGTransparencyToolkit. 
> http://alphapixel.com/project/osg-transparency-toolkit/ 
> (http://alphapixel.com/project/osg-transparency-toolkit/)
> 
> There are several Order Independent Transparency implementation out there 
> that let you not worry about the object draw order.


Thanks, I might possibly take a look at this if I can't make it work in any 
other way. Currently, I just want to make sure B is rendered after A (and that 
A and B are both rendered after everything else, which is fully opaque).

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





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


Re: [osg-users] List renderbins

2018-05-21 Thread Robert Osfield
Hi Kristofer,

Are you asking what RenderBin implementations are available to be in
the OSG itself, or what RenderBin's have been created by your
application at runtime?

The list of ones that are available by default is set up by
OpenSceneGraph/src/osgUtil/RenderBin.cpp, at the top of the .cpp is
the list of one that are provided by default (you can define your own
if you want.)  The code that sets them up is:

class RenderBinPrototypeList : osg::depends_on,
   public osg::Referenced, public
std::map< std::string, osg::ref_ptr >
{
public:
RenderBinPrototypeList()
{
add("RenderBin",new
RenderBin(RenderBin::getDefaultRenderBinSortMode()));
add("StateSortedBin",new RenderBin(RenderBin::SORT_BY_STATE));
add("DepthSortedBin",new RenderBin(RenderBin::SORT_BACK_TO_FRONT));
add("SORT_BACK_TO_FRONT",new
RenderBin(RenderBin::SORT_BACK_TO_FRONT));
add("SORT_FRONT_TO_BACK",new
RenderBin(RenderBin::SORT_FRONT_TO_BACK));
add("TraversalOrderBin",new RenderBin(RenderBin::TRAVERSAL_ORDER));
}

void add(const std::string& name, RenderBin* bin)
{
(*this)[name] = bin;
}

~RenderBinPrototypeList() {}
};


There isn't a method for listing this, I've never added as no one has
ever asked...

Robert.

On 21 May 2018 at 08:01, Kristofer Krus  wrote:
> Hi,
>
> Is there some way in which I can list all existing render bins and print 
> details about them, i.e. number, name and mode (the details given to 
> setRenderBinDetails 
> (http://public.vrac.iastate.edu/vancegroup/docs/OpenSceneGraphReferenceDocs-3.0/a00762.html#a498095c3811e00b2fc6123a24ef5ec81))?
>
> Thank you!
>
> Cheers,
> Kristofer
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=73683#73683
>
>
>
>
>
> ___
> 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] List renderbins

2018-05-21 Thread Kristofer Krus
Hi,

Is there some way in which I can list all existing render bins and print 
details about them, i.e. number, name and mode (the details given to 
setRenderBinDetails 
(http://public.vrac.iastate.edu/vancegroup/docs/OpenSceneGraphReferenceDocs-3.0/a00762.html#a498095c3811e00b2fc6123a24ef5ec81))?

Thank you!

Cheers,
Kristofer

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





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