Re: [osg-users] VAO Resource Leak in OSG 3.6.2
Julien, Yo may want to verify if you have CACHE_NODES enabled. If so, then you may think there's a resource leak but in fact the scene graph leading to your Geometry may be cached by OSG. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=74511#74511 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VAO Resource Leak in OSG 3.6.2
Just to clarify that my suggestion to change the Drawable's desructor is only if there is indeed a GL object resource leak, which I'm not totally convinced yet (by reviewing the code). -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=74499#74499 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VAO Resource Leak in OSG 3.6.2
I suggest that we remove Geometry::dirtyGLObjects() as it does nothing other
than call its base class, i.e. Drawable::dirtyGLObjects().
Code:
void Geometry::dirtyGLObjects()
{
Drawable::dirtyGLObjects();
}
I also noticed that the Drawable's destructor is calling a virtual function
which is never a good idea, i.e. it's calling dirtyGLObjects(). I also suggest
changing the dirtyGLObjects() to NOT BE virtual.
Code:
Drawable::~Drawable()
{
dirtyGLObjects();// WARNING: Not a good idea to call a virtual function
within a destructor.
}
Although Julien Valentin suggested changing the Geometry's destructor with
respect resolving the Gl object resource leak, I wonder if it would not be
better to move that code to the Drawable's destructor. Here is my suggestion
instead:
Code:
void Drawable::~Drawable()
{
unsigned int i;
#ifdef OSG_GL_DISPLAYLISTS_AVAILABLE
for(i=0;i<_globjList.size();++i)
{
if (_globjList[i] != 0)
{
Drawable::deleteDisplayList(i,_globjList[i], getGLObjectSizeHint());
_globjList[i] = 0;
}
}
#endif
[color=red]for(i=0; i<_vertexArrayStateList.size(); ++i)
{
VertexArrayState* vas = _vertexArrayStateList[i].get();
if (vas) vas->release();
}[/color]
}
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=74498#74498
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VAO Resource Leak in OSG 3.6.2
Got it. It's not necessarily a memory but a resource leak. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=74497#74497 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VAO Resource Leak in OSG 3.6.2
I'm a little confused. Is there or is there not a memory leak? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=74494#74494 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OpenThreads Mutex::lock() crash
Hi,
Has anyone experienced issues with OpenThreads Mutext::lock()? Occasionally a
crash occurs when starting my application but only if the threading model is
not SingleThreaded. The crash occurs in the following functions of OpenThreads:
Code:
int Mutex::lock() {
Win32MutexPrivateData *pd =
static_cast(_prvData);
#ifdef USE_CRITICAL_SECTION
// Block until we can take this lock.
EnterCriticalSection( &(pd->_cs) );
return 0;
#else
[...]
#endif
}
What I noticed is that sometimes "pd" is 0 eventhough "_prvData" is not 0!! I
can't understand how that can occur unless there's a concurency issue. As a
test, I added a sanity check after initializing the "pb" local variable, as
follows:
Code:
while( pd == 0 )
{
Sleep( 10 ); // sleep for 10ms and try again...
pd = static_cast(_prvData);
}
I know it's dumb... but it works. I've been chasing this problem for a long
time now and I haven't found a solution yet (except my dumb one).
This issue occurs with v3.4.0 and v3.6.2. The crash occurs on Win7 and Win10
when build with VS2013.
Any help on this topic would be much appreciated.
Thank you!
Cheers,
Guy
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=74333#74333
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] ViewerBase::setThreadingModel() not working
Actually, if we want to adjust the threading affinity when cycling through the threading model, then would`t be better to if we replaced: Code: if (isRealized() && _threadingModel!=SingleThreaded) startThreading(); by Code: if (isRealized() && _threadingModel!=SingleThreaded) setUpThreading(); Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=74330#74330 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] ViewerBase::setThreadingModel() not working
Hi, I also looked at the osg-submissions archives and could not find any trace of this change. I went back as far as June 2017. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=74329#74329 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] [build] ViewerBase::setThreadingModel() not working
Hi, I looked at the commit but the description does not clearly provide a reason for the change. I looked at the forum but could not find anything. I'll try the mailing list next. Thank you! Cheers, Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=74327#74327 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [build] ViewerBase::setThreadingModel() not working
Hi,
When I try to cycle through the threading models by pressing the 'm' key (when
the ThreadingHandler is registered) the stats would indicates the correct
threading model, but the engine would remain in SingleThreaded. So I started
investigating the issue and I noticed that, with OSG v3.6.2, the
ViewerBase::setThreadingModel() changed compared with v3.4.0. Below is a snipit
of function:
Code:
void ViewerBase::setThreadingModel(ThreadingModel threadingModel)
{
if (_threadingModel == threadingModel) return;
bool needSetUpThreading = _threadsRunning
if (_threadsRunning) stopThreading();
_threadingModel = threadingModel;
if (needSetUpThreading) setUpThreading();
}
If the current threading model is SingleThreaded then _threadsRunning will be
false which means that needSetUpThreading will also be false. Therefore,
setUpThreading() will never be called if we are in SingleThreaded.
Rolling back the function to v3.4.0 seems to resolve the problem, but I'm not
sure if that will cause other issues. There's obviously a reason why it was
changed. I would like someone with more experience that I to way in. Below is a
snipit of the rolled-back function.
Code:
void ViewerBase::setThreadingModel(ThreadingModel threadingModel)
{
if (_threadingModel == threadingModel) return;
if (_threadsRunning) stopThreading();
_threadingModel = threadingModel;
if (isRealized() && _threadingModel!=SingleThreaded) startThreading();
}
Regards,
Guy
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=74324#74324
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [build] Missing OpenThreads PDB when building INSTALL
Hi, This is not really a big issue, but I noticed that the OpenThreads PDB file is not copied to the INSTALL directory when building OSG v3.6.2 on Windows with VS2013. I looked at .\src\OpenThreads\win32\cmake_install.cmake and the lines required to copy the PDB are missings. Thanks, -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=74320#74320 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LineSegmentIntersector::intersect + performance
Excellent. I tested it and everything seems to work as expected. Thanks for the quick response. BTW: I'm also investigating a way to somehow "cache" the last drawable that we intersected with (terrain only). If this works, it could prove to be a significant performance gain in situations where we simulate ground vehicles or lifeforms (for example), since their speed is relatively slow and the probably of intersecting the same geometry at the next frame is very high. My objective is to try to intersect with the cached drawable first, and there's no intersection then fallback to intersecting the entire terrain. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=74198#74198 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] LineSegmentIntersector::intersect + performance
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
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<mailto:brian.bak...@meggitt.com>
url; www.meggitt.com<http://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
Re: [osg-users] [osgPlugins] [ive] Option "inlineExternalReferencesInIVEFile"
Although this is an old post, I recently noticed the same issue in v3.4.0. Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=7#7 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] ComputeBoundsVisitor does not consider Billboards
If I have a chance, I'll try to look at it as well based on your suggestion solution. Cheers, Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=72217#72217 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] ComputeBoundsVisitor does not consider Billboards
Hi, I'm having problem with the osg::ComputeBoundsVisitor and osg::Billboards. In essence, the osg::ComputeBoundsVisitor does not consider the pivot position of the facing billboard. For example, let say I have a simple model that contains a single facing quad billboard (like a tree) located at (20, 20, 0) with a dimension of (10, 0, 10). I would expect the osg::ComputeBoundsVisitor to calculate a scene bounding box of min(15, 20, 0) max(25, 20, 10). However, what I seem to get instead is min(-5, 0, 0 ) max( 5, 0, 10 ). My investigation led me to review osg::ComputeBoundsVisitor and I found that it does not consider billboards - i.e. the osg::ComputeBoundsVisitor::apply(osg::Billboard& billboard) is missing. In effect, the osg::ComputeBoundsVisitor does not consider the pivot position stored in osg::Billboard::_positionList. Is this design intentional? If not, then how would you propose fixing this issue? Thank you! Cheers, Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=72214#72214 ___ 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
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<mailto:brian.bak...@meggitt.com>
url; www.meggitt.com<http://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
Re: [osg-users] OSG crash on startup
Understood. I compared the Config file used for building OSG and the one that is copied by the INSTALL project, which is used by my app, and they are both the same. Below is the content of my OpenThreads\Config header file. Code: #ifndef _OPENTHREADS_CONFIG #define _OPENTHREADS_CONFIG /* #undef _OPENTHREADS_ATOMIC_USE_GCC_BUILTINS */ /* #undef _OPENTHREADS_ATOMIC_USE_MIPOSPRO_BUILTINS */ /* #undef _OPENTHREADS_ATOMIC_USE_SUN */ #define _OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED /* #undef _OPENTHREADS_ATOMIC_USE_BSD_ATOMIC */ /* #undef _OPENTHREADS_ATOMIC_USE_MUTEX */ /* #undef OT_LIBRARY_STATIC */ #endif Thank you! Cheers, Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=70899#70899 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Optimizer::RemoveLoadedProxyNodesVisitor + NO_AUTOMATIC_LOADING
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 <guy.volcka...@meggitt.com> 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
[osg-users] Optimizer::RemoveLoadedProxyNodesVisitor + NO_AUTOMATIC_LOADING
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] OSG crash on startup
Hi,
I was wondering if anyone observed a similar problems. In essence, we recently
upgrade from v2.8.2 to 3.4.0 and we are now noticing random crashed when
launching many of our applications. Note that we also upgraded from VS2005 to
VS2013, so technically it can also be a compiler issue as well. Hopefully you
guys can guide me a little towards where to investigate;)
I’ve been able to isolate the crash in Win32Mutex.cpp, the lock() and unlock()
functions:
Code:
Mutex::Mutex(MutexType type):
_mutexType(type)
{
Win32MutexPrivateData *pd = new Win32MutexPrivateData();
_prvData = static_cast(pd);
}
int Mutex::lock() {
Win32MutexPrivateData *pd =
static_cast<Win32MutexPrivateData*>(_prvData);
[b]if(!pd) return 0; /// ADDED THIS SANITY CHECK[/b]
#ifdef USE_CRITICAL_SECTION
// Block until we can take this lock.
EnterCriticalSection( &(pd->_cs) );
return 0;
#else
[…]
#endif // USE_CRITICAL_SECTION
}
In essence, from time to time the pointer would be NULL even though
<_prvData> is not, causing a crash when calling EnterCriticalSection(). I
suspect that maybe there a racing condition when creating the internal threads.
Adding if(!pd) return 0; seems to resolve the problem, albeit not a perfect
solution.
Any ideas would be appreciated.
Thank you!
Cheers,
Guy
Code:
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=70842#70842
___
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
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
[osg-users] My first OSG application
Hi, I a newbee with OpenSceneGraph, Trying to write a really simple app doing the following: a single window is divided to 2: one part has a model that is rendered from different views according to mouse events (click,drag,...) The second part has simply an image. I really got lost with the variety of examples and tools. can someone give me some guidlines for this task?(what classes to use, maybe a similar example available in the database) ... Thank you! Cheers, Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61800#61800 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Quad Buffer Stereo in osgViewer::CompositeViewer
Hi, Just a note to say this is now completely resolved. It was my fault, the stereo failed in my application because I was setting up the display settings of the 3D view after adding it to the composite viewer. Anyone who is trying to get something similar to work please beware: The order of operations in setting up composite views matters A LOT. The issues with enabling the active stereo on my Stereo Monitor were resolved by setting the Select when the display is in 3D mode: option to Always in the Nvidia control panel. Thanks again for the help! ... Cheers, Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61413#61413 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Quad Buffer Stereo in osgViewer::CompositeViewer
Hi, I've been struggling with this for over a week now, its really blocking progress on my project. Basically, I can't seem to get quad buffer stereo working in any sort of compositeviewer. For what its worth, both the osgcompositeviewer example and my own application show the same error : Warning: detected OpenGL error 'invalid operation' at after RenderBin::draw(..) ..and refuse to show anything other than a mono view. I get the same issue on both my builds: a MinGW Windows 7 build and a gcc build on Arch Linux. My OpenSceneGraph is built from source in both cases using the latest revision in trunk (14459) Finally all other stereo modes seem to work in all cases, on both builds. I've been trying to track the problem down using a debugger without any luck. I'm going to try and debug the GL calls next, but was wondering if anyone else had experienced anything similar. ... Thank you! Cheers, Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61366#61366 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Quad Buffer Stereo in osgViewer::CompositeViewer
Hi Robert, Many thanks for the quick response. I'm currently testing on an Nvidia Quadro 600 on windows with drivers I've just updated. I've enabled stereo on the control panel and I have seen other applications (and the demo) working fine. The linux build is on a virtual machine.. so I would not expect stereo to actually 'work' with that.. but I'd at least expect to see the usual flickery ghosting of frame sequential output. Just an added additional note: the osgviewer application 'looks' like its rendering frame sequential - but does't seem to trigger my nView stereo monitor. Again, osgcompositeviewer shows no signs of quad buffer output at all. Hope this helps. Guy ... Thank you! Cheers, Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61390#61390 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Quad Buffer Stereo in osgViewer::CompositeViewer
Hi, OK, I've made some progress. osgcompositeviewer seems to be producing frame sequential output as expected when I use the -2 flag to full screen it. The problem with the default settings was that the WSI graphics context wasn't getting initialised with stereo enabled. Still not playing nice will nView.. but its definitely progress. ... Thank you! Cheers, Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61391#61391 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] [ANN] iOS Developer with OSG experience needed!
Hello dear OSG-community, Hi all, I don't mean to tread on toes, perhaps this will be of interest to one of you, or someone you know. I'm finding it very hard to find a candidate with OSG knowledge! Job spec below: iOS Developer Our client, based in Central London is urgently looking for a skilled iOS Developer to assist in a project currently set to last for a month. A relatively new, yet established and exciting Digital Agency, there are big opportunities for extended work. The ideal candidate will need: • Expertise in iOS Development • Have 1+ years’ experience in Objective-C programming • Experience with OSG Toolkit • A gaming background With a knowledge of: • ARToolkit • 3ds Max • Open GL You will also be available for work ASAP. If you are interested, please contact me immediately with a CV! :) Thank you! Best regards, Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=46356#46356 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] animation from one projection type to the other one
Hello Gianluca, I think, and I'm not exactly sure about it that if the matrix W component (4th column) is zero, then the computation works with the 3x3 matrix. When it is different than zero, it uses it as 4x4 matrix. Now supposed that startProj or endProj has in the 4th column zero, and the other one has something different than zero, then all the animation matrices will be 4x4 but the first or the last, and therefore the reason on the discontinuity. Check if that happens for any N and check if both matrices are 4x4 or 3x3. If one of them is 3x3 than set it's 4th component to one. From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Gianluca Natale Sent: Wednesday, February 29, 2012 7:16 PM To: Osg Users Subject: [osg-users] animation from one projection type to the other one Hi all, I'm trying to implement an animation from a perspective projection to an orthographic one. What I'm computing at each step is a weighted linear combination of 2 projection matrices (the start, that refers to a perspective projection, and the end, which is an orthographic projection). So, supposing the whole animation in N steps, at step n my projection matrix is defined by: Proj(n) = startProjMat * (1 - n/N) + endProjMat * n/N. The animation looks fine, but in the last step there is a noticeable jump on the screen. What did I go wrong? Is there any unpredictable or invalid result in the linear combination I computed, or is it a well defined projection matrix? Thanks Gianluca ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] window position and size
you caj also use the environment variable OSG_WINDOW, e.g.: set OSG_WINDOW = 40 40 640 480 Note: space delimited. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=44341#44341 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] protecting files and assets in osga Archive
I think that the first approach of creating your own file stream for encryption is an excellent one, but there is a problem (I think). What would happen if the stream's seekg()/seekp() is called. For example, if you wanted to seek to the end of the file, you would need to decrypt the entire file... you couldn't just jump to the end. I guess that's do-able, but would be much longer. Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35671#35671 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Clearing window client area.
Now I understand! That makes perfect sense to me now. I tried calling GraphicContext::setClearMask(GL_COLOR_BUFFER_BIT) in my app and now it works as expected. Thanks... your the best. Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=35663#35663 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Clearing window client area.
Hi,
I have a stituation where the viewport is smaller than the windows, causing the
region outside the viewport to not be cleared properly. Does anyone know how to
clear the background window?
I tied several things including the following:
Code:
void ClearClientBackground( HWND hWnd )
{
RECT oRect;
PAINTSTRUCT oPs;
GetUpdateRect( hWnd, oRect, FALSE );
if( IsRectEmpty( oRect ) )
{
GetClientRect( hWnd, oRect );
}
BeginPaint( hWnd, oPs );
BOOL bRet = BitBlt( oPs.hdc, oRect.left, oRect.top, oRect.right -
oRect.left, oRect.bottom - oRect.top,
NULL, oRect.left, oRect.top, BLACKNESS );
EndPaint( hWnd, oPs );
}
I would appreciate it if someone can tell me how to clear the area window that
is outside the viewport area.
Thanks,
Guy
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=35657#35657
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Clearing window client area.
I guess I could have been a little clearer in my description. So here's an
example that should help:
1) I have a osg::camera of size 640x480. So the window's client area is
640x480, or GraphicsContext::Trats::(x,y,width,height) = (0, 0, 640, 480).
2) The GL viewport of this camera is 320x240, i.e osg::Camera::setViewport(0,
0, 320, 240).
3) When I render the scene, the windows area outside the GL viewport is not
cleared.
Note that I set the osg::Camera::setClearMask(GL_COLOR_BUFFER_BIT |
GL_DEPTH_BUFFER_BIT);
I found that context should be clear via the following function:
Code:
void SwapBuffersOperation::operator () (GraphicsContext* context)
{
context-swapBuffersImplementation();
context-clear();
}
But for some reason, it doesn't. I'll try to modify one of the examples and see
if the problem occurs as well.
Guy
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=35659#35659
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Graphic Context + Texture Memory
Thanks for all your replies. That confirms what I imagined. I forgot to mention that in addition of requiring multiple cameras, we also need multiple windows. Each window presents a different view of the scene. Because of the complexity of the scene I wanted to gain a little performance by using multiple draw threads, but I guess I will have to choose between performance gain (i.e multi-threaded) and memory consumption (i.e single-threaded). I will perform a few tests to see which is best suited for my situation. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34488#34488 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Graphic Context + Texture Memory
I have a newby question to ask... so please be gentil Let's say I have 2 cameras running in different draw threads. Each camera is also associated with a different graphic context. If I load a 2D texture then each context will have its own opengl texture object (created in the Texture2D::Apply() function). So far so good... My question is: will the opengl driver have 2 instance of the texture object in memory and therefore occuping twice the amount necessary? Or is the driver smart enough to somehow share the same memory space for both instances? I guess the answer is that each texture is represented in each graphic context by a different opengl texture object, and thus will occupy N times the required memory space, where N is the number of graphic context. Am I understanding this right? Regards, -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=34460#34460 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] BMP plugin (suggested change)
Hi,
I noticed that the alpha component in the BMP file (when RGBA or BGRA) is not
being preserved in the image. I would like to proposed the following small
change to correct this problem. Instead of ignoring the alpha component, I
first check if the bytesPerPixel == 4 bytes. If so, then I simply copy the row
alpha to the image alpha component.
Does that make sense? Or am I not following the BMP standard?
Code:
if (dib.bitsPerPixel = 16)
{
unsigned char* imgp = imageBuffer;
for (int i = 0; i dib.height; ++i)
{
// read row
unsigned char* rowp = *rowBuffer.begin();
fin.read((char*) rowp, rowBuffer.size());
// copy to image buffer, swap/unpack BGR to RGB(A)
for (unsigned int j = 0; j bytesPerRow; j += bytesPerPixel)
{
if (dib.bitsPerPixel == 16)
{
// 16-bit RGB - 24-bit RGB
unsigned short rgb16 = (rowp[1] 8) | rowp[0];
if (swap)
osg::swapBytes2((char*) rgb16);
imgp[0] = (rgb16 redMask) redShift;
imgp[1] = (rgb16 greenMask) greenShift;
imgp[2] = (rgb16 blueMask) blueShift;
// expand range
imgp[0] = (8-redMaskWidth);
imgp[1] = (8-greenMaskWidth);
imgp[2] = (8-blueMaskWidth);
}
else
{
// BGR - RGB(A)
imgp[0] = rowp[2];
imgp[1] = rowp[1];
imgp[2] = rowp[0];
if (imageBytesPerPixel == 4)
{
// * THIS IS MY CHANGE***
if( bytesPerPixel == 4 )
{
imgp[3] = rowp[3];
}
else
{
imgp[3] = 0xFF;
}
}
}
imgp += imageBytesPerPixel;
rowp += bytesPerPixel;
}
}
}
Regards,
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=34271#34271
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DatabasePager and CompileContext
Here is my system configuration: Laptop XPS M1730 Windows 7 4 GB RAM NVidia 8800M GTX, 512 MB NVidia Driver v257.71 I hope this help. I've spent all weekend trying to deciphere what's going on. Still don't know why it's not working. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31825#31825 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DatabasePager and TextureObjects
Sorry for the confusion - I ment to say the SharedStateManager. I should have mentioned (in my original post) that I already merged the SharedStateManager from the trunk into v2.8.2. Fortunately, the changes were easy to merge but did not resolve the problem. I'm trying to figure out a way to determine what's the difference between loading the FLT model myself using readNode() and loading it through the DatabasePager. In both cases, I run the SharedStateManager process and the optimizer process (via the readNode callback). I will continue isolating the problem, but not sure how far I can go. Regards, -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31832#31832 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DatabasePager and CompileContext
Yes. Everything works when I don't use the compile context (i.e the scene is rendered correctly), except that I still detect a problem with the number of texture objects when using the database pager. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31835#31835 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] DatabasePager and CompileContext
Hi, I think there are a few problems with compiling GL objects with the DatabasePager (in OSG 2.8.2). The following topic sums it up pretty well: http://forum.openscenegraph.org/viewtopic.php?t=1032start=0postdays=0postorder=aschighlight=compilecontext So far, I was able to compile all the GL object from a compile context (by calling DisplaySettings::setCompileContextsHint(true)). However, my scene appears all white. It seems that the texture objects are not created, or are created but invalid from the rendering context. Any ideas? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31804#31804 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DatabasePager and CompileContext
I noticed a huge discrepency between loading an FLT with and without the DatabasePager. Before loading any database model, the number of TextureObject created is 16. When I load a model via readNode(), the number of TextureObjects created increases to 112 (for 96 textures objects for the model itself). However, when I load the same model from within the DatabasePager thread, then I get 173 TexureObjects created (157 TextureObjects for the model itself). Essentially, I noticed that loading tiles from within the DatabasePager requires lots more texture memory (confirmed by using glDebugger). Note: The StateSetManager is used the in the same manner for both cases. Any ideas? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31806#31806 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] DatabasePager and TextureObjects
I noticed a huge discrepency between loading an FLT with and without the DatabasePager. Before loading any database model, the number of TextureObject created is 16. When I load a model via readNode(), the number of TextureObjects created increases to 112 (for 96 textures objects for the model itself). However, when I load the same model from within the DatabasePager thread, then I get 173 TexureObjects created (157 TextureObjects for the model itself). Essentially, I noticed that loading tiles from within the DatabasePager requires lots more texture memory (confirmed by using glDebugger). Note: The StateSetManager is used the in the same manner for both cases. Any ideas? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31807#31807 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Why SharedStateManager::share() from main thread?
I've been looking activating the SharedStateManager within the DatabasePager and I was curious to know why the share() function is called from within the main thread (i.e in DatabasePager::addLoadedDataToSceneGraph()) as opposed to the DatabasePager thread (like the GL compile post-process). I would suspect that doing this work in the main thread would cause frame hickups, right? Regards, -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31654#31654 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Why SharedStateManager::share() from main thread?
After thinking about it, shouldn't the share() function be called before the compile GL objects process which is invoked from the DatabasePager thread. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=31655#31655 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] ModelView and Projection Matrices
Hi all, I'm encountering an inconsistency between OpenGL vertex manipulation and OSG. It is almost sure that it's my own misuse of OSG so I will present the issue and be glad to learn. J I'm trying to force a point in orthographic projection to have a specific z value. Suppose z = 0.95 I know the world point is (xw,yw,zw) So I calculate near/far planes in orthographic projection to be [0, zw/z] Then I create the projection matrix to be osg::Matrix new_proj = osg::Matrix::ortho(-(width*0.5),width*0.5,-(height*0.5),height*0.5, 0, zw/z); osg::Matrix new_view = osg::Matrix::identity(); The model view matrix is identity. Now, I create a dummy vertex to check the projection: osg::Vec3 pt(0,0,zw/z); osg::Vec3 s = new_proj.preMult(new_view .preMult(pt)); I would expect s.z() to be 1 or a smaller number but very very close to one. What I get is 3. (width x height are 160x120. zw = 800) When I use the utility function double x,y,z; int success = gluProject(pt.x(), pt.y(), pt.z(),new_view.ptr(), new_proj.ptr(), vp, x, y, z); z is very close to 1 (0.9997...) as was expected. Can anyone explain? Thanks, Guy L. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] SE Core Paging Terrain Tiles
Hi, Is there a plugin (or mechanism) that would allow me to load SE Core DVED terrain databases which contains many pageable tiles but there's no master file (see https://www.se-core.org/Default.aspx?tabid=175). Here is an example of an SE Core DVED terrain database directory structure: .\MyTerrain\terrain\ - this folder contains all the FLT tiles using the filename format tile_x_y.flt, where x is the row index of the tile, and y is the column index of the tile. Unlike TerraPage format, the SE Core file does not contain a master file. However, it seems that each tile in the folder has the same width/depth dimensions. .\MyTerrain\externals\ - this folder contains all the external FLT references. .\MyTerrain\textures\ - thid folder contains all the textures. I looked at how the TXP plugin works and I was about to create my own SECorePagedNode class (similar to TxpNode class) but I was wondering if OSG ca already handle these types of databases. If so, then please let me know. Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=30151#30151 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] txp::TXPNode coordinate system
While analyzing the TXNode class, I noticed that it makes a suttle assumption
that the coordinate system is Z up. Almost everyhere else in OSG it make no
such assumption (or it provides a CoordinateFrame class to convert from one
coordinate system to another such as from Z up to Y up).
Here is a small code snipit of TxpNode:
Code:
void TXPNode::updateEye(osg::NodeVisitor nv)
{
[...]
// This code assumes Z up.
trpg2dPoint loc;
loc.x = nv.getEyePoint().x() - _originX;
loc.y = nv.getEyePoint().y() - _originY;
[...]
}
Is there an easy to make this work with other coordinate systems (like Y up).
Cheers,
Guy
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=30152#30152
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] DatabasePager Callback
I am aware of the ReadFileCallback - but I guess the problem is how to distinguish between my paging terrain files from other database files loaded during runtime. All my files are FLTs (with the exception of a few TXP files for the terrain). I can't use the file extension as a filter since they are all the same (i.e *.flt). Keep the ideas comming... it's all good. Regards, -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=29872#29872 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] DatabasePager Callback
Hi, Is there a mechanism that would allow me to get notified when a subgraph gets loaded by the DatabasePager. I essentially need to process the subgraph before it gets added to scene. I guess this would be valid for TXPNode and PagedLOD nodes as well? Thanks, -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=29851#29851 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] TXP Extents/BoundingBox
Hi, The ComputeBoundVisitor does not seem to support TXPNode nodes. Is there another way of getting the boundingbox (not the boundingsphere) of a TXP database? I know that the TXPNode contains the extents of the terrain (which is what I want) but the interface is not exposed to the osg lib - only the txp plugin. So the question is how I get access to the interface without linking in the plugin lib? Regards, -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=29852#29852 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Windows 7 Aero Color Scheme issue
I'm having the same problem on my laptop (single screen). When I launch the osgViewer application, the screen gets rendered for 1 frame and then the entire window becomes black. If I use ALT-TAB to cycle back and forth, then the scene gets rendered correctly. As you mentioned, it's very irritating. I was wondering if anyone looked into this since? Cheers, Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=29807#29807 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OpenFlight meshing problem
I'm hoping that someone can help me with a weird problem I'm having with an
openflight terrain I have.
It seems that when I mesh my terrain (with Multigen Creator 2.5.1) I can't see
it anyore. Note that the problem only occurs when I disable lighting (i.e
GL_LIGHTING). However, when I un-mesh the terrain (seperate faces) then it
works correctly, regarless of the lighting state.
I converted the *.FLT to *.OSG so that I can look at the different between the
meshed and un-meshed version. What I discovered was that the color array in the
meshed version contained invalid RGBA components - they do not correspond to
the color set within Creator. The color should be (1,1,1,1) but I'm getting
(1,0,1,0). So it's normal that I don't see the terrain because the alpha is 0.
The green component also 0, which I can't understand as well.
For example:
Code:
ColorBinding PER_VERTEX
ColorArray Vec4Array 9
{
1 0 1 0
1 0 1 0
1 0 1 0
1 0 1 0
1 0 1 0
1 0 1 0
1 0 1 0
1 0 1 0
1 0 1 0
}
The reason why I want to use the meshed version of the terrain is to improve
rendering performance.
We've isolated the problem in the LocalVertexPool::readRecord() function in the
openflight plugin. It seems that the alphaIndex value extracted from the FLT
is incorrect (see snipit below).
Code:
virtual void readRecord(RecordInputStream in, Document document)
{
[...]
if (mask HAS_COLOR_INDEX)
{
uint32 alphaIndex = in.readUInt32(); [b]// Bad
alphaIndex.[/b]
int index = alphaIndex 0x00ff;
uint8 alpha = alphaIndex 24;
osg::Vec4 color = document.getColorPool()-getColor(index);
color.a() = (float)alpha/255;
vertex.setColor(color);
if (!color.valid())
{
osg::notify(osg::NOTICE)Warning: data error detected in
LocalVertexPool::readRecord color=color.r() color.g()
color.b() color.a()std::endl;
}
}
[...]
}
Obviously, the meshed FLT file could ne invalid, right? So I used a different
application (an old 3D Explorer app) to load the meshed version and it works
correctly.
I can't exaplin it.
I've attached a snipit of the terrain for you to look at. It contains the
following files:
.\gr01.rgb
.\gr01.rgb .attr
.\small_faces.flt : unmeshed version
.\small_faces.osg
.\small_mesh.flt : meshed version
.\small_mesh.osg
Can anyone shed some light of this problem?
Cheers,
Guy
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=25823#25823
Attachments:
http://forum.openscenegraph.org//files/smallflt_129.zip
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Precipitation and VBO
As promised, I modified the osgprerender example to include a single instance of the precipitation effect and I was able to reproduce the problem. Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25686#25686 Attachments: http://forum.openscenegraph.org//files/osgprerender_175.cpp ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Precipitation and VBO
I will modify the precipitation example to include a render-target implementation and see if I can reproduce the problem. If I am successful, I will post the example on the forum so that someone can review the implementation. Like you said Rob, I may have a bad setup and I just don't know it. Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25612#25612 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Help: how to rotate view camera 90 degrees in relationship to terrain
Is your viewing camera also using the local coordinate system (i.e geocentric)? Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25621#25621 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] LOD support
If I recall correctly, even the osgParticle supports LODs, but I think they are called details instead (or something rather). However, osg does not implicitely use it - you need to manage the details yourself. Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25622#25622 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Precipitation and VBO
Hi, I am experiencing VERY bad performance (i.e 1 FPS) when I enable precipitation on my Dell laptop (XPS 1710) that uses a GeForce 7950 graphic card (dell driver version 179.xx). But here's the kicker... the performance is fine when running on any other desktop systems that has a more recent graphic card (for example a 8800 GTX). I kinda understand that it would run faster, but never expecte a drop to 1 FPS on a 7950, especially when there is ABSOLUTELY nothing in the scene. I've reduced my application to the bare minimum to isolate the problem. All I have in my scene graph is a pre- post- camera used to render my scene to a texture (using the render-target-implememtation functions of the osg::camera), and an instance of precipitation effect. I tried using different render-target-implementation technique (like FRAME_BUFFER) but that did not change anything. If I bypass the render-target-implementation (i.e I bypass the osg::camera::attach() method), keep the pre-camera, and remove the post-camera, then everything work fine (running at 60fps). Can someone shed some light on why the the render-target-implementation would affect osg::PrecipitationEffect (or vice-versa). Note: The problem is not the precipitation effect because I compared my implementation with the osg precipitation example and they are the same. When I run the example the frame rate is 60fps (which is the same as my app when I bypass the rendet to target). Cheers, Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=25603#25603 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] automatic pixel transparency adjustment
Hi, thanks, I've just read that SMOOTH isn't supported since several years ago. It is important since this is physically correct that even objects which are very small, does contribute to the pixel color. Is it possible to calculate the pixel coverage or get it in a shader? That would be a good solution. Does anyone know how Multi-sampling is implemented algorithmically? Thanks, Guy. From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Michael Platings Sent: Tuesday, March 09, 2010 5:09 PM To: OpenSceneGraph Users Subject: Re: [osg-users] automatic pixel transparency adjustment Hi Guy, the behaviour of multisampling is quite well defined - the more samples you request, the more accurate the render will be. Yes, objects smaller than a pixel may not be rendered. Why is that a problem for you? The behaviour of smooth rendering is not well defined. It's a hint to the OpenGL implementation, nothing more. To find out how it behaves on a particular graphics card you'll have to experiment. On 9 March 2010 14:32, Guy g...@dvp.co.il wrote: Hi all, Thanks again for your answers, I've read about Multi-sampling, SMOOTH rendering and centroid variables. It all helped a lot. I've few questions regarding these issues that were not clear: With multisampling: - if none of the samples falls within the intersection of the object and the pixel, than nothing will be rendered? Does it mean that tiny objects will disappear? - multi-sampling can never be accurate, right? I mean almost never can set the object alpha to the object pixel coverage percentange? With SMOOTH rendering: - is it more accurate than multisampling? Is it possible that OpenGL implementation will not calculate the pixel coverage correctly? - Does it works slower or faster than multisampling? - Will it work even for tiny objects? Thanks, Guy. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] automatic pixel transparency adjustment
Hi all, Thanks again for your answers, I've read about Multi-sampling, SMOOTH rendering and centroid variables. It all helped a lot. I've few questions regarding these issues that were not clear: With multisampling: - if none of the samples falls within the intersection of the object and the pixel, than nothing will be rendered? Does it mean that tiny objects will disappear? - multi-sampling can never be accurate, right? I mean almost never can set the object alpha to the object pixel coverage percentange? With SMOOTH rendering: - is it more accurate than multisampling? Is it possible that OpenGL implementation will not calculate the pixel coverage correctly? - Does it works slower or faster than multisampling? - Will it work even for tiny objects? Thanks, Guy. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] automatic pixel transparency adjustment
You are right. The only way to solve it completely in my opinion is ray tracing. However, according to OpenGL spec, the smooth implementation should calculate the coverage percentage to the pixels of the edge of the object, that means that if the situation you described occurs for two polygons of the same object, the effect you described won't happen. Only if two different objects edges falls in the same pixel and are not overlapping it will happen. Thanks anyway, Guy. From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Michael Platings Sent: Tuesday, March 09, 2010 7:01 PM To: OpenSceneGraph Users Subject: Re: [osg-users] automatic pixel transparency adjustment If physically correct is what you need then OpenGL probably isn't what you want. In general, OpenGL is suitable for rendering something that looks pretty good, FAST. I don't know of any way to get fragment coverage in a shader. However, even if you could that wouldn't be adequate: Imagine you have a white (255) square on a black (0) background. You size the square so that it precisely covers one pixel. When you render it, the pixel is coloured white (255). Now imagine you divide that white square in half. You would expect that rendering the two halves would also get you a value of 255, but... When you render the first half, the pixel is 255 * 0.5 + 0 * (1 - 0.5) = 127. When you render the second half the pixel is 255 * 0.5 + 127 * (1 - 0.5) = 191. NOT 255! Therefore, multiplying alpha by coverage wouldn't work unless you're only dealing with separate polygons, which isn't the case most of the time. HTH ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] automatic pixel transparency adjustment
This is the current solution we implemented in our group. I was looking for a more accurate solution that will also work for the whole scene, but the problem Michael Platins indicated holds. The accurate solution would to give each object's pixel, alpha that corresponds to its coverage, but the destination alpha shouldn't be 1-SRC_ALPHA but 1-(area percentage of destination object covered by source object). To calculate these areas intersection seems complex solution... Guy. From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Chuck Seberino Sent: Tuesday, March 09, 2010 8:52 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] automatic pixel transparency adjustment Guy, One option that I have used in the past is to use super-sampling. You would render your scene at a higher resolution, and then perform any variation of averaging or weighting you want as you scale it down to the final size. This will help to make sure sub-pixel objects contribute to the final rendered image. One of my previous implementations just rendered a specific node geometry by itself at a high resolution and then scaled/blended it in with the rest of the scene. HTH Chuck On 9 March 2010 14:32, Guy g...@dvp.co.il wrote: Hi, thanks, I've just read that SMOOTH isn't supported since several years ago. It is important since this is physically correct that even objects which are very small, does contribute to the pixel color. Is it possible to calculate the pixel coverage or get it in a shader? That would be a good solution. Does anyone know how Multi-sampling is implemented algorithmically? Thanks, Guy. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] automatic pixel transparency adjustment
Hmm... I guess I'll have to read about the full screen antialiasing algorithm then. :-) Thanks. From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Robert Osfield Sent: Thursday, March 04, 2010 11:03 AM To: OpenSceneGraph Users Subject: Re: [osg-users] automatic pixel transparency adjustment Hi Guy, I can't help but feel what you are asking for is full screen anti-aliasing... Robert. On Thu, Mar 4, 2010 at 4:43 AM, Guy g...@dvp.co.il wrote: Hi all, I need OpenGL/driver/fixed-pipeline/whatever I don't need to code, to do the following thing: When rasterizing an object, first never ignore any pixel the object is projected on (even if the area the object consume in that pixels is tiny). Second multiply the object transparency by the percents the object occupies in that pixel. Is it possible? How can I achieve that? Suppose I can achieve it (maybe with OpenGL3.0, or special flags for previous versions that prevent openGL from discarding pixels that the object occupies less than some threshold on that pixel), does it mean all the objects should be sent to the transparent bin and have blending enabled? What amount of performance impact should I expect? If it is a major impact, do you have any other idea to achieve this effect for objects edges and for objects that are smaller than one pixel? Btw, this is not because I'm crazy, this process is closer to the physical process that happens with camera and therefore more accurate. Thanks, Guy. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] automatic pixel transparency adjustment
Thanks, I'll look into it. From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Wojciech Lewandowski Sent: Thursday, March 04, 2010 12:42 PM To: OpenSceneGraph Users Subject: Re: [osg-users] automatic pixel transparency adjustment Hi Guy, If classic multisample antialiasing does not work for you, have a look at centroid modified in GLSL ver 1.2 and upr. See this link for example: http://www.opengl.org/pipeline/article/vol003_6/ Wojtek Lewandowski - Original Message - From: Robert Osfield mailto:robert.osfi...@gmail.com To: OpenSceneGraph Users mailto:osg-users@lists.openscenegraph.org Sent: Thursday, March 04, 2010 10:03 AM Subject: Re: [osg-users] automatic pixel transparency adjustment Hi Guy, I can't help but feel what you are asking for is full screen anti-aliasing... Robert. On Thu, Mar 4, 2010 at 4:43 AM, Guy g...@dvp.co.il wrote: Hi all, I need OpenGL/driver/fixed-pipeline/whatever I don't need to code, to do the following thing: When rasterizing an object, first never ignore any pixel the object is projected on (even if the area the object consume in that pixels is tiny). Second multiply the object transparency by the percents the object occupies in that pixel. Is it possible? How can I achieve that? Suppose I can achieve it (maybe with OpenGL3.0, or special flags for previous versions that prevent openGL from discarding pixels that the object occupies less than some threshold on that pixel), does it mean all the objects should be sent to the transparent bin and have blending enabled? What amount of performance impact should I expect? If it is a major impact, do you have any other idea to achieve this effect for objects edges and for objects that are smaller than one pixel? Btw, this is not because I'm crazy, this process is closer to the physical process that happens with camera and therefore more accurate. Thanks, Guy. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] automatic pixel transparency adjustment
Thanks. From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Michael Platings Sent: Thursday, March 04, 2010 12:57 PM To: OpenSceneGraph Users Subject: Re: [osg-users] automatic pixel transparency adjustment If classic multisample antialiasing does not work for you, have a look at centroid modified in GLSL ver 1.2 and upr. See this link for example: http://www.opengl.org/pipeline/article/vol003_6/ I agree, if you're using shaders make sure you declare all your varyings centroid. The linked article suggests that you might not want to use centroid - ignore that, I found that even for quite simple shaders (e.g. basic per-pixel lighting) you can get significant artefacts if centroid isn't used. Predefined varyings (e.g. gl_TexCoord) are always centroid, and unless you're really, really sure it isn't needed, your custom ones should be centroid too. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OpenGL3.0
Hi all, I built the osg2.9.7. I tried to create the project with the OSG_GL3_AVAILABLE, and he rest GL flags disabled. But when I run the simplest example, osgviewer with the cow.osg to render, it renders nothing and display warnings as TexGen::apply - not supported and some other stuff. I dug into the code and found that this is due that I disabled the OSG_GL_FIXED_FUNCTION_AVAILABLE. Does it mean that with OpenGL3 there is not fixed pipeline and all should be written by shaders? What about the projections of the objects from the 3D world to the camera plan, are they done by OpenGL or should I write them too? And if all should be done by shaders, does it mean that most of the code of OSG won't work under GL3 if no appropriate shaders would be written? Thanks, Guy. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenGL3.0
Thanks, I got the main idea, but what about all the OSG foundations? A lot of the code, algorithms and effects are based on the fixed pipeline, am I wrong? Is all this work goes to waste? From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Jason Daly Sent: Wednesday, March 03, 2010 6:09 PM To: OpenSceneGraph Users Subject: Re: [osg-users] OpenGL3.0 Guy wrote: Does it mean that with OpenGL3 there is not fixed pipeline and all should be written by shaders? What about the projections of the objects from the 3D world to the camera plan, are they done by OpenGL or should I write them too? Short answer is yes. OpenGL 3 does not have a fixed-function pipeline, and all rendering must be done with shaders. There is a compatibility extension that allows you to use most of the fixed-function pipeline, but that really goes against the purpose of OpenGL 3. For the long version, I'll echo Gordon's advice to read the list archives. You might also want to refer to the specifications at http://www.opengl.org/documentation/specs/ --J ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] automatic pixel transparency adjustment
Hi all, I need OpenGL/driver/fixed-pipeline/whatever I don't need to code, to do the following thing: When rasterizing an object, first never ignore any pixel the object is projected on (even if the area the object consume in that pixels is tiny). Second multiply the object transparency by the percents the object occupies in that pixel. Is it possible? How can I achieve that? Suppose I can achieve it (maybe with OpenGL3.0, or special flags for previous versions that prevent openGL from discarding pixels that the object occupies less than some threshold on that pixel), does it mean all the objects should be sent to the transparent bin and have blending enabled? What amount of performance impact should I expect? If it is a major impact, do you have any other idea to achieve this effect for objects edges and for objects that are smaller than one pixel? Btw, this is not because I'm crazy, this process is closer to the physical process that happens with camera and therefore more accurate. Thanks, Guy. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Frame Rate oddity
Hi, Many developers at my locations are experiencing odd frame rate readings (from the StatsHandler), and we would like to know if others are having the same issue. We are running in a multiple window/camera enviroment. When I minimize a windows, then the frame rate drops! I would expect the frame rate to increase instead. Maybe not by much (depending on the scene) but an increase just the same. The biggest confusion araises when we change one of our draw callback. By adding a simple glPushAttrib(GL_COLOR_BUFFER_BIT ) and glPopAttrib() in the callback, the frame rate dropped by 1.5ms (200 FPS to 153FPS) - that HUGE!!!. I calculated the cost of glPushAtrrib() and glPopAttrib() in it is ~3 microseconds. Obviously, there is something I don't fully understand about the frame rate being displayed. My first though was that the frame rate displayed by the statshandler was not accurate - but that seems a little odd to me as well. Can anyone shed some light on this odd behavior? Thanks, -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=24718#24718 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] setDataVariance question
Hi, I'm little confused about when it's appropriate or even necessary to call setDataVariance(DYNAMIC) - assuming we are not running in SingleThreaded mode. For example: 1) If I have a switch node and want to change its state in the update or event sequence (i.e during runtime), does the data variance need to be DYNAMIC? If I look at the _switch node in osgViewer::StatsHandler, it is not set to DYNAMIC although it is changed dynamically during runtime. 2) If I add a child node to a simple Group node (again during runtime), does the Group node need to be DYNAMIC? 3) If I have a my target has a MatrixTranform node and I decide to update its matrix, does it need to be DYNAMIC? Regards, -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=24518#24518 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Trilinear vs Bilinear
Ok. I have a little more information for you guys. Just to recap the situation: When I run using Bilinear, I get 30 Hz. When I run using Trilinear, I get 60Hz. During my investigation, I noticed that their are actually 2 bilinear modes: LINEAR and LINEAR_MIPMAP_NEAREST. LINEAR does not include any mipmaps, whereas LINEAR_MIPMAP_NEAREST will include mipmaps. As a test, I modified my texture attribute visitor to replace LINEAR by LINEAR_MIPMAP_NEAREST. Now, the performance is similar to using Trilinear. It seems that the graphics card does not like using Bilinear textures without the mipmaps. Does anyone know why? Regards, Cheers, Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=24243#24243 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] precreating all opengl objects
Thanks for your quick response. This forum is fantastic. Although I haven't tried it yet, I think that Render::setCompileOnNextDraw() is exactly what I am looking for. Paul, I can't seem to find the osgUtil::IncrementalCompileOperator class you mentioned in OSG v2.8.2. Is that a new class in OSG v2.9.6? Regards, -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=24200#24200 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] precreating all opengl objects
I've bee experiencing momentary frame drops when I rotate my camera in my scene. After look at the osg code, I noticed that many of the opengl objects are created during runtime and not when the model is loaded. For example, opengl texture objects are only created when the Texture2d::apply() is traversed. A drawable display lists is only created when its Drawable::drawImplementation() is called. I suspect that, in case, these runtime object creations are the cause of my momentory frame drops. Is there a way to precreate all open objects located define in a scene graph? That way I can confirm my suspicion. One way would be to have a VERY big camera frustum that encloses the entire scene and then renders one frame, but that seems a little *hacked* to me. I am trying to look for an alternative and better way to do that. Guy, -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=24117#24117 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Trilinear vs Bilinear
Hi, I was wondering was experiencing the same odd behavior I am. I created a visitor that essentially iterates through all the textures of a terrain scene graph to change their texture filtering from bilinear to trilinear. When I replace the filtering from bilinear to trilinear, I get a boost of 50% in performance. If I completely bypass my texture visitor then I get a bad performance. This is contrary to what I've been told. I was under the impression tha bilinear filtering was essentially free (as far as performance goes), and that trilinear was a little more expensive (but fairly negligeable). This is not was I am observing. I've tried this on several different graphic cards (9500 GT, 8800 GTX, 260, etc). The driver version I am using is v195.x but it also happens on 185.x. Can someone explain this to me? Someone told me that the new GPUs are built with trilinear in mind, and therefore would perform better is trilinear. Is this true? Regards, Cheers, Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=24104#24104 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Disabling rendering
This might sound like an odd question, but is there a way to disable rendering (no culling and no draw) while still allowing intersections. The reason why I am asking is because I have a distributed system - i.e. some applications only performs intersections with the scene without rendering it. In addition, the osg update call must still occur since that's where some of my animation states gets uptate, which will change the outcome of intersection results (like sprites). Cheers, Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22641#22641 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Disabling rendering
Paul. Thanks for the advice. What I ended-up doing is overriding the void ViewerBase::frame(double simulationTime) function. Depending on the state of a rendering flag, I either call or don't call the renderingTraversals() function. Hopefully, that won't cause any other issues. Cheers, Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=22648#22648 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] PBOs for images and textures
Hi J.P.
First of all, I haven't tried anything yet. It seems to me more than a
minor change so I didn't want to start messig up OSG code with my own
gibrish :)
Second, I've looked at the screen capture examples, but it's not a
generic solution (no offense, it's only my opinion).
Third, about gaining performance, what is the format of RTT you are
using? I remember I once implemented DMA access to textures in an OpenGL
application. For RGB images it was slower than the glReadPixel, but for
RGBA images it was faster. I assume it depends on the driver.
I wonder if I should try and code the DMA access to the draw callback
after you already have done it. I trust you did a good job and if it
didn't gain performance I doubt I could do something better.
Currently the read-back is THE slowest section of my application.
Thanks for the answer, if I'll have time I'll try it also and share the
results with the forum.
Guy.
-Original Message-
From: osg-users-boun...@lists.openscenegraph.org
[mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of J.P.
Delport
Sent: Monday, January 04, 2010 9:20 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] PBOs for images and textures
Hi,
I've been fiddling with some of this at the end of last year for fast
GPU to CPU. You could insert your code into the draw callback. Have you
tried it? How is the performance? I could not make anything faster than
the default readimage. You could also look at osgscreencapture for
examples.
jp
Guy wrote:
Hi all,
I was wondering why when there is an image attached to an FBO camera
buffer, the data transfer is made by glReadImage from the READ_BUFFER
and not by glMapBuffer after copying the READ_BUFFER to PBO?
The same question goes in the other direction for updating textures
with
glTexSubImage.
Wouldn't that be faster (using the DMA)? Is there a scenario which it
wouldn't be better that I miss.
If it is the best way I don't mind trying to help doing so, but I
guess
I'd need help designing it.
My initial approach is:
1. Add PBO object to image. (could be null)
2. Change image readpixels function to the following:
If( PBO )
{
Copy pixels from READ_BUFFER to PBO
Get PBO address
Memcopy(data, address)
}
Else
OldImageReadPixels
3. When attaching image to camera buffer automatically allocate PBO to
that image.
That way there will be no change in render stage or any other part of
OSG.
For textures there can be something similar. The Texture has PBO
object,
the function apply will check for the PBO if exists then copy data to
the PBO address, then bind it and use glTexSumImage and in similar way
change the copyTex to copy to the PBO and then from it's mapped
address
to a CPU address.
In textures maybe part of it could be implemented in subload callback.
Is it the correct path?
Does it already exists and I missed it? If so I'm sorry for the
noise... :)
Thanks,
Guy.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
--
This message is subject to the CSIR's copyright terms and conditions,
e-mail legal notice, and implemented Open Document Format (ODF)
standard.
The full disclaimer details can be found at
http://www.csir.co.za/disclaimer.html.
This message has been scanned for viruses and dangerous content by
MailScanner,
and is believed to be clean. MailScanner thanks Transtec Computers for
their support.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] particles
Hi all, I was wondering what are the criteria to decide upon using display lists or just openGL instruction. Particularly why the rendering of the particles in the osgParticle::Particle::render is done by openGL instructions and not display list or something more efficient. If the reason is changing in the vertex attributes like the particle alpha, and position, then suppose all these attributes are static and I use display list, what performance gain (if any) it is reasonable to expect? I'm asking this because I use shaders in my application, and if there could be performance gain I might want to change the render to update shader attributes and render using these attributes. Do you think it worth the effort implementing such mechanism? Thanks, Guy. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] HUD-Problem
Maybe you had problems with the font loading dlls and when you compiled the code the binaries matched and the dll could load properly... I had similar problem once and required to compile many 3rd party dlls from scratch in order to make them work. But this is only a guess... Guy. -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Carl Johnson Sent: Wednesday, December 30, 2009 12:20 AM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] HUD-Problem Hi, YEAH now it works. Thanks a lot for your help. But now please tell me the different between the developer release and the binary release !? why does the developer release works and the other release not? Thanks a lot again! Cheers, Carl -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21947#21947 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] MultiTexturecontrol on OSG subgraphs (NOT VPB)
What do you mean? You just need to set the different textures at different units... When you create a geometry you set an array of texture coordinates and bind it to texture unit. If you want you can use the same texture coordinates to more texture units or different coordinates to different units. As for the texture itself, when you add the texture attribute to the stateset of the object you also bind it to a texture unit, and of course you can repeat the process with other units. I think there is an example of multi-texturing... -Original Message- From: osg-users-boun...@lists.openscenegraph.org [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf Of Torben Dannhauer Sent: Monday, December 28, 2009 5:37 PM To: osg-users@lists.openscenegraph.org Subject: Re: [osg-users] MultiTexturecontrol on OSG subgraphs (NOT VPB) Hmm, has anyone yet used a Model with more than one texture? Hard to believe.. I would be happy to write a howto, but I have no clue myself... Well,I'll let you Know if I have a solution. Thanks Torben -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=21887#21887 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or g ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] PBOs for images and textures
Hi all,
I was wondering why when there is an image attached to an FBO camera
buffer, the data transfer is made by glReadImage from the READ_BUFFER
and not by glMapBuffer after copying the READ_BUFFER to PBO?
The same question goes in the other direction for updating textures with
glTexSubImage.
Wouldn't that be faster (using the DMA)? Is there a scenario which it
wouldn't be better that I miss.
If it is the best way I don't mind trying to help doing so, but I guess
I'd need help designing it.
My initial approach is:
1. Add PBO object to image. (could be null)
2. Change image readpixels function to the following:
If( PBO )
{
Copy pixels from READ_BUFFER to PBO
Get PBO address
Memcopy(data, address)
}
Else
OldImageReadPixels
3. When attaching image to camera buffer automatically allocate PBO to
that image.
That way there will be no change in render stage or any other part of
OSG.
For textures there can be something similar. The Texture has PBO object,
the function apply will check for the PBO if exists then copy data to
the PBO address, then bind it and use glTexSumImage and in similar way
change the copyTex to copy to the PBO and then from it's mapped address
to a CPU address.
In textures maybe part of it could be implemented in subload callback.
Is it the correct path?
Does it already exists and I missed it? If so I'm sorry for the noise...
:)
Thanks,
Guy.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] DrvCopyContex
Hi all, I profiled my application and found that about 25% of the time is spent in DrvCopyContext. This is an NVidia driver function. Any way to avoid it or reduce it? Does it happens to all? I tried updating the driver and it is still the same. I'm running on windows XP SP3, NVida 8800 driver 195.62 Thanks, Guy. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture2D::copyTexImage2D
Unfortunately, my graphic crad does not support NPOT texture which is why I
can't use osg::TextureRectangle.
I also tried ensuring that my Texture2D is always a POT when I change the
windows size (see code below).
Code:
int32 nWitdh = viewport-width();
int32 nHeight = viewport-height();
int32 nPOTWidth = ComputeUpperPowerOfTwo( nWidth );
int32 nPOTHeight = ComputeUpperPowerOfTwo( nHeight );
if( nPOTWidth != pTex2D-getTextureWidth( ) || nPOTHeight !=
pTex2D-getTextureHeight( ) )
{
pTex2D-dirtyTextureObject( );
pTex2D-setTextureSize( nPOTWidth, nPOTHeight );
}
else
{
bDirtyTexture = false;
}
u = double( nWidth ) / nPOTWidth;
v = double( nHeight ) / nPOTHeight;
However that does not work. The Texture2D::copyTexImage2D() eventually gets
called, but fails to call copyTexSubImage2D() since the width/height passes as
paramater do not equal the texture width/height.
Code:
if (width==(int)_textureWidth height==(int)_textureHeight)
{
// we have a valid texture object which is the right size
// so lets play clever and use copyTexSubImage2D instead.
// this allows use to reuse the texture object and avoid
// expensive memory allocations.
copyTexSubImage2D(state,0 ,0, x, y, width, height);
return;
}
Near the end of the Texture2D::copyTexImage2D() function, it simply copies the
viewport size (width/height) into the texture _textureWidth/_textureHeight and
thus it becomes a NPOT texture - hense the problem I am experiencing.
Guy
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=20896#20896
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture2D::copyTexImage2D
Ahhh.. I was not aware of that small detail. Thanks for the info - I will try it immediately. Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=20898#20898 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture2D::copyTexImage2D
Dude you the greatest. Using osg::TextureRectangle worked! Thanks for your great help. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=20926#20926 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Texture2D::copyTexImage2D
Hi,
I was having problems with a resizable window that required a render target
implementation (like FRAME_BUFFER). The problem only occurred on hardware that
did not support NPOT textures (what can I say - I have an old graphic card!).
The problem was isolated in Texture2D::copyTexImage2D() which I corrected below
(enclosed between MTSI labels).
Can anyone confirm that this is the correct solution?
Code:
inline int ComputeUpperPowerOfTwo( int s )
{
static double ks_dLog2 = log10( 2.0 );
return ( 1 ( int ) ceil( log10( ( double ) s ) / ks_dLog2 ) );
}
void Texture2D::copyTexImage2D(State state, int x, int y, int width, int
height )
{
const unsigned int contextID = state.getContextID();
if (_internalFormat==0) _internalFormat=GL_RGBA;
// get the globj for the current contextID.
TextureObject* textureObject = getTextureObject(contextID);
if (textureObject)
{
if (width==(int)_textureWidth height==(int)_textureHeight)
{
// we have a valid texture object which is the right size
// so lets play clever and use copyTexSubImage2D instead.
// this allows use to reuse the texture object and avoid
// expensive memory allocations.
copyTexSubImage2D(state,0 ,0, x, y, width, height);
return;
}
// the relevent texture object is not of the right size so
// needs to been deleted
// remove previously bound textures.
dirtyTextureObject();
// note, dirtyTextureObject() dirties all the texture objects for
// this texture, is this right? Perhaps we should dirty just the
// one for this context. Note sure yet will leave till later.
// RO July 2001.
}
// remove any previously assigned images as these are nolonger valid.
_image = NULL;
// switch off mip-mapping.
//
_textureObjectBuffer[contextID] = textureObject =
generateTextureObject(contextID,GL_TEXTURE_2D);
textureObject-bind();
applyTexParameters(GL_TEXTURE_2D,state);
bool needHardwareMipMap = (_min_filter != LINEAR _min_filter != NEAREST);
bool hardwareMipMapOn = false;
if (needHardwareMipMap)
{
hardwareMipMapOn = isHardwareMipmapGenerationEnabled(state);
if (!hardwareMipMapOn)
{
// have to switch off mip mapping
notify(NOTICE)Warning: Texture2D::copyTexImage2D() switch
off mip mapping as hardware support not available.std::endl;
_min_filter = LINEAR;
}
}
GenerateMipmapMode mipmapResult = mipmapBeforeTexImage(state,
hardwareMipMapOn);
// MTSI [20091203 guyv]
// Fixed an an issue with hardware that does not support non-power-of-two
textures.
int tex_width = width;
int tex_height = height;
const Extensions* extensions = getExtensions(contextID,true);
if( _resizeNonPowerOfTwoHint ||
!extensions-isNonPowerOfTwoTextureSupported(_min_filter) )
{
tex_width = ComputeUpperPowerOfTwo(width-2*_borderWidth)+2*_borderWidth;
tex_height =
ComputeUpperPowerOfTwo(height-2*_borderWidth)+2*_borderWidth;
}
// cap the size to what the graphics hardware can handle.
if (tex_widthextensions-maxTextureSize()) tex_width =
extensions-maxTextureSize();
if (tex_heightextensions-maxTextureSize()) tex_height =
extensions-maxTextureSize();
glCopyTexImage2D( GL_TEXTURE_2D, 0, _internalFormat, x, y, tex_width,
tex_height, 0 );
mipmapAfterTexImage(state, mipmapResult);
_textureWidth = tex_width;
_textureHeight = tex_height;
_numMipmapLevels = 1;
// ~MTSI [20091203 guyv]
textureObject-setAllocated(_numMipmapLevels,_internalFormat,_textureWidth,_textureHeight,1,0);
// inform state that this texture is the current one bound.
state.haveAppliedTextureAttribute(state.getActiveTextureUnit(), this);
}
Cheers,
Guy
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=20833#20833
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Texture2D::copyTexImage2D
Forgot to mentioned that I was using OSG 2.8.2. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=20834#20834 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Disabling culling for a geode
Hi, Is there a way to disable culling for a geode. Essentially, I want the geode render every frame - usefull for skyboxes and skydomes. I tried calling setCullingActive(false) but that does not work. The only way I was able to make it work, so far, is by setting the Geometry::setInitialBound(...) to something very big. But that seems odd to me. Is there a better way that I am not aware of? Thanks, -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=20300#20300 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Cameras hierarchy
Hi all, I'm having a difficulty understanding whats goes wrong with my scene setting. I tried merge between the osghud example and the osgdistortion example. The result I expected was to have object in the background which responds to the mouse movement, HUD in front of it, and the entire image distorted. So initially I had a graph build like that Root Distortion Group HUDed scene Which equals Root DistortedTextureDisplayCamera RTT Camera GridGeometry PostRenderCamera Scene Hud geometry This didn't work. I couldn't see the HUD. Later I changed it to Root DistortedTextureDisplayCamera RTT Cameta order 1 RTT Cameta order 1 GridGeometry Hud geometry Scene This configuration did get the right result. Later on I tried, just for the test to render a scene Root DistortedTextureDisplayCamera RTT Camera GridGeometry Camera Scene This is exactly the osgdistortion example with the adding of a camera above the scene. This camera has all the default settings, which means it does nothing, but I couldn't see anything. Can you please explain why the first and the last graphs didn't give the expected results? Isn't it possible to add cameras under RTT camera? I had similar problems with depth partitioning and shadows. Does it mean that when using RTT, these solutions have to be rearranged completely in the aspect of the camera hierarchy? Thanks, Guy. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Stats Matrices label
Hi, I think I found a wrong display label when when the camera scene stats is enabled. There is a label called Matrices. Shouldn't it be called Materials instead? Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=1#1 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] State::getInitialViewMatrix() StatsHandler
Hi, We are observing a few problems when displaying the statistics on the screen. Essencially, when we enable stats the State::getInitialViewMatrix() return identity matrix. If the stats are NOT enabled, then it return the view matrix of my slave camera. Is this the correct behavior? If so, what is the best way to recover the view matrix of my slave camera? I know that the State class contains a list of cameras. I can iterate through the vector and find my camera, but that seems and expensive solution. Any other suggestions would be appreciated. Cheers, Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=17568#17568 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenGL Extensions.
Jan, I looked at GLEW after I wrote my original post. I was about to download and use when I figured out an easier way. I essentially followed robert's advise (thanks rob!). NOTE: In my case, I would also need to recompile GLEW to use multiple threads/context (which also require installing Cygwin). Thanks for your help. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=17305#17305 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render-to-texture TextureRectangle
NPOT = non-power-of-two POT = power-of-two Since my card does not support NPOT textures, can I create a POT texture but command the renderTargetImplemtation to only render to a specific region of the texture. For example, if my texture if 512x512 (i.e POT texture) and my viewport is 320x240 (widthxheight), can I command the renderTargetImplememtation to render the entire viewport to only the 320x240 portion of the texture? Since the viewport define in the camera is 320x240, I would expect this to work. Can anyone confirm this? Regards, -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=17306#17306 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Render-to-texture TextureRectangle
I was able to use a POT texture after all with the renderTargetImplementation of camera (as I mentioned in my last post). All is well with the world once again. Thanks everyone. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=17307#17307 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Render-to-texture TextureRectangle
Hi, I am having a weird problem which I hope you can help. I am running on Win2000 with a relatively old nvidia card. 1) When I run then osgtexturerectangle example and I supply a non-power-of-two image as a command line argument, the example still runs as expected. So that tell me that my system supports non-power-of-two textures. 2) When I run the osgprerender example with --texture_rectangle argument at the command line, all I see is a black flag. Obviously, if I do not supply the --texture_rectangle option, it works fine. I've been trying to identify why the camera's render target implementation is not working. The example is so simple, but it does not work. I tried diffent render target implementation (ex. FRAME_BUFFER) and they all don't work. As soon as the texture is NPOT, it fails. Note that the driver I am using is fairly old (v56.71) and I cannot update it. Any ideas would be appreciated. Cheers, Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=17302#17302 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OpenGL Extensions.
Hi, I have several cameras that need to be configured slightly differently depending on the opengl extensions supported by the card. For example, I have a card that does not support p-buffers in which case I need to devise a different way to perform RTT. Same goes for vertex and fragment shaders. In essence, I need to handle these situations. I know how to recover all supported extensions but that can only be done after the graphic context is create and made current for the camera (i.e. the osg::camera::realize() is called). As I understand, I'm in a catch-22 situation. I cannot get the opengl extension because I did not fully configured my camera, and I can't configure my camera because I don't have the opengl extension yet. Obviously, I can register a InitialDrawCallback function for each of my cameras. This callback could then lookup the extension and complete the camera configuration, but that seems very messy. Is there an easier way to do this? Thank you! Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=17188#17188 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] window position and size
You're the man!!! Thanks. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=14697#14697 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] window position and size
Hi, I've implemented the osg::GraphicsContext::ResizedCallback to get notified when the user resizes the window via the mouse. That work perfectly. However, I also need to change the window size programatically (when the user presses a button, for example). I tried calling osg::GraphicsContext::resized() function, but that does not always work. Apart from calling ::SetWindowPos(), is there an osg call that allow the windows position and size to be adjusted? Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=14668#14668 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Problems with RTT-cameras when changing window s
As you may have noticed from my scene graph layout, I have a switch node above the RTT camera. This switch node allows me to enable/disable the RTT process. By default, this switch node has the RTT process disabled. So, the RTT process is not executed. I also found that (by default) the update traversal mode is set to traverse all children (TRAVERSE_ALL_CHILDREN). I originally thought that this was my problem, so I changed the traversal mode to TRAVERSE_ACTIVE_CHILDREN, but I still get the same problem when update callbacks are being called twice every frame. Example: m_pViewer-getUpdateVisitor( )-setTraversalMode( osg::NodeVisitor::TRAVERSE_ACTIVE_CHILDREN ); Guy -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=14106#14106 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
