[osg-users] LineSegmentIntersector::intersect + performance

[Volckaert, Guy (CA - MTS)]

Hi,

I recently upgraded to the OSG v3.6.1 and I noticed that the new 
LineSegmentIntersector has changed significantly compared to v3.4.0. As I was 
reviewing the changes, I noticed that the LineSegmentIntersector now allocates 
an instance of LineSegmentIntersectorUtils::Settings every time the 
IntersectionVisitor intercepts a drawable.

>From a purely efficiency standpoint, I was wondering if we could do better. 
>Intersection were relatively slow in the past and now it seems that we made 
>even slower. That being said, I'm pretty sure there's a valid reason for why 
>it was done this way. Before I look at alternative solutions, I was wondering 
>if anyone could share for reasons.

Below is a snip-it of the function:

void LineSegmentIntersector::intersect(osgUtil::IntersectionVisitor& iv, 
osg::Drawable* drawable,
   const osg::Vec3d& s, const osg::Vec3d& e)
{
if (reachedLimit()) return;

osg::ref_ptr settings = new 
LineSegmentIntersectorUtils::Settings; // << HERE 
settings->_lineSegIntersector = this;
settings->_iv = 
settings->_drawable = drawable;
settings->_limitOneIntersection = (_intersectionLimit == 
LIMIT_ONE_PER_DRAWABLE || _intersectionLimit == LIMIT_ONE);

osg::Geometry* geometry = drawable->asGeometry();
if (geometry)
{
settings->_vertices = 
dynamic_cast(geometry->getVertexArray());
}

osg::KdTree* kdTree = iv.getUseKdTreeWhenAvailable() ? 
dynamic_cast(drawable->getShape()) : 0;

if (getPrecisionHint()==USE_DOUBLE_CALCULATIONS)
{

osg::TemplatePrimitiveFunctor > intersector;
intersector.set(s,e, settings.get());

if (kdTree) kdTree->intersect(intersector, kdTree->getNode(0));
else drawable->accept(intersector);
}
else
{

osg::TemplatePrimitiveFunctor > intersector;
intersector.set(s,e, settings.get());

if (kdTree) kdTree->intersect(intersector, kdTree->getNode(0));
else drawable->accept(intersector);
}
}

Regards,

Guy Volckaert, ing.
Snr 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
Cell: 1 (514) 928-5641
email: guy.volcka...@meggitt.com
url; www.meggitt.com
skype: guy.volckaert

Svp. Considérez l'environnement avant d'imprimer
Please consider the environment before printing this e-mail.





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.

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

[osg-users] Potential crash in ObjectCache::removeExpiredObjectsInCache

[Volckaert, Guy (CA - MTS)]

Hi,

I think I found a bug in the following function:

void ObjectCache::removeExpiredObjectsInCache(double expiryTime)
{
OpenThreads::ScopedLock lock(_objectCacheMutex);

// Remove expired entries from object cache
ObjectCacheMap::iterator oitr = _objectCache.begin();
while(oitr != _objectCache.end())
{
if (oitr->second.second<=expiryTime)
{
   // _objectCache.erase(oitr++);  << This line was 
causing unpredictable issues.
oitr = _objectCache.erase(oitr);<< replaced 
with this line.
}
else
{
++oitr;
}
}
}

Regards,

Guy Volckaert, ing.
Snr 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
Cell: 1 (514) 928-5641
email: guy.volcka...@meggitt.com
url; www.meggitt.com
skype: guy.volckaert

Svp. Considérez l'environnement avant d'imprimer
Please consider the environment before printing this e-mail.





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.

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

[osg-users] Post Processing Effect - Vertex Shader not working

[Volckaert, Guy (CA - MTS)]

Hi,

Sorry to bother you guys... but I was wondering if you can help identify why my 
pass through vertex shader isn't working. In essence, if I enable the vertex 
shader, then the scene disappears (I only see that blue background color). If I 
disable it then the scene appears correctly. No errors are generated by OSG 
after linking the vertex shader. I know that my fragment shader is working 
because if I set the gl_FragColor to red then the scene is completely red.

Here are my pass-thru shaders:

[code]
VERTEX SHADER
=
attribute vec4 osg_Vertex;
void main( void )
{
 gl_Position = osg_Vertex;
}

FRAGMENT SHADER
===
uniform sampler2D tRttTexture;

void main( void )
{
 vec3 vColor = texture2D( tRttTexture, gl_TexCoord[0].st ).rgb;
 // Output color.
 gl_FragColor = vec4( vColor, 1.0 );
}
[/code]


The shader is applied on a fullscreen quad using typical Ortho2D projection. 
Here is the code that loads the shader which is applied to the post process 
geode containing a single geometry quad:

[code]
void loadShaders( )
{
osg::StateSet* pStateSet = g_pPolyGeode->getOrCreateStateSet( );

osg::ref_ptr pProgram = new osg::Program;
pProgram->setName( "PostProcessProgram" );

osg::ref_ptr pVertShader = osg::Shader::readShaderFile( 
osg::Shader::VERTEX, osgDB::findDataFile( "shaders/osgprerender.vert" ) );
if( pVertShader )
{
pVertShader->setName( "osgprerender.vert" );
pProgram->addShader( pVertShader );
pProgram->addBindAttribLocation( "osg_Vertex", 0 );
}

osg::ref_ptr pFragShader = osg::Shader::readShaderFile( 
osg::Shader::FRAGMENT, osgDB::findDataFile( "shaders/osgprerender.frag" ) );
if( pFragShader )
{
pFragShader->setName( "osgprerender.frag" );
pProgram->addShader( pFragShader );
}

// RTT texture.
pStateSet->addUniform( new osg::Uniform( "tRttTexture", 0 ) );
pStateSet->setAttributeAndModes( pProgram, osg::StateAttribute::ON );
}
[/code]


What am I doing wrong? I tried different variation of the shader but nothing 
works. Here are the variations that I tried:

[code]
VARIATION #1
===
void main( void )
{
 gl_Position = gl_Vertex;
}

VARIATION #2
===
void main( void )
{
 gl_Position = gl_ModelViewProjectionMatrix * gl_Vertex;
}

VARIATION #3
===
attribute vec4 osg_Vertex;
void main( void )
{
 gl_Position = gl_ModelViewProjectionMatrix * osg_Vertex;
}

VARIATION #4
===
void main( void )
{
 gl_Position = ftransform();
}
[/code]

Any help would be really appreciated... The full source code is attached.

Thank you!

Cheers,
Guy

Guy Volckaert, ing.
Snr 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
Cell: 1 (514) 928-5641
email: guy.volcka...@meggitt.com
url; www.meggitt.com
skype: guy.volckaert

Svp. Considérez l'environnement avant d'imprimer
Please consider the environment before printing this e-mail.





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.

/* OpenSceneGraph example, osgprerender.
*
*  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 

Re: [osg-users] Optimizer::RemoveLoadedProxyNodesVisitor + NO_AUTOMATIC_LOADING

[Volckaert, Guy (CA - MTS)]

Hi Robert,

Understood... I appreciate the feedback. I'll probably end up implementing my 
own visitor to do what I need ;)

Regards,

-Original Message-
From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Robert Osfield
Sent: April-28-17 2:06 PM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Optimizer::RemoveLoadedProxyNodesVisitor + 
NO_AUTOMATIC_LOADING

Hi Guy,

The visitor in question is meant to just remove loading ProxyNode's it's not 
meant to remove nodes that haven't yet been loaded, doing so would potentially 
break applications where nodes disappear that are still needed.

What you describe is a special case - there are problems loading external nodes 
and you still want to get rid of them.  This is an application specific 
decision you are prepared to make but isn't a general solution.  My 
recommendation would be to just write a visitor that you run on the loaded 
subgraphs and cleans up items like ProxuNode's that have failed.  There may be 
other platform specific scene graph optimizations you can do that the OSG can 
do because it can't assume that it's safe.

Robert.

On 28 April 2017 at 18:10, Guy Volckaert  wrote:
> Hi,
>
> I was wondering if someone could explain why the 
> Optimizer::RemoveLoadedProxyNodesVisitor is not removing ProxyNodes with 
> NO_AUTOMATIC_LOADING set?
>
> Here is the motivation behind my question... We often need to load relatively 
> large openflight terrains that contains a significant number external 
> references. In fact, on some terrains, each single tree is an external 
> reference - so you can image how many external references that makes!!! 
> Unfortunately, many of these terrains are provided to us AS IS and we don't 
> have the necessary rights to modify them.
>
> What we discovered is that, sometimes, many of those external reference files 
> are missing, thus leading to poor performance. For example, if we simply 
> delete all the external references for a terrains, I would expect better 
> performance (since I don't need to render all those trees), but that's not 
> the case.
>
> To resolve this poor performance problem, I modified the following optimizer 
> function to consider the NO_AUTOMATIC_LOADING. Can you tell me if what I did 
> makes sense? If so, then I could propose this as a change in the 
> osg-submission.
>
>
> Code:
> void Optimizer::RemoveLoadedProxyNodesVisitor::apply(osg::ProxyNode&
> proxyNode) {
> if (proxyNode.getNumParents()>0
> && ( proxyNode.getNumFileNames()==proxyNode.getNumChildren()
> //MTSI_BEGIN
> || ( proxyNode.getLoadingExternalReferenceMode() ==
> osg::ProxyNode::NO_AUTOMATIC_LOADING && proxyNode.getNumChildren() == 0 ) ) ) 
> //MTSI_END
> {
> if (isOperationPermissibleForObject())
> {
> _redundantNodeList.insert();
> }
> }
> traverse(proxyNode);
> }
>
>
>
> Thank you!
>
> Cheers,
> Guy
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=70857#70857
>
>
>
>
>
> ___
> 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




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.

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

Re: [osg-users] Vanishing letters in osg::Text

[Volckaert, Guy (CA - MTS)]

Hi,

I'm using OSG v3.4.0 and I resolved this issue by adding a glTexParameteri( 
GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER,...) before calling glTexSubImage2D() in 
glyph.cpp. This problem was occurring if I was using an Intel video driver.

void Glyph::subload() const
{
[...]

// MTSI_BEGIN
// This line was added to resolve a problem with intel chipsets. In 
essence, some of the
// numeric glyphs would not display correctly. They would appear grey or 
transparent.
if( getTexture() )
{
glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, 
getTexture()->getFilter( osg::Texture::MIN_FILTER ) );
}
// MTSI_END

glTexSubImage2D(GL_TEXTURE_2D,0,
_texturePosX,_texturePosY,
s(),t(),
(GLenum)getPixelFormat(),
(GLenum)getDataType(),
data());
[...]
}

void GlyphTexture::apply(osg::State& state) const
{
[...]
// MTSI_BEGIN
// This line was added to resolve a problem with intel chipsets. In 
essence, some of the
// numeric glyphs would not display correctly. They would appear 
grey or transparent.
glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, _min_filter);
// MTSI_END
// Subload the image once
glTexSubImage2D( GL_TEXTURE_2D, 0, 0, 0,
getTextureWidth(),
getTextureHeight(),
OSGTEXT_GLYPH_FORMAT, GL_UNSIGNED_BYTE, local_data);
[...]
}

Regards,

-Original Message-
From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Tim Hartter
Sent: April-25-17 7:29 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Vanishing letters in osg::Text

Setting OSG_TEXT_INCREMENTAL_SUBLOADING to off does not make a difference and 
YES it happens on Intel cards (not on Nvidia) (Win 7 OSG 3.4)

Maybe the patched OSG text works better...

Mit AquaMail Android
http://www.aqua-mail.com gesendet


Am 25. April 2017 10:18:21 vorm. schrieb Robert Osfield
:

> On 25 April 2017 at 06:34, Wouter Roos  wrote:
>> I've experienced a similar issue lately where we were running a
>> project on lower spec systems with only an integrated GPU. On those
>> systems the frame rate would not show properly, having the same issue
>> as described here, with some numbers not showing properly.
>> I did a test on my laptop, and when I force it to use the integrated
>> GPU
>> (4600) the problems shows up as well. If I switch to use the GTX970M
>> everything is fine again. This is all on Windows 10, osg 3.4.0 I
>> haven't done any further investigation as the project is not using
>> any Text objects, but maybe this might help somehow.
>
> Some hardware/drivers don't support texture sub-loading correctly so
> the osgText subloading of new glyphs could cause problems, perhaps
> this is what you are seeing.  It's problem that originally occurred on
> Radeon's and some SGI hardware so there is a workaround in osgText
> that detects these combinations in drivers, you can also enable the
> workaround by setting the env var OSG_TEXT_INCREMENTAL_SUBLOADING to
> OFF i.e. under bash you'd do:
>
>   export OSG_TEXT_INCREMENTAL_SUBLOADING=OFF
>   osgtext
>
> Under windows I think it's something like:
>
>   set OSG_TEXT_INCREMENTAL_SUBLOADING=OFF
>   osgtext
>
> The OSG master version has a had a major rewrite of osgText so it no
> longer uses the texture subloading as may well just work out of the
> box on the Intel GPU/drivers that you have.
>
> 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




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.

___
osg-users mailing list
osg-users@lists.openscenegraph.org