Glenn Waldron | 13 Feb 18:34 2016
Picon
Gravatar

osgText and SCREEN_COORDS -- aspect ratio problem

Robert,

I'm using osgText with setCharacterSizeMode(SCREEN_COORDS). The vertical size of the text is always correct, but the horizontal size changes with the aspect ratio of the viewport.

This is easy to reproduce with the "osgtext" example. Just run the example and resize the window so that it has a high x/y aspect ratio (say 10x as wide as it is high). You can see the pink SCREEN_COORDS text in the center become squished.

I believe the problem is here:


For SCREEN_COORDS, I believe that a single scale factor for both vertical and horizontal makes sense. (If I change both scale factors to use "pixelSizeVert" the problem goes away).

If this makes sense, I can file a submission. Thanks.

Glenn Waldron
<div><div dir="ltr">
<div><div class="gmail_signature"><div dir="ltr">
<div>Robert,</div>
<div><br></div>
<div>I'm using osgText with setCharacterSizeMode(SCREEN_COORDS). The vertical size of the text is always correct, but the horizontal size changes with the aspect ratio of the viewport.</div>
<div><br></div>
<div>This is easy to reproduce with the "osgtext" example. Just run the example and resize the window so that it has a high x/y aspect ratio (say 10x as wide as it is high). You can see the pink SCREEN_COORDS text in the center become squished.</div>
<div><br></div>
<div>I believe the problem is here:</div>
<div><br></div>
<div>
<a href="https://github.com/openscenegraph/osg/blob/master/src/osgText/Text.cpp#L688">https://github.com/openscenegraph/osg/blob/master/src/osgText/Text.cpp#L688</a><br>
</div>
<div><br></div>
<div>For SCREEN_COORDS, I believe that a single scale factor for both vertical and horizontal makes sense. (If I change both scale factors to use&nbsp;"pixelSizeVert" the problem goes away).</div>
<div><br></div>
<div>If this makes sense, I can file a submission. Thanks.</div>
<div><br></div>
<div>Glenn Waldron</div>
</div></div></div>
</div></div>
Alex Taylor | 11 Feb 20:49 2016
Picon

Changes in osgVolume from 3.0 to 3.4

Hi Robert,


Thanks so much, the thread you referenced, "osgViewer/Renderer ctor
set wrong defaults for SceneView" has mostly resolved the blending issues I was having. I now call:

        osg::ref_ptr<osg::StateSet> stateSet = osgCamera->getOrCreateStateSet();
        stateSet->setGlobalDefaults();

When setting up my Camera. Things *mostly* look good now. I am still having one lingering problem with the way my isosurfaces are rendering with RayTracedTechnique as a result of the OSG 3.4 upgrade from OSG 3.0. I'm using RayTracedTechnique with the default shaders used by RayTracedTechnique, no hardcoded shaders paths or anything like that.

        if (volumeProperties.volumeTechnique == VolumeTechnique::RayTraced){
            osg::ref_ptr<osgVolume::RayTracedTechnique> rayTraced = new osgVolume::RayTracedTechnique();
            tile->setVolumeTechnique(rayTraced.get());
            osg::ref_ptr<osg::FrontFace> frontFace(new osg::FrontFace(osg::FrontFace::CLOCKWISE));
            stateset->setAttribute(frontFace.get(), osg::StateAttribute::PROTECTED);

        } else if (volumeProperties.volumeTechnique == VolumeTechnique::FixedFunction) {
            tile->setVolumeTechnique(new osgVolume::FixedFunctionTechnique());
            stateset->setMode(GL_LIGHTING,osg::StateAttribute::OFF | osg::StateAttribute::OVERRIDE);
        } else {
            throw hg::PropertyException("VolumeTechnique");
        }

        layer->addProperty(new osgVolume::TransferFunctionProperty(volumeProperties.transferFunction.get()));
        layer->addProperty(new osgVolume::AlphaFuncProperty(volumeProperties.alphaFunc));
        layer->addProperty(new osgVolume::SampleDensityProperty(volumeProperties.sampleDensity));
        layer->addProperty(new osgVolume::SampleDensityWhenMovingProperty(volumeProperties.sampleDensityWhenMoving));
        if (volumeProperties.useLighting) layer->addProperty(new osgVolume::LightingProperty);
        if (volumeProperties.useIsosurface) layer->addProperty(new osgVolume::IsoSurfaceProperty(volumeProperties.alphaFunc));
        if (volumeProperties.useMaximumIntensityProjection) layer->addProperty(new osgVolume::MaximumIntensityProjectionProperty());

Attached is what I see for isosurfaces in OSG 3.4 vs. OSG 3.0. The OSG 3.4 isosurfaces are rendering very "washed out" looking. I suspect I'm still having some sort of Blending issue with the Isosurface specifically. Any thoughts on what that might be happening?

Either way, I have really appreciated your help.

- Alex
________________________________________
From: osg-users <osg-users-bounces-ZwoEplunGu0hajLcUbyfC12AsgEQdTeF@public.gmane.org> on behalf of Robert Osfield <robert.osfield-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Sent: Thursday, February 4, 2016 6:43 AM
To: OpenSceneGraph Users

Subject: Re: [osg-users] Changes in osgVolume from 3.0 to 3.4

Hi Alex,

The blending difference might be down to a bug fix elsewhere in the
OSG.  Have a look at yesterdays discussion "osgViewer/Renderer ctor
set wrong defaults for SceneView", in particular my replies that
explain how a bug fix (in OSG-3.2 onwards) to the way that global
State is managed reveals a deficiency in the viewer set up.

As the light direction issue, the new way is more general purpose, the
old behaviour isn't required, the old shaders aren't maintained.  If
you want the old shaders and uniform set up you'll need to write these
yourself, or just adopt the new approach and have your viewer
manipulate the main light source using the viewer's Light or an
osg::LightSource placed in the scene.

Robert.

osg-users
x

On 3 February 2016 at 21:11, Alex Taylor <alextaylor-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Robert,
>
> Thanks. There are two main culprits the behavior change I was seeing. The
> first is that for some reason, between OSG 3.0 and 3.4, I now need to
> explicitly set a BlendFunc. With the exception of MIP, it looks like the
> rest of osgVolume just renders with a default BlendFunc and doesn't
> explictly set anything.
>
> I found that by setting
>
>  stateset->setAttribute(new osg::BlendFunc(GL_SRC_ALPHA,
> GL_ONE_MINUS_SRC_ALPHA), osg::StateAttribute::ON);
>
> There is a second issue I want to ask about:
>
> It looks to me there was a change to the shaders I'm using regarding the
> position of the light source between OSG 3.0 and OSG 3.4:
>
> https://github.com/openscenegraph/osg/commit/4525ec49a386b48608fdb3107033a1c915d928e6
>
> The change is to honor the lightDirection from GL_LIGHT0 rather than use the
> eye direction as the direction of the light source.
>
> If I wanted to get the old behavior of using the eyeDirection, is there an
> easy way to go about that?
>
> Thanks,
>
> Alex
>
>
> On Thu, Jan 28, 2016 at 3:16 PM Robert Osfield <robert.osfield-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> wrote:
>>
>> Hi Alex,
>>
>> There were quite a few improvements to osgVolume between OSG-3.0 and
>> OSG-3.4, both in shaders and the introduction of the new MultiPassTechnique.
>> One thing to look at with your own setup is that you aren't picking up on
>> old
>>  shaders such as by having your own path to old shaders.
>>
>> It's quite a while since I did the work on osgVolume, around two years, so
>> won't be able to be specific without viewing code and being able to
>> reproduce the problems you are seeing first hand.
>>
>> Robert.
>>
>> On 28 January 2016 at 15:25, Alex Taylor <alextaylor-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>>
>>> Hi,
>>>
>>> I'm working on upgrading the OSG version used in the product I work on.
>>> When OSG is upgraded with the same client code, I'm noticing differences is
>>> the way my volumes are rendered with all of the rendering algorithms that I
>>> can't explain. I've fixed the parameters I'm using to define the osgVolume
>>> in both versions, so it can't be a matter of picking up a different default
>>> option for a parameter.
>>>
>>> OSG 3.4 Fixed Function
>>>
>>> OSG 3.0 Fixed Function
>>>
>>>
>>> OSG 3.4 Ray Traced Lit
>>>
>>>
>>> OSG 3.0 Ray Traced Lit
>>>
>>>
>>>
>>> OSG 3.4 Isosurface
>>>
>>> OSG 3.0 Isosurface
>>>
>>>
>>> In the Ray Traced cases, I'm using the properties:
>>>
>>> AlphaFunc = 0.02;
>>> SampleDensity = 0.005;
>>>
>>> I'm using setting the TransferFunctionProperty, so I'm using the shaders
>>> to do the alpha/color mapping.
>>>
>>> For the FixedFunctionTechnique, I'm using AlphaFunc = 0.02, and using the
>>> applyTransferFunction function to obtain an RGBA mapped osg::Image buffer.
>>>
>>> It's very possible that the upgrade to 3.4 has changed something else in
>>> my overall use of OSG elsewhere in the pipeline, unrelated to osgVolume,
>>> that is causing this issue. That said, I thought i'd ask if visually anyone
>>> has a guess it what might have changed between osg 3.0 and osg 3.4 that
>>> might explain these visual differences.
>>>
>>> Thanks for your help,
>>>
>>> Alex
>>>
>>>
>>>
>>> _______________________________________________
>>> osg-users mailing list
>>> osg-users-ZwoEplunGu0hajLcUbyfC12AsgEQdTeF@public.gmane.org
>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>
>>
>> _______________________________________________
>> osg-users mailing list
>> osg-users-ZwoEplunGu0hajLcUbyfC12AsgEQdTeF@public.gmane.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
> _______________________________________________
> osg-users mailing list
> osg-users-ZwoEplunGu0hajLcUbyfC12AsgEQdTeF@public.gmane.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
_______________________________________________
osg-users mailing list
osg-users-ZwoEplunGu0hajLcUbyfC12AsgEQdTeF@public.gmane.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
<div><div dir="ltr"><div class="gmail_quote">
<div dir="ltr"><div dir="ltr"><div>
<p><span>Hi Robert,</span></p>
<br>
Thanks so much, the thread you referenced, "osgViewer/Renderer ctor<br>
set wrong defaults for SceneView" has mostly resolved the blending issues I was having. I now call:<br><br><span><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; osg::ref_ptr&lt;osg::StateSet&gt; stateSet = osgCamera-&gt;getOrCreateStateSet();</span></span><br><span><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; stateSet-&gt;setGlobalDefaults();</span></span><br><br>
When setting up my Camera. Things *mostly* look good now. I am still having one lingering problem with the way my isosurfaces are rendering with RayTracedTechnique as a result of the OSG 3.4 upgrade from OSG 3.0. I'm using RayTracedTechnique with the default
 shaders used by RayTracedTechnique, no hardcoded shaders paths or anything like that.<br><br><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if (volumeProperties.volumeTechnique == VolumeTechnique::RayTraced){</span><br><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; osg::ref_ptr&lt;osgVolume::RayTracedTechnique&gt; rayTraced = new osgVolume::RayTracedTechnique();</span><br><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; tile-&gt;setVolumeTechnique(rayTraced.get());</span><br><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; osg::ref_ptr&lt;osg::FrontFace&gt; frontFace(new osg::FrontFace(osg::FrontFace::CLOCKWISE));</span><br><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; stateset-&gt;setAttribute(frontFace.get(), osg::StateAttribute::PROTECTED);</span><br><br><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } else if (volumeProperties.volumeTechnique == VolumeTechnique::FixedFunction) {</span><br><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; tile-&gt;setVolumeTechnique(new osgVolume::FixedFunctionTechnique());</span><br><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; stateset-&gt;setMode(GL_LIGHTING,osg::StateAttribute::OFF | osg::StateAttribute::OVERRIDE);</span><br><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; } else {</span><br><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; throw hg::PropertyException("VolumeTechnique");</span><br><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }</span><br><br><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; layer-&gt;addProperty(new osgVolume::TransferFunctionProperty(volumeProperties.transferFunction.get()));</span><br><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; layer-&gt;addProperty(new osgVolume::AlphaFuncProperty(volumeProperties.alphaFunc));</span><br><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; layer-&gt;addProperty(new osgVolume::SampleDensityProperty(volumeProperties.sampleDensity));</span><br><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; layer-&gt;addProperty(new osgVolume::SampleDensityWhenMovingProperty(volumeProperties.sampleDensityWhenMoving));</span><br><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (volumeProperties.useLighting) layer-&gt;addProperty(new osgVolume::LightingProperty);</span><br><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (volumeProperties.useIsosurface) layer-&gt;addProperty(new osgVolume::IsoSurfaceProperty(volumeProperties.alphaFunc));</span><br><span>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (volumeProperties.useMaximumIntensityProjection) layer-&gt;addProperty(new osgVolume::MaximumIntensityProjectionProperty());</span><br><br>
Attached is what I see for isosurfaces in OSG 3.4 vs. OSG 3.0. The OSG 3.4 isosurfaces are rendering very "washed out" looking. I suspect I'm still having some sort of Blending issue with the Isosurface specifically. Any thoughts on what that might be happening?
<div><br></div>
<div>Either way, I have&nbsp;really appreciated your help.<br>
</div>
<div><br></div>
<div>- Alex<br>
</div>
<div>&#8203;
<div>________________________________________<br>
From: osg-users &lt;<a href="mailto:osg-users-bounces@...h.org" target="_blank">osg-users-bounces@...</a>&gt; on behalf of Robert Osfield &lt;<a href="mailto:robert.osfield@..." target="_blank">robert.osfield@...</a>&gt;<br>
Sent: Thursday, February 4, 2016 6:43 AM<br>
To: OpenSceneGraph Users</div>
</div>
</div></div></div>
<div dir="ltr"><div dir="ltr"><div><div><div>
<br>
Subject: Re: [osg-users] Changes in osgVolume from 3.0 to 3.4<br><br>
</div></div></div></div></div>
<div dir="ltr"><div dir="ltr"><div><div><div>
Hi Alex,<br><br>
The blending difference might be down to a bug fix elsewhere in the<br>
OSG.&nbsp; Have a look at yesterdays discussion "osgViewer/Renderer ctor<br>
set wrong defaults for SceneView", in particular my replies that<br>
explain how a bug fix (in OSG-3.2 onwards) to the way that global<br>
State is managed reveals a deficiency in the viewer set up.<br><br>
As the light direction issue, the new way is more general purpose, the<br>
old behaviour isn't required, the old shaders aren't maintained.&nbsp; If<br>
you want the old shaders and uniform set up you'll need to write these<br>
yourself, or just adopt the new approach and have your viewer<br>
manipulate the main light source using the viewer's Light or an<br>
osg::LightSource placed in the scene.<br><br>
Robert.<br><br>
osg-users<br>
x<br><br>
On 3 February 2016 at 21:11, Alex Taylor &lt;<a href="mailto:alextaylor <at> gmail.com" target="_blank">alextaylor@...</a>&gt; wrote:<br>
&gt; Robert,<br>
&gt;<br>
&gt; Thanks. There are two main culprits the behavior change I was seeing. The<br>
&gt; first is that for some reason, between OSG 3.0 and 3.4, I now need to<br>
&gt; explicitly set a BlendFunc. With the exception of MIP, it looks like the<br>
&gt; rest of osgVolume just renders with a default BlendFunc and doesn't<br>
&gt; explictly set anything.<br>
&gt;<br>
&gt; I found that by setting<br>
&gt;<br>
&gt;&nbsp; stateset-&gt;setAttribute(new osg::BlendFunc(GL_SRC_ALPHA,<br>
&gt; GL_ONE_MINUS_SRC_ALPHA), osg::StateAttribute::ON);<br>
&gt;<br>
&gt; There is a second issue I want to ask about:<br>
&gt;<br>
&gt; It looks to me there was a change to the shaders I'm using regarding the<br>
&gt; position of the light source between OSG 3.0 and OSG 3.4:<br>
&gt;<br>
&gt; <a href="https://github.com/openscenegraph/osg/commit/4525ec49a386b48608fdb3107033a1c915d928e6" target="_blank">
https://github.com/openscenegraph/osg/commit/4525ec49a386b48608fdb3107033a1c915d928e6</a><br>
&gt;<br>
&gt; The change is to honor the lightDirection from GL_LIGHT0 rather than use the<br>
&gt; eye direction as the direction of the light source.<br>
&gt;<br>
&gt; If I wanted to get the old behavior of using the eyeDirection, is there an<br>
&gt; easy way to go about that?<br>
&gt;<br>
&gt; Thanks,<br>
&gt;<br>
&gt; Alex<br>
&gt;<br>
&gt;<br>
&gt; On Thu, Jan 28, 2016 at 3:16 PM Robert Osfield &lt;<a href="mailto:robert.osfield@..." target="_blank">robert.osfield@...</a>&gt;<br>
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Hi Alex,<br>
&gt;&gt;<br>
&gt;&gt; There were quite a few improvements to osgVolume between OSG-3.0 and<br>
&gt;&gt; OSG-3.4, both in shaders and the introduction of the new MultiPassTechnique.<br>
&gt;&gt; One thing to look at with your own setup is that you aren't picking up on<br>
&gt;&gt; old<br>
&gt;&gt;&nbsp; shaders such as by having your own path to old shaders.<br>
&gt;&gt;<br>
&gt;&gt; It's quite a while since I did the work on osgVolume, around two years, so<br>
&gt;&gt; won't be able to be specific without viewing code and being able to<br>
&gt;&gt; reproduce the problems you are seeing first hand.<br>
&gt;&gt;<br>
&gt;&gt; Robert.<br>
&gt;&gt;<br>
&gt;&gt; On 28 January 2016 at 15:25, Alex Taylor &lt;<a href="mailto:alextaylor@..." target="_blank">alextaylor@...</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Hi,<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I'm working on upgrading the OSG version used in the product I work on.<br>
&gt;&gt;&gt; When OSG is upgraded with the same client code, I'm noticing differences is<br>
&gt;&gt;&gt; the way my volumes are rendered with all of the rendering algorithms that I<br>
&gt;&gt;&gt; can't explain. I've fixed the parameters I'm using to define the osgVolume<br>
&gt;&gt;&gt; in both versions, so it can't be a matter of picking up a different default<br>
&gt;&gt;&gt; option for a parameter.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; OSG 3.4 Fixed Function<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; OSG 3.0 Fixed Function<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; OSG 3.4 Ray Traced Lit<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; OSG 3.0 Ray Traced Lit<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; OSG 3.4 Isosurface<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; OSG 3.0 Isosurface<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; In the Ray Traced cases, I'm using the properties:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; AlphaFunc = 0.02;<br>
&gt;&gt;&gt; SampleDensity = 0.005;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I'm using setting the TransferFunctionProperty, so I'm using the shaders<br>
&gt;&gt;&gt; to do the alpha/color mapping.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; For the FixedFunctionTechnique, I'm using AlphaFunc = 0.02, and using the<br>
&gt;&gt;&gt; applyTransferFunction function to obtain an RGBA mapped osg::Image buffer.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; It's very possible that the upgrade to 3.4 has changed something else in<br>
&gt;&gt;&gt; my overall use of OSG elsewhere in the pipeline, unrelated to osgVolume,<br>
&gt;&gt;&gt; that is causing this issue. That said, I thought i'd ask if visually anyone<br>
&gt;&gt;&gt; has a guess it what might have changed between osg 3.0 and osg 3.4 that<br>
&gt;&gt;&gt; might explain these visual differences.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Thanks for your help,<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Alex<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; _______________________________________________<br>
&gt;&gt;&gt; osg-users mailing list<br>
&gt;&gt;&gt; <a href="mailto:osg-users@..." target="_blank">osg-users@...</a><br>
&gt;&gt;&gt; <a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" target="_blank">
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; osg-users mailing list<br>
&gt;&gt; <a href="mailto:osg-users@..." target="_blank">osg-users@...</a><br>
&gt;&gt; <a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" target="_blank">
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; osg-users mailing list<br>
&gt; <a href="mailto:osg-users@..." target="_blank">osg-users@...</a><br>
&gt; <a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" target="_blank">
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>
&gt;<br>
_______________________________________________<br>
osg-users mailing list<br><a href="mailto:osg-users@..." target="_blank">osg-users@...</a><br><a href="http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org" target="_blank">http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org</a><br>
</div></div></div></div></div>
</div></div></div>
Mike Greene | 11 Feb 20:43 2016
Picon

[build] undefined setColorArray and setNormalArray in 3.2.3

Hi,

Have some older code that I have working with on Windows (OSG 3.2.1). Uses setColorArray and setNormal
array to define some primitive geometry.

While porting to LINUX using OSG 3.2.3, I get undefines on these two methods while linking. Are there some
"deprecation" flags or something I need to link these in?

Thank you!

Cheers,
Mike

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

Trajce Nikolov NICK | 11 Feb 12:00 2016
Picon

osgviewer and OpenGL 3.3

Hi Community,

I started with the OpenGL 3.3 (fixing issues with Mesa for Intel board). Any hints how to display the cessna model for example under Linux with 3.3 context?

Thanks a bunch as always!

--
trajce nikolov nick
<div><div dir="ltr">Hi Community,<div><br></div>
<div>I started with the OpenGL 3.3 (fixing issues with Mesa for Intel board). Any hints how to display the cessna model for example under Linux with 3.3 context?</div>
<div><br></div>
<div>Thanks a bunch as always!<br clear="all"><div><br></div>-- <br><div class="gmail_signature">trajce nikolov nick<br>
</div>
</div>
</div></div>
Etienne de Sarrieu | 8 Feb 14:12 2016

[build] Building OSG 3.4.0 with VS2009, Windows 7, minor issues (fixed)

Hi,

I was trying to build OpenSceneGraph 3.4.0 with CMake 3.2.2, Visual Studio 2008 (MSC_VER=1500) on a
windows 7 station.

I had following error :

Code:
43>l:\compil_osg\openscenegraph-3.4.0\src\osgplugins\osgjs\JSON_Objects(26) : error C2371:
'int8_t' : redefinition; different basic types
43>        L:\COMPIL_OSG\OpenSceneGraph-3.4.0\include\osg/Types(18) : see declaration of 'int8_t'

Which I fixed in ReaderWriterSTL.cpp :

Code:
#ifndef __OSG_TYPES
#if defined(_WIN32) && !defined(__MINGW32__) && (!defined(_MSC_VER) || _MSC_VER<1600)

typedef unsigned __int8 uint8_t;
typedef unsigned __int16 uint16_t;
typedef unsigned __int32 uint32_t;
typedef signed __int8 int8_t;
typedef signed __int16 int16_t;
typedef signed __int32 int32_t;

#else

#include <stdint.h>

#endif
#endif

First and last line of code were added in the quoted code.
I had to do quite the same fix in JSON_Objects header in order to terminate OSG build.

If this is could be due to a mistake in my configuration, please let me know, otherwise I wanted to share this
to the community if you think this should be fixed in trunk.

Cheers,
Etienne

PS I can give more details if you need it.

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

Christophe Lhe | 3 Feb 12:00 2016
Picon

[build] Can't execute Qt example in IOS environment

Hi,

My platform is Emac 10.9 with IOS sdk 8.2.

I succedeed in compiling OSG 3.4 for IOS.

I inserted the viewerQT example in QT creator, and added osgplugin.h found in osgviewerIphone example
(needed for static lib).

But I have following error when I launch the viewerQT with the data file robot.osg :

Code:
Warning: detected OpenGL error 'invalid enumerant' at Before Renderer::compile
VERTEX glCompileShader "" FAILED
VERTEX Shader "" infolog:
ERROR: 0:16: Use of undeclared identifier 'gl_LightSource'
ERROR: 0:17: Use of undeclared identifier 'lpos'
ERROR: 0:18: Use of undeclared identifier 'lpos'
ERROR: 0:20: Use of undeclared identifier 'lpos'

FRAGMENT glCompileShader "" FAILED
FRAGMENT Shader "" infolog:
ERROR: 0:1: 'vec3' : declaration must include a precision qualifier for type
ERROR: 0:2: 'vec3' : declaration must include a precision qualifier for type
ERROR: 0:3: 'vec3' : declaration must include a precision qualifier for type
ERROR: 0:7: 'vec4' : declaration must include a precision qualifier for type
ERROR: 0:8: Use of undeclared identifier 'normalDir'
ERROR: 0:9: Use of undeclared identifier 'lightDir'
ERROR: 0:10: Use of undeclared identifier 'viewDir'
ERROR: 0:11: Use of undeclared identifier 'gl_FrontLightModelProduct'
ERROR: 0:12: Use of undeclared identifier 'color'
ERROR: 0:12: Use of undeclared identifier 'gl_FrontLightProduct'
ERROR: 0:13: Use of undeclared identifier 'ld'
ERROR: 0:13: Use of undeclared identifier 'nd'
ERROR: 0:14: Use of undeclared identifier 'color'
ERROR: 0:14: Use of undeclared identifier 'gl_FrontLightProduct'
ERROR: 0:14: Use of undeclared identifier 'diff'
ERROR: 0:15: Use of undeclared identifier 'color'
ERROR: 0:15: Use of undeclared identifier 'base'
ERROR: 0:16: Use of undeclared identifier 'diff'
ERROR: 0:18: Use of undeclared identifier 'ld'
ERROR: 0:18: Use of undeclared identifier 'vd'
ERROR: 0:19: Use of undeclared identifier 'color'
ERROR: 0:19: Use of undeclared identifier 'base'
ERROR: 0:19: Use of undeclared identifier 'gl_FrontLightProduct'
ERROR: 0:20: Use of undeclared identifier 'halfDir'
ERROR: 0:20: Use of undeclared identifier 'nd'
ERROR: 0:20: Use of undeclared identifier 'gl_FrontMaterial'
ERROR: 0:22: Use of undeclared identifier 'color'

glLinkProgram "" FAILED
Program "" infolog:
ERROR: One or more attached shaders not successfully compiled

Warning: Material::apply(State&) - not supported.
Warning: ShadeModel::apply(State&) - not supported.

Any help would be appreciated to have OSG working with QT on IOS...

Here is the cmake configuration : 
        -DOSG_BUILD_PLATFORM_IPHONE:BOOL=ON 
        -DDYNAMIC_OPENSCENEGRAPH:BOOL=OFF 
        -DDYNAMIC_OPENTHREADS:BOOL=OFF 
        -DIPHONE_SDKVER:STRING=8.2 
        -DBUILD_OSG_APPLICATIONS:BOOL=OFF 
        -DBUILD_OSG_EXAMPLES:BOOL=OFF 
        -DOPENGL_PROFILE:STRING=GLES2 
        -DOSG_USE_QT:BOOL=ON 
        -DQt5Core_DIR:STRING=/Users/qt/Qt5.5.1/5.5/ios/lib/cmake/Qt5Core 
        -DQt5Gui_DIR:STRING=/Users/qt/Qt5.5.1/5.5/ios/lib/cmake/Qt5Gui \
        -DQt5OpenGL_DIR:STRING=/Users/qt/Qt5.5.1/5.5/ios/lib/cmake/Qt5OpenGL \
        -DQt5WebKitWidgets_DIR:STRING=/Users/qt/Qt5.5.1/5.5/ios/lib/cmake/Qt5WebKitWidgets \
        -DQt5Widgets_DIR:STRING=/Users/qt/Qt5.5.1/5.5/ios/lib/cmake/Qt5Widgets

And I added following lines in CMakeLists.txt :
        set (CMAKE_FIND_ROOT_PATH ${IPHONE_DEVROOT} ${IPHONE_SDKROOT} ${CMAKE_PREFIX_PATH} CACHE string 
"iOS find search path root")
        set (CMAKE_FIND_FRAMEWORK FIRST)
        set (CMAKE_SYSTEM_FRAMEWORK_PATH
              ${IPHONE_SDKROOT}/System/Library/Frameworks
              ${IPHONE_SDKROOT}/System/Library/PrivateFrameworks
              ${IPHONE_SDKROOT}/Developer/Library/Frameworks
        )
        set (CMAKE_FIND_ROOT_PATH_MODE_PROGRAM ONLY)
        set (CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
        set (CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
... 

Thank you!

Cheers,
christophe[/code]

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

Pierre-Jean Petitprez | 10 Feb 10:07 2016
Picon
Picon

osg_MultiTexCoord0 on OpenGL 2 vs GLES2

Hi,

I am working on an application that has to work both on regular Ubuntu environment and on Android. So I have
written a couple of shaders in order to comply with GLES2 specs.
The problem is, with regular OpenGL profile on Ubuntu, the same shader is not working properly: the
osg_MultiTexCoord0 seems to not be working, while gl_MultiTexCoord0 works (but obviously noton GLES2
of course).

Here is my vertex shader:

Code:

attribute vec4 osg_Vertex;
uniform mat4 osg_ModelViewProjectionMatrix;
attribute vec4 osg_MultiTexCoord0;
varying vec4 texCoord;

void main(void) {
gl_Position = osg_ModelViewProjectionMatrix * osg_Vertex;
texCoord = osg_MultiTexCoord0;
}

The fragment shader is just applying the texture thanks to the texCoord variable.

So on GLES2 this vertex shader works properly, but on OpenGL 2  I have to replace osg_MultiTexCoord0 by the
old gl_MultiTexCoord0 in order to make it work.

I have tried with OSG 3.2 (as apt packages on Ubuntu), 3.4 and 3.5 as sources, and I always get the same results.
I have applied setUseModelViewAndProjectionUniforms(true) on my graphics context state to enable
osg_* matrices.  Is there a possibility to also enable other osg_* variables ?

Thank you!

Cheers,
Pierre-Jean

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

Alexandre Vaillancourt | 9 Feb 15:28 2016
Picon

Re: [osgPlugins] OpenFlight plugin update

Hi,

Any new development on this?

We're thinking about including the opcodes for the extended material headers and Ambient/Diffuse/Specular/Emissive/Alpha (opcodes [135-139]), but only the data that can go in an osg::Material object.

Thank you!

Cheers,
Alexandre

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

<div>

	<div class="postbody">Hi,<br><br>
Any new development on this? <br><br>
We're thinking about including the opcodes for the extended material headers and Ambient/Diffuse/Specular/Emissive/Alpha (opcodes [135-139]), but only the data that can go in an osg::Material object.<br><br>
Thank you!<br><br>
Cheers,<br>
Alexandre</div>
	<br><div class="gensmall">------------------<br>
Read this topic online here:<br><a href="http://forum.openscenegraph.org/viewtopic.php?p=66242#66242" target="_blank">http://forum.openscenegraph.org/viewtopic.php?p=66242#66242</a><br><br>
</div>
	</div>
Jens Georg | 9 Feb 09:59 2016

dumptruck.osg and GL ES 2.0

Hi,

I was trying to build a demo scene with our OSG (3.2 branch until commit 
44cf6b92d2) (OpenGL ES 2.0) and I noticed that when I load dumptruck.osg 
(from 
https://raw.githubusercontent.com/openscenegraph/osg-data/master/dumptruck.osg) 
into osgviewer, the GL drawing operations seem to generate a heack of a 
lot of calls to glDrawArrays (GL_TRIANGLE_STRIP, some_offset, 3), so 
rendering each trianlge separately, causing a huge load on the system.

Is that expected to happen or is there something odd with our 
configuration or is that a bug?

KR, Jens.
Judson Weissert | 9 Feb 05:52 2016
Picon

Re: StateAttributeCallback marked deprecated

Bump.

Why is osg::StateAttributeCallback marked deprecated?

Thanks,

Judson

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

Scott Duensing | 8 Feb 23:04 2016
Gravatar

Controlling the version of OpenGL used.

Is it possible to specify which version of OpenGL is being used?  I do a lot of development inside a VM and it
doesn't quite have the GL capabilities of my actual hardware.  

Thanks.

Scott

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


Gmane