Re: [osg-users] Submission/Pull Request problems on github
According to these post you can let the git tools automatically make a branch for every pull request on github: http://blog.scottlowe.org/2015/09/04/checking-out-github-pull-requests-locally/ https://coderwall.com/p/3dgwcg/github-add-remote-for-pulls-and-merges Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=67178#67178 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-3.4.0 release candidate 7 tagged
The changed for VS2015 look good. I still get the following warning: 3I:\Libraries\OpenSceneGraphTrunk\include\osg/GraphicsThread(45): warning C4589: Constructor of abstract class 'osg::GraphicsOperation' ignores initializer for virtual base class 'osg::Referenced' (compiling source file I:\Libraries\OpenSceneGraphTrunk\src\osg\TextureCubeMap.cpp) 3 I:\Libraries\OpenSceneGraphTrunk\include\osg/GraphicsThread(45): note: virtual base classes are only initialized by the most-derived type (compiling source file I:\Libraries\OpenSceneGraphTrunk\src\osg\TextureCubeMap.cpp) 3 I:\Libraries\OpenSceneGraphTrunk\include\osg/GraphicsThread(45): note: This diagnostic occurred in the compiler generated function 'osg::GraphicsOperation::GraphicsOperation(const osg::GraphicsOperation )' (compiling source file I:\Libraries\OpenSceneGraphTrunk\src\osg\TextureCubeMap.cpp) But according Microsoft it's a vs2015 bug that will be fixed in the next update (https://connect.microsoft.com/VisualStudio/feedback/details/1570496/vs-2015-generates-a-copy-constructor-and-then-complains-about-it) Btw VS2015 now also warns when a variable is shadowing another one, this amounts to over 600 warnings. In gcc or clang you can probably turn them on with -Wshadow. Some of them are in osg core, I'll look into those when I get back from vacation. Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=64461#64461 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-3.4.0-rc6 tagged
I'll see what I can do. I'm going on vacation tomorrow so I don't have that much time. First I have resolved the errors so I can get OSG to compile with VS2015, those are more important. Attached are two files. - First is osg/Types: VS2015 now have stdint.h included. This generates erros when including Types when stdin.h was previously included somewhere else. - Second is ViewerBase with a workaround for VS2015 which generates a standard assignment operator that in turn uses the private one from osg::Objectand this all makes the compiler generate and error. To fix the other warnings I will first need to find all the classes that derive from osg::Operation and make sure they call osg::Referenced in their constructors. Then remove the call from the call to osg::Referenced from the constructors of osg::Operation. I have though about this and wondered why other compilers don't complain about this. It could be that they just ignore the call to Referenced::Reference(true) in the constructors of Operation without a warning and in the most derive class place a call to Referenced::Reference() instead of Referenced::Reference(true). For more info about virtual inheritance see http://stackoverflow.com/questions/10534228/order-of-constructor-call-in-virtual-inheritance and https://isocpp.org/wiki/faq/multiple-inheritance#virtual-inheritance-ctors Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=64450#64450 ViewerBase Description: Binary data Types Description: Binary data ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-3.4.0-rc6 tagged
Hi Robert,
Testing with the newly released VS2015 produced these 4 warnings for each file
that includes (directly or indirectly) osg/GraphicsThread this will lead to
hundreds of warnings:
1I:\Libraries\OpenSceneGraphTrunk\include\osg/OperationThread(55): warning
C4589: Constructor of abstract class 'osg::Operation' ignores initializer for
virtual base class 'osg::Referenced'
1 I:\Libraries\OpenSceneGraphTrunk\include\osg/OperationThread(55): note:
virtual base classes are only initialized by the most-derived type
1I:\Libraries\OpenSceneGraphTrunk\include\osg/OperationThread(81): warning
C4589: Constructor of abstract class 'osg::Operation' ignores initializer for
virtual base class 'osg::Referenced'
1 I:\Libraries\OpenSceneGraphTrunk\include\osg/OperationThread(81): note:
virtual base classes are only initialized by the most-derived type
1I:\Libraries\OpenSceneGraphTrunk\include\osg/OperationThread(85): warning
C4589: Constructor of abstract class 'osg::Operation' ignores initializer for
virtual base class 'osg::Referenced'
1 I:\Libraries\OpenSceneGraphTrunk\include\osg/OperationThread(85): note:
virtual base classes are only initialized by the most-derived type
1I:\Libraries\OpenSceneGraphTrunk\include\osg/GraphicsThread(45): warning
C4589: Constructor of abstract class 'osg::GraphicsOperation' ignores
initializer for virtual base class 'osg::Referenced'
1 I:\Libraries\OpenSceneGraphTrunk\include\osg/GraphicsThread(45): note:
virtual base classes are only initialized by the most-derived type
1 I:\Libraries\OpenSceneGraphTrunk\include\osg/GraphicsThread(45): note: This
diagnostic occurred in the compiler generated function
'osg::GraphicsOperation::GraphicsOperation(const osg::GraphicsOperation )'
Trying to find out what is really happening I stumbled on this:
http://stackoverflow.com/questions/10534228/order-of-constructor-call-in-virtual-inheritance
The first three warnings come from this:
The problem is that the Operation class is virtually inheriting from the class
Referenced. The constructors and copy constructors of the class Operation call
Referenced(true). Now, with virtual inheritance the constructors of virtual
base classes are always called from the most derived class. Now what Visual
Studio is complaining about is that Operations is a abstract class so you can
not construct an instance of it directly. You need to inherit from it,
implement the abstract methods and construct the derived class. So the call to
Referenced(true) will never happen inside the Operation constructors. Instead
you need to add this call to the most derived classes of Operation. If you
don't do this it will call the default constructor Referenced::Referenced()
instead of Referenced::Referenced(true).
I did a search to see whats inheriting from Operation and found a few cases.
For example BlockAndFlushOperation and
ReleaseContext_Block_MakeCurrentOperation do not call Referenced(true) in their
constructors so then the default constructor Referenced() is called.
The 4th warning comes from that visual studio makes a default constructor for
GraphicsOperation that calls Referenced() and then complains about it, this is
probably a bug in vs2015, see also:
https://connect.microsoft.com/VisualStudio/feedback/details/1570496/vs-2015-generates-a-copy-constructor-and-then-complains-about-it
The same is happening for the class ViewerBase because it is using virtual
inheritance to derive from Object and calling Object(true) from the constructor.
For ViewerBase I even got an error:
1I:\Libraries\OpenSceneGraphTrunk\include\osgViewer/ViewerBase(340): error
C2249: 'osg::Object::operator =': no accessible path to private member declared
in virtual base 'osg::Object'
1 I:\Libraries\OpenSceneGraphTrunk\include\osg/Object(238): note: see
declaration of 'osg::Object::operator ='
1 I:\Libraries\OpenSceneGraphTrunk\include\osg/Object(56): note: see
declaration of 'osg::Object'
1 I:\Libraries\OpenSceneGraphTrunk\include\osgViewer/ViewerBase(340): note:
This diagnostic occurred in the compiler generated function
'osgViewer::ViewerBase osgViewer::ViewerBase::operator =(const
osgViewer::ViewerBase )'
But this looks like the bug in visual studio from above but this time it makes
a default copy operator for ViewerBase that tries to call the private copy
operator of Object from the generated default copy operator. It might be an bug
in the compiler or it might be by a genuine error (I don't know the specs of
c++ that well:) ) but a workaround for this error is to add:
Code:
private:
ViewerBase operator = (const ViewerBase) { return *this; }
At the end of the ViewerBase class. (At least if that is the intended behavior)
Cheers,
Pjotr
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=64443#64443
___
osg-users mailing list
osg-users@lists.openscenegraph.org
Re: [osg-users] Last update in the osgAnimation::Animation ONCE mode bug fix
Would't this add cpu overhead for animations that are done playing because the channels are still updating? Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61727#61727 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GeometryTechnique race condition crash
Hi Robert, I tested a few of our scene's and till now there are no problems. Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61638#61638 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GeometryTechnique race condition crash
Due to some other work I won't be able to test this out today, but I'll try to make room for it tomorrow. Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61614#61614 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GeometryTechnique race condition crash
I have done some tests and it looks good so far. There is only one regression here and that is that proxy nodes that are set to load immediately are never looked up from the cache ever. This actually is the most common use case for us for those types of nodes. In our program we by chance had the database pager flags set in such a way that the database did not do any post-processing so those visitors are thread safe (if the marker objects are removed again). It would be a good idea to have a flag in the database pager to not disable caching of nodes (or for the pager to automatically see if the flags for FindCompileableGLObjectsVisitor are set in such a way that it is not needed). Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61567#61567 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GeometryTechnique race condition crash
That sounds good. You might even want to have a mapfilename, Readresult somewhere in there, then you can see which of the nodes are already in the cache and do not need further post-processing. Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61571#61571 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GeometryTechnique race condition crash
Because you also have to deal with subobject like proxy nodes and images that you want to have in the cache option 2 and 3 will be pretty hard to implement. Option one seems like the elegant solution as right now you can only activate those post processing steps if you have a database pager (or you implement them yourself). Also looking at the code there are already some post process things in the Registery and Database Pager that overlap. For instance there is a _buildKdTreeIfRequired method in Registery but FindCompileableGLObjectsVisitor also tries to build a kdtree. Btw: whatever you choose it would be a good idea to split the post processing traversal from the compile set collecting anyway for better readability. Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61537#61537 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GeometryTechnique race condition crash
robertosfield wrote: I have been looking further into how to handle use of the object cache alongside the DatabasePager and believe the best option will be for the DatabasePager to disable use of object cache when it's loaded subgraphs and handle the initial query against the object cache and final insertion of loaded subgraphs into the object cache. Caching of images will probably be safe to do within the scope of loading data. Do you mean that you want to keep loading images normally and defer the loading of subgraph/proxynodes to the database pager? That sounds reasonable. robertosfield wrote: I don't know if it will be worth implementing a form of block in the object cache to hold back attempts to read the same file whilst it's still being loaded. If the second concurrent load attempt is being done by a DatabasePager thread then it'll be safe to block, but this might actually be handled by merging/coupling the DatabaseRequest's so that only one load happens, but two merges can happen later. Such coupling would add quite a bit of complexity though. Thoughts? I don't understand what you want to do here? Do you only want to have one file loading at a time? -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61542#61542 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GeometryTechnique race condition crash
Hi Robert,
I tried your fix and it exposed a bug in my fix :)
The problem is that the readObjectFields method will add the object to the
_identifierMap. So all the other instances of that image in the same file will
be replaced by the created dummy object. In my fix this was an dummy image and
I didn't notice it in our scene's, probably because it covered a small part of
an object. In your fix the dummy object was not an image and that leads to a
crash when something tries to use it as an image. I have attached a small fix
for this bug.
Cheers,
Pjotr
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=61530#61530
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2010 Robert Osfield
*
* This library is open source and may be redistributed and/or modified under
* the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or
* (at your option) any later version. The full license is in LICENSE file
* included with this distribution, and on the openscenegraph.org website.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* OpenSceneGraph Public License for more details.
*/
// Written by Wang Rui, (C) 2010
#include osg/Notify
#include osg/ImageSequence
#include osgDB/ReadFile
#include osgDB/XmlParser
#include osgDB/FileNameUtils
#include osgDB/ObjectWrapper
using namespace osgDB;
static std::string s_lastSchema;
class DummyObject : public osg::Object
{
public:
DummyObject() {}
DummyObject(const DummyObject dummy, const osg::CopyOp copyop) {}
META_Object(osgDB, DummyObject)
protected:
virtual ~DummyObject() {}
};
InputStream::InputStream( const osgDB::Options* options )
: _fileVersion(0), _useSchemaData(false), _forceReadingImage(false),
_dataDecompress(0)
{
BEGIN_BRACKET.set( {, +INDENT_VALUE );
END_BRACKET.set( }, -INDENT_VALUE );
if ( !options ) return;
_options = options;
if ( options-getPluginStringData(ForceReadingImage)==true )
_forceReadingImage = true;
if ( !options-getPluginStringData(CustomDomains).empty() )
{
StringList domains, keyAndValue;
split( options-getPluginStringData(CustomDomains), domains, ';' );
for ( unsigned int i=0; idomains.size(); ++i )
{
split( domains[i], keyAndValue, ':' );
if ( keyAndValue.size()1 )
_domainVersionMap[keyAndValue.front()] =
atoi(keyAndValue.back().c_str());
}
}
std::string schema;
if ( !options-getPluginStringData(SchemaFile).empty() )
{
schema = options-getPluginStringData(SchemaFile);
if ( s_lastSchema!=schema )
{
osgDB::ifstream schemaStream( schema.c_str(), std::ios::in );
if ( !schemaStream.fail() ) readSchema( schemaStream );
schemaStream.close();
s_lastSchema = schema;
}
}
if ( schema.empty() )
{
resetSchema();
s_lastSchema.clear();
}
// assign dummy object to used for reading field properties that will be
discarded.
_dummyReadObject = new DummyObject;
}
InputStream::~InputStream()
{
if (_dataDecompress)
delete _dataDecompress;
}
int InputStream::getFileVersion( const std::string d ) const
{
if ( d.empty() ) return _fileVersion;
VersionMap::const_iterator itr = _domainVersionMap.find(d);
return itr==_domainVersionMap.end() ? 0 : itr-second;
}
InputStream InputStream::operator( osg::Vec2b v )
{
char x, y; *this x y;
v.set( x, y );
return *this;
}
InputStream InputStream::operator( osg::Vec3b v )
{
char x, y, z; *this x y z;
v.set( x, y, z );
return *this;
}
InputStream InputStream::operator( osg::Vec4b v )
{
char x, y, z, w; *this x y z w;
v.set( x, y, z, w );
return *this;
}
InputStream InputStream::operator( osg::Vec2ub v )
{
unsigned char x, y; *this x y;
v.set( x, y );
return *this;
}
InputStream InputStream::operator( osg::Vec3ub v )
{
unsigned char x, y, z; *this x y z;
v.set( x, y, z );
return *this;
}
InputStream InputStream::operator( osg::Vec4ub v )
{
unsigned char r, g, b, a; *this r g b a;
v.set( r, g, b, a );
return *this;
}
InputStream InputStream::operator( osg::Vec2s v )
{ *this v.x() v.y(); return *this; }
InputStream InputStream::operator( osg::Vec3s v )
{ *this v.x() v.y() v.z(); return *this; }
InputStream InputStream::operator( osg::Vec4s v )
{ *this v.x() v.y() v.z() v.w(); return *this; }
InputStream InputStream::operator( osg::Vec2us v )
{ *this v.x() v.y(); return *this; }
InputStream InputStream::operator( osg::Vec3us v )
{ *this v.x() v.y() v.z(); return *this; }
InputStream InputStream::operator( osg::Vec4us v )
{ *this v.x() v.y() v.z() v.w(); return *this; }
InputStream
Re: [osg-users] GeometryTechnique race condition crash
Hi Robert, I'm still in the process of compiling, but I had a look at the code. As I understand it an object is put in the registery cache by Registry::instance()-readNode(), thats before FindCompileableGLObjectsVisitor will traverse it. This means that you will get race conditions in FindCompileableGLObjectsVisitor trying to set/get markerobjects. Also get/setUserdata is not thread safe also. Another problem can arise when people add their own userdata inside an object after they load it or have objects that have userdata already present file. Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61533#61533 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GeometryTechnique race condition crash
Hi Robert, I saw that you put the new thread code on svn. I have experimented a little with it and it seems to produce deadlocks on application shutdown for us. In OperationThread::cancel you have replaced a while loop with a join. The problem is that the previous code was periodically calling _currentOperation-release() which the new code does not do. I think I have narrowed the problem down, there are two scenarios that can produce deadlocks: 1) OperationThread::cancel can call _currentOperation-release() when the operation thread is at line 396 to 399 (so it didn't set _currentOperation yet). This way the operation thread will be blocking on the operation it just got from the queue, which is not the operation that got it's release method called by OperationThread::cancel. 2) If the current operation is a barrier then the release method only releases threads that are waiting, it does not invalidate the barrier. So if the operation thread is not yet in the barrier and you call release it will still block when it arrives at the barrier. Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61519#61519 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GeometryTechnique race condition crash
I first got the deadlock on linux and only in release builds. On windows I was able to reproduce it by placing a 1ms sleep line 403. Adding cancel helps but then the thread will not do any clean up and valgrind spits out a 1mb log file complaining about memory leaks. It's better to try to fix the deadlock than doing a cancel. For scenario one it should be possible to rearrange the code a little to make it work. For scenario two, a Operation should have a method that will invalidate it so it won't block any more. I have searched the code and have found 3 kinds of Operations: - BlockOperation: this one is invalidated by calling release, but can become blocking again is you call reset() or set(false). - BarrierOperation: this is where the deadlock occurs. But Barriers can be invalidated by calling invalidate() but there is currently no way to make them blocking again if you want to reuse them later. - GraphicsOperation: the release method of this one is empty already, it is stopped by calling setDone() when stopThreading is called. Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61521#61521 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GeometryTechnique race condition crash
Looks like the new code fixes the deadlocks.
Attached are my modifications to the InputStream to no modify images when they
come from a cache. Note that this is a quick fix.
Cheers,
Pjotr
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=61524#61524
/* -*-c++-*- OpenSceneGraph - Copyright (C) 1998-2010 Robert Osfield
*
* This library is open source and may be redistributed and/or modified under
* the terms of the OpenSceneGraph Public License (OSGPL) version 0.0 or
* (at your option) any later version. The full license is in LICENSE file
* included with this distribution, and on the openscenegraph.org website.
*
* This library is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* OpenSceneGraph Public License for more details.
*/
// Written by Wang Rui, (C) 2010
#include osg/Notify
#include osg/ImageSequence
#include osgDB/ReadFile
#include osgDB/XmlParser
#include osgDB/FileNameUtils
#include osgDB/ObjectWrapper
using namespace osgDB;
static std::string s_lastSchema;
InputStream::InputStream( const osgDB::Options* options )
: _fileVersion(0), _useSchemaData(false), _forceReadingImage(false),
_dataDecompress(0)
{
BEGIN_BRACKET.set( {, +INDENT_VALUE );
END_BRACKET.set( }, -INDENT_VALUE );
if ( !options ) return;
_options = options;
if ( options-getPluginStringData(ForceReadingImage)==true )
_forceReadingImage = true;
if ( !options-getPluginStringData(CustomDomains).empty() )
{
StringList domains, keyAndValue;
split( options-getPluginStringData(CustomDomains), domains, ';' );
for ( unsigned int i=0; idomains.size(); ++i )
{
split( domains[i], keyAndValue, ':' );
if ( keyAndValue.size()1 )
_domainVersionMap[keyAndValue.front()] =
atoi(keyAndValue.back().c_str());
}
}
std::string schema;
if ( !options-getPluginStringData(SchemaFile).empty() )
{
schema = options-getPluginStringData(SchemaFile);
if ( s_lastSchema!=schema )
{
osgDB::ifstream schemaStream( schema.c_str(), std::ios::in );
if ( !schemaStream.fail() ) readSchema( schemaStream );
schemaStream.close();
s_lastSchema = schema;
}
}
if ( schema.empty() )
{
resetSchema();
s_lastSchema.clear();
}
}
InputStream::~InputStream()
{
if (_dataDecompress)
delete _dataDecompress;
}
int InputStream::getFileVersion( const std::string d ) const
{
if ( d.empty() ) return _fileVersion;
VersionMap::const_iterator itr = _domainVersionMap.find(d);
return itr==_domainVersionMap.end() ? 0 : itr-second;
}
InputStream InputStream::operator( osg::Vec2b v )
{
char x, y; *this x y;
v.set( x, y );
return *this;
}
InputStream InputStream::operator( osg::Vec3b v )
{
char x, y, z; *this x y z;
v.set( x, y, z );
return *this;
}
InputStream InputStream::operator( osg::Vec4b v )
{
char x, y, z, w; *this x y z w;
v.set( x, y, z, w );
return *this;
}
InputStream InputStream::operator( osg::Vec2ub v )
{
unsigned char x, y; *this x y;
v.set( x, y );
return *this;
}
InputStream InputStream::operator( osg::Vec3ub v )
{
unsigned char x, y, z; *this x y z;
v.set( x, y, z );
return *this;
}
InputStream InputStream::operator( osg::Vec4ub v )
{
unsigned char r, g, b, a; *this r g b a;
v.set( r, g, b, a );
return *this;
}
InputStream InputStream::operator( osg::Vec2s v )
{ *this v.x() v.y(); return *this; }
InputStream InputStream::operator( osg::Vec3s v )
{ *this v.x() v.y() v.z(); return *this; }
InputStream InputStream::operator( osg::Vec4s v )
{ *this v.x() v.y() v.z() v.w(); return *this; }
InputStream InputStream::operator( osg::Vec2us v )
{ *this v.x() v.y(); return *this; }
InputStream InputStream::operator( osg::Vec3us v )
{ *this v.x() v.y() v.z(); return *this; }
InputStream InputStream::operator( osg::Vec4us v )
{ *this v.x() v.y() v.z() v.w(); return *this; }
InputStream InputStream::operator( osg::Vec2i v )
{ *this v.x() v.y(); return *this; }
InputStream InputStream::operator( osg::Vec3i v )
{ *this v.x() v.y() v.z(); return *this; }
InputStream InputStream::operator( osg::Vec4i v )
{ *this v.x() v.y() v.z() v.w(); return *this; }
InputStream InputStream::operator( osg::Vec2ui v )
{ *this v.x() v.y(); return *this; }
InputStream InputStream::operator( osg::Vec3ui v )
{ *this v.x() v.y() v.z(); return *this; }
InputStream InputStream::operator( osg::Vec4ui v )
{ *this v.x() v.y() v.z() v.w(); return *this; }
InputStream InputStream::operator( osg::Vec2f v )
{ *this v.x() v.y(); return *this; }
InputStream InputStream::operator( osg::Vec3f v )
{ *this v.x() v.y()
Re: [osg-users] GeometryTechnique race condition crash
Thanks for the helgrind tip. I think I pinpointed the crash in our program, this is working from trunk: As said we have multiple files that reference the same image for a texture, I have found two spots that can cause problems: - In InputStream::readImage(bool readFromExternal) at line 777 the program could get an image from the cache. After this it continues to read the image fields and set parameters. The most problematic is at like 784 where it will set the image filename, which is a string. This is not thread safe. Looking further it will call readObjectFields which will read the name and userdata and crash on that. - When a Texture2D is read it will call Texture2D::setImage and this function will call _image-addClient which can mess up the _numClients counter. The second problem can also appear while reading ive files. Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61424#61424 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GeometryTechnique race condition crash
Hi Robert, You said that you were working with shaders. A race condition that looks like the Texture2D::setImage example above can also happen with shaders in .osg files: The method Shader_readLocalData can get shaders out of a cache when files are referenced. Then later in Program::addShader the program will call shader-addProgramRef which does not look thread safe to me. Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61426#61426 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GeometryTechnique race condition crash
robertosfield wrote: In the case when the image is shared it looks to me like the best approach would be to not allow any additional modifications to the image by the InputStream::readImage() method. Even if you added mutex locks around the write operations to the mutex you'd ended with an image that flips state during it's lifetime so that the original owners of the image would then have an Image in a new state that it doesn't have baring on what it was originally. This might be OK in some instances, but could cause real problems for application/code that assumes the Image is invariant once it has been set up. Changing the behaviour to ignore the local modifications when an Image is shared is something that might break applications too, but my instinct is to treat Image as invariant once setup is the more common case so will affect users left often than the current state. Perhaps one possibility would be to have a flag in InputStream to give a hint to what to do. If we do ignore the extra write for Image's pulled from the cache we'd need to still read then discard the options to avoid breaking file compatibility. Another, more drastic workaround would be to duplicate the osg::Image from the cache and let the new Image be modified. This rather defaults the purpose of using a cache though. It's worth adding that this cached object issue will be a wider one that just Image handling, so whatever solution we plump for we'll need to tackle these other cases as well. I'm with you on not changing an image (or other objects) state when it's already in a cache. If people don't want this they should turn the cache off or clear the cache or clone things in the cache or whatever they need. OSG has options for that. Right now I made a small modification on my side to osg that (in case the image comes from a cache) makes a dummy image and uses that one to read too. Then discards that image. For the scenes we work with that works but as you said this issue could be wider that only the images. An option in the InputStream and Serializer class to not set any data to an object, or even better to skip parsing the data (but for the latter you would need an end offset for binary files) would be great. It would allow to easily solve these issues when they come up and could potentially be used to do more advanced things later on. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61430#61430 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GeometryTechnique race condition crash
Hi Robert, We too have some trouble with the database pager. It all started after we used DatabasePager::setUpThreads to use more threads. We get memory corruption but only on linux. Tried to use valgrind but then the problem does not occur. We are still in the process of pinpointing it down, some theories I have and it might help you so here are my two cents: - we have some osgb files that reference the same images. We also have some files that use proxy nodes to reference other files because we have some objects that can be build out of subobjects. - What could happen is that the database pager tries to load this referenced image or object and find it in the registry cache. Then it could occur that more database pager threads run the incremental compilation over the same objects. Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61414#61414 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] GeometryTechnique race condition crash
robertosfield wrote: There are some specific .osgb threading issues related to initialization of the wrappers. There is chance that you are hitting up against this. For my own work I'm not currently testing against .osgb and get problems so I believe the .osgb issues can be dealt with separately. We already had this issue and we make sure that we are pre loading all the plugins and serializers we need at program start to avoid this issue. robertosfield wrote: Hi Pjotr, - What could happen is that the database pager tries to load this referenced image or object and find it in the registry cache. Then it could occur that more database pager threads run the incremental compilation over the same objects. The IncrementalCompileOperator only compiles objects from the GraphicsThreads assoicated with teh GraphicsContext and this ensures that for a single context all the GL objects are compiled in series, and duplicates if they exist will be checked to see if they compiling and they've already compiled will be skipped. Given this I don't think there is any danger of multiple entries. What about FindCompileableGLObjectsVisitor, it is run on the pager thread. Is that visitor thread safe? Just had a quick look at it and there are too many different paths in osg code I'm not familiar with to make an assessment for me about thread safety. For example it can call Geometry::setUseVertexBufferObjects depending on the database pager flags, is that method thread safe. Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61416#61416 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Serializer trouble with TextureAttributeList
This could be related to a report I made here http://forum.openscenegraph.org/viewtopic.php?t=13992#60127 Then there are might be two bugs, one is that for osgx files it somehow does not looks in the right directory and two is that it gives a parse error when an image is not found. Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=61011#61011 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] performance issues with Intel. Display Lists and VBOs...
We did some tests with display lists and VBO's. For our scene's usually display lists outperform VBO's because they have less cpu overhead in the draw traversal. There is only one point (which is vendor/driver specific, we use nvidia) is that with models with a large amount of vertices (extract amount depends on other vertex data like normals, colers and uv's) it looks like the driver keeps the data on system memory instead on the gpu if we choose to use display lists. This will kill the performance a lot. In our tests there was a clear threshold value to the amount of vertices where you see this performance changing. But this looks so driver and vendor specific that it should be better to do it the way it is so like Robert said just to individually set the setting for each Geometry. Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=60811#60811 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Disable/enable multisampling per attachment
Hi, According to http://www.opengl.org/registry/specs/EXT/framebuffer_multisample.txt all your attachments need to have the same amount of samples. Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=60798#60798 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-3.3.2 developer release tagged
Hi Robert, A few small bugs I found in the trunk: - loading osgb/osgt files that have references to images that do not exists fail to parse (and sometimes I get a segfault) and the warnings produced are not meaningful at all. - saving classes that derive from osg::Image (like ImageSequece) seem to be broken. Looking into the code this seems to have happened by a rewrite of the image handling code for the scripting interface. I do not know why the rewrite took place and the exact workings of that code so I do not know what I would break by trying to fix it so I haven't tried messing around with that code. Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=60127#60127 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-3.3.2 developer release tagged
I also noticed when profiling a scene with a lot of AnimationPathCallback that dynamic casts make 1-2% of the total execution time (Visual Studio uses strcmp when doing dynamic casts it seems). Almost all of this comes from NodeCAllback::run and Callback::traverse. The question is are all those casts really needed to be dynamic? Also it should be possible to cut that in half by not inheriting from NodeCallback but directly from Callback for the osg classes, or will that break a lot of existing code? Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=60128#60128 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-3.3.2 developer release tagged
No they do not present itself in the 3.2 branch. One thing I just noticed was that osgt files created with the 3.2 branch failed to load in the trunk version. Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=60133#60133 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] OpenSceneGraph-3.3.2 developer release tagged
Pjotr wrote: No they do not present itself in the 3.2 branch. One thing I just noticed was that osgt files created with the 3.2 branch failed to load in the trunk version. Cheers, Pjotr Nevermind the last bit. That was me trying to read the file that I made to test wrong image references. Reading files from 3.2 with trunk works ok. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=60136#60136 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Promoting Drawable from being subclassed from osg::Object to osg::Node
I was trying to save a file to .ive format today but that failed with the message: Unknown node in Group::write(), className()=Geometry So right now it looks like it's impossible to write to .ive files. While osgt/osgb files work I looked at the code and noticed that the osg::Drawable does not have an osg::Node associate which means that node specific fields like _cullingActive and _nodeMask are not saved. Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=59980#59980 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Synchronize animations between different computers
With our distributed rendering setup we don't let the master run till all the clients are connected. From there we send the master's FrameStamp (so frame number, reference time, simulation time and just in case also the calender time) to all the slaves every frame. To manage animations the master also has to send to the slaves when an animation starts or stops. Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=59798#59798 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Promoting Drawable from being subclassed from osg::Object to osg::Node
It only fixed the warnings for set/getUserdata. The warning for the run method still exist. It might be that Microsoft chose to always output this warning. Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=59683#59683 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Promoting Drawable from being subclassed from osg::Object to osg::Node
The warning is still there. Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=59687#59687 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Promoting Drawable from being subclassed from osg::Object to osg::Node
Yes that seems to work. But I think that the warning is meant to inform that you could get unexpected behavior if you don't watch out as explained here (http://stackoverflow.com/questions/11965596/diamond-inheritance-scenario-compiles-fine-in-g-but-produces-warnings-errors) (see last example of http://msdn.microsoft.com/en-us/library/6b3sy7ae(v=vs.120).aspx) Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=59689#59689 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Promoting Drawable from being subclassed from osg::Object to osg::Node
I had to add OSG_EXPORT to osg::Callback and osg::StateSet::Callback to make it compile with visual studio 2013. I did get a lot of warnings about the run method being inherited via dominance from classes like ClusterCullingCallback. But till now everything is working fine here. Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=59662#59662 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Promoting Drawable from being subclassed from osg::Object to osg::Node
The warnings I get are: ClusterCullingCallback.h(12): warning C4250: 'osg::ClusterCullingCallback' : inherits 'osg::NodeCallback::osg::NodeCallback::run' via dominance (..\..\..\..\..\src\osgWrappers\serializers\osg\ClusterCullingCallback.cpp) I:\Libraries\OpenSceneGraphTrunk\include\osg/Callback(168) : see declaration of 'osg::NodeCallback::run' ViewerEventHandlers(540): warning C4250: 'osgViewer::InteractiveImageHandler' : inherits 'osgGA::EventHandler::osgGA::EventHandler::run' via dominance (..\..\..\src\osgViewer\HelpHandler.cpp) I:\Libraries\OpenSceneGraphTrunk\include\osgGA/EventHandler(45) : see declaration of 'osgGA::EventHandler::run' osgsidebyside.cpp(157): warning C4250: 'SwitchDOFVisitor' : inherits 'osg::NodeVisitor::osg::NodeVisitor::getUserData' via dominance I:\Libraries\OpenSceneGraphTrunk\include\osg/NodeVisitor(183) : see declaration of 'osg::NodeVisitor::getUserData' I:\Libraries\OpenSceneGraphTrunk\include\osg/NodeVisitor(180) : see declaration of 'osg::NodeVisitor::getUserData' osgsidebyside.cpp(157): warning C4250: 'SwitchDOFVisitor' : inherits 'osg::NodeVisitor::osg::NodeVisitor::setUserData' via dominance I:\Libraries\OpenSceneGraphTrunk\include\osg/NodeVisitor(177) : see declaration of 'osg::NodeVisitor::setUserData' Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=59664#59664 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Promoting Drawable from being subclassed from osg::Object to osg::Node
License does not really matter. Same terms as the other examples is fine by me. I don't mean to say to just depecrate the drawable callbacks without fixing them. Of course we need to fix them, but we also need to deprecate them to make clear to people that somewhere in the future those callbacks will be removed. Else people might continue using them. Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=59560#59560 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Promoting Drawable from being subclassed from osg::Object to osg::Node
Sure you can adapt and use it as an example. As you can't have a Drawable::UpdateCallback on a osg::Node it sounds weird that Node::setUpdateCallback(Object*) can accept a Drawable::UpdateCallback. What do you do when someone passes a Drawable::UpdateCallback to a Node? I rather have an compile error than a error/warning at runtime. This is what the code does now, except that the syntax to assign a normal UpdateCallback to a drawable is weird which might prevent people from using/discovering it. I think that if you make Node::UpdateCallback virtual this should be resolved, right? Also whats the point of a Drawable::Update/Event/CullCallback now, should't they be deprecated now that a Drawable is a Node and can use the Node's callbacks? Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=59524#59524 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Promoting Drawable from being subclassed from osg::Object to osg::Node
Might moving the logic over to the add/remove parent methods and making special overloads for those methods in the drawable class be a solution? I don't know if it's better at the end but at least this would at least remove the need to have special handling of this in the setChild method (with all those delta's). Btw I also noticed that setNumChildrenRequiringUpdateTraversal has a special check if there is already an updatecallback there should also be a test for a drawable updatecallback somewhere in there, right? However you solve this you will get yucky code. Even both callbacks use the same member variable name _updateCallback which just don't feel right now... I just found a new bug regarding with the callbacks: a osg::NodeCallback as a update callback to a drawable will not be called if the drawable is attached to a geode. Btw I haven't tested event callbacks but those might also not work correctly now. Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=59504#59504 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Promoting Drawable from being subclassed from osg::Object to osg::Node
I made a little testfile with all the permutations of nodes/drawables and
updatecallbacks could come up with. The last two would never come up in old
code and maybe only by accident in new code.
It adds 7 update callbacks.
For me only 4 are called and the parent group says that only 3 children require
update traversal.
Hope this helps.
Cheers,
Pjotr
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=59506#59506
#include osgViewer/Viewer
#include osg/Group
#include osg/Drawable
struct DrawableUpdateCallback : public osg::Drawable::UpdateCallback
{
DrawableUpdateCallback(const std::string message): _message(message) {}
virtual void update(osg::NodeVisitor*, osg::Drawable* drw) {
printf(%s\n, _message.c_str());
}
std::string _message;
};
struct NodeUpdateCallback : public osg::NodeCallback
{
NodeUpdateCallback(const std::string message): _message(message) {}
virtual void operator()(osg::Node* node, osg::NodeVisitor* nv) {
printf(%s\n, _message.c_str());
}
std::string _message;
};
void main(){
osg::Group *root = new osg::Group();
osg::Node *test1 = new osg::Node();
test1-setUpdateCallback(new NodeUpdateCallback(test1));
root-addChild(test1);
osg::Drawable *test2 = new osg::Drawable();
test2-osg::Node::setUpdateCallback(new NodeUpdateCallback(test2));
root-addChild(test2);
osg::Drawable *test3 = new osg::Drawable();
test3-setUpdateCallback(new DrawableUpdateCallback(test3));
root-addChild(test3);
osg::Geode *test4 = new osg::Geode();
osg::Drawable *drawable1 = new osg::Drawable();
drawable1-osg::Node::setUpdateCallback(new NodeUpdateCallback(test4));
test4-addDrawable(drawable1);
root-addChild(test4);
osg::Geode *test5 = new osg::Geode();
osg::Drawable *drawable2 = new osg::Drawable();
drawable2-setUpdateCallback(new DrawableUpdateCallback(test5));
test5-addDrawable(drawable2);
root-addChild(test5);
osg::Geode *test6 = new osg::Geode();
osg::Drawable *drawable3 = new osg::Drawable();
drawable3-setUpdateCallback(new DrawableUpdateCallback(test6));
test6-addChild(drawable3);
root-addChild(test6);
osg::Geode *test7 = new osg::Geode();
osg::Drawable *drawable4 = new osg::Drawable();
drawable4-osg::Node::setUpdateCallback(new NodeUpdateCallback(test7));
test7-addChild(drawable4);
root-addChild(test7);
printf(Numchildren with updates %u\n,
root-getNumChildrenRequiringUpdateTraversal());
osg::ref_ptrosgViewer::Viewer viewer = new osgViewer::Viewer();
viewer-setSceneData(root);
viewer-run();
}
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Promoting Drawable from being subclassed from osg::Object to osg::Node
Hi Robert,
I stumbled on a little bug with the new drawables. I was distributing points
data into different drawables that I used in a LOD later. When simplifying the
system to not use geodes anymore I came upon the following bug:
If Drawable::getBoundingBox would compute an invalid bounding box (if it was
for example empty) it would make a bounding sphere with a infinite radius which
counts as a valid sphere in osg.
Attached is a small fix.
Btw just while writing this post I noticed that the sphere is being set outside
the if(!_boundingSphereComputed){} statement. This means it is set every time
you call getBoundingBox, whats the reason it needs to be outside this statement?
Cheers,
Pjotr
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=59489#59489
Drawable
Description: Binary data
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Promoting Drawable from being subclassed from osg::Object to osg::Node
Hi Robert, While trying to add an update callback to a geometry node that was attached to a lod without using a geode I stumbled upon some bugs: If you use the Drawable::setUpdateCallback method to add a osg::Drawable::UpdateCallback it will not fire because a group does not update it's NumChildrenRequiringUpdateTraversal variable when it has Drawable nodes that have callbacks. If you use the Node::setUpdateCallback method to add a osg::Nodecallback instead it will not fire because the node visitor will stop visiting when NodeVisitor::apply(Drawable drawable) is fired. Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=59495#59495 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Promoting Drawable from being subclassed from osg::Object to osg::Node
I have compiled osg successfully with and without osg_use_bound and everything seems to work with our software. (For the record, I only had to change two lines of code to make our software compile without osg_use_bound) I must say that after thinking about this I share a bit of David concern. I understand the need to do this change. Not only will it make easier to construct scenegraphs, it will also remove a lot of duplicate code (think of update, cull and event callbacks). But right now it only adds more complexity to the code. I think that in the end a solution could be to abandon the use of Geodes and just add drawables to groups directly. That way only a group can have children so the parentlist can be reverted to become a list of groups again. But this will break a lot of code. Another solution would be to have two geometry nodes side by side, one to be used with geodes and one that can be attached to nodes directly. Then have the Geodes and the old Geometry node deprecated so people have time to update the code base. You could for instance in the next osg version deprecate it with maybe a compile time warning, then in the osg version after that also add runtime a warning when these types of nodes constructed and in the version after that just remove them. But this of course will mean we will have a lot of duplicate code for the next few osg versions. By the way, adding drawables to nodes would also degrade performance a bit as drawables attached to nodes will have a boundingbox with a sphere around it making all the parent bounding spheres larger that previously. This won't impact draw performance as at the end osg culls using the bounding boxes but it could impact cull traversal time as it will travel deeper into the tree before it starts to cull out nodes. Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=59425#59425 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Promoting Drawable from being subclassed from osg::Object to osg::Node
Our codebase consists of 350 files (50% are headers). There was only one place where we were using the bounding boxes to draw a box around selected object to highlight them as being selected. So when compiling without osg_use_bound we had to change some getBound calls to getBoundingBox. We of course have more calls to getBound in our codebase but those all deal with Nodes so they do not need to be changed. Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=59432#59432 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Promoting Drawable from being subclassed from osg::Object to osg::Node
A side request, if you plan to keep the Bound struct can it be moved into it's own file? Right now osg/Plane has to include osg/Node for the Bound struct. Because osg/Plane is included by osg/Polytope which is included by osg/State the recompile time increases a lot. In the osg project alone the amount of files that need to be recompiled when changing osg/Node goes from 55 to 102. Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=59436#59436 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Promoting Drawable from being subclassed from osg::Object to osg::Node
I fixed that linker error for myself but didn't commit anything yet as I though
that it was a work in progress. I had to change include/osgUI/Export and
src/osgUI/CMakeLists.txt to make it compile on my system (visual studio 2013).
See the attached files.
Cheers,
Pjotr
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=59442#59442
IF (DYNAMIC_OPENSCENEGRAPH)
ADD_DEFINITIONS(-DOSGUI_LIBRARY)
ELSE (DYNAMIC_OPENSCENEGRAPH)
ADD_DEFINITIONS(-DOSG_LIBRARY_STATIC)
ENDIF(DYNAMIC_OPENSCENEGRAPH)
SET(LIB_NAME osgUI)
SET(HEADER_PATH ${OpenSceneGraph_SOURCE_DIR}/include/${LIB_NAME})
SET(TARGET_H
${HEADER_PATH}/Export
${HEADER_PATH}/Widget
${HEADER_PATH}/Label
${HEADER_PATH}/LineEdit
${HEADER_PATH}/Style
${HEADER_PATH}/AlignmentSettings
${HEADER_PATH}/FrameSettings
${HEADER_PATH}/TextSettings
)
SET(TARGET_SRC
Widget.cpp
Label.cpp
LineEdit.cpp
Style.cpp
AlignmentSettings.cpp
FrameSettings.cpp
TextSettings.cpp
${OPENSCENEGRAPH_VERSIONINFO_RC}
)
SET(TARGET_LIBRARIES
osgGA
osgDB
osgUtil
osgText
osg
OpenThreads
)
SETUP_LIBRARY(${LIB_NAME})
Export
Description: Binary data
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Promoting Drawable from being subclassed from osg::Object to osg::Node
I tested the code in trunk with OSG_USE_BOUND defined and I now get crashes when loading files. After some debugging it looks like expressions like these (see Geode::computeBound() and Group::computeBound()): bb.expandBy((*itr)-getBound()); do not work anymore because the compiler can not know in advance which overload of expandBy to use for the function call. If the wrong overload is chosen a null pointer will be passed to the function resulting in a crash. After changing te lines to: bb.expandBy((const osg::BoundingSphere)((*itr)-getBound())); it crashes later in the cull traversal in CullVisitor::apply(osg::Drawable drawable) because the line const BoundingBox bb =drawable.getBound(); expects a BoundingBox while the Bound wrapper has a BoundingSphere. I have not looked further if there are more places these crashes can occur but after a bit of thinking I must say that Farshid is right about the segfaults and just forcing people to rename their methods is a better solution. Basically if your test suite does not cover your whole code base you could accidentally skip one of these bugs and ship it to customers which would be bad. Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=59404#59404 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New scheme for configuring the OSG for building against different versions of the OpenGL/OpenGL ES
For me osgviewer.cpp and Renderer.cpp were not compiling (visual studio 2013 with profile GL2) because they were still using GLuintEXT. So I changed that, see the attached files. I also noticed that the generated OpenGL header were not copied to the installation directory so my own application could not find it. See the attached files for the proposed fixes. Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=59156#59156 Attachments: http://forum.openscenegraph.org//files/cmakelists_534.txt http://forum.openscenegraph.org//files/renderer_697.cpp http://forum.openscenegraph.org//files/osgviewer_363.cpp ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VertexAttribArrayList serialization
I think the problem with the generated file is that the vertex attributes begin at 6 and the attributes 0 to 5 are null pointers and are not written. Then when reading the reader expects 8 arrays but there are only 2 written so it messes up reading them. I also noticed that, unlike in the osg format there is no way to tell to what attribute number to bind an array. Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=58952#58952 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] VertexAttribArrayList serialization
I'm not familiar with the new osg(t/b) writers (we still use osg and ive here but are also considering a switch) but looking at the commit log there was a change in the revision 14099 that added a new way to serialize arrays to support the lua plugin which seems to change the layout also. Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=58957#58957 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Deprecating vertex indices in osg::Geometry
Hi Robert, I tried out your code and it won't load a lot of geometry files even if they are using fast path. The problem lies in that with the old Geometry::ArrayData structure you could first set the binding and then the array. Now you are forced to do this the other way around. The ive reader (ive::Geometry::read) for instance always first sets the binding and then the data. And for .osg files it depend on how you structure your file. Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54653#54653 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Deprecating vertex indices in osg::Geometry
Hi Robert, Reading ive files works. Only reading .osg files that contain vertex attribute arrays does not work yet. (both the binding and the normalization can be set before the array itself right now). Cheers, Pjotr robertosfield wrote: Hi Pjotr, Could you do an svn update, rebuild and then report how your models load, hopefully the changes I've made will address the issue. Cheers, Robert. ___ osg-users mailing list http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Post generated by Mail2Forum -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54658#54658 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] osg::Text setText - changing text during rendering - What is the correct way to change the text in osgText::Text?
Hi, Have you set the datavariance of the text to dynamic? Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54557#54557 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Warning messages VS2012...
Hi, This is actually an issue with the visual studio 2012 library, see here for an explanation: http://connect.microsoft.com/VisualStudio/feedback/details/733720/ Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=54332#54332 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] How to render without a depth buffer ?
Hi, Have you tried camera-setImplicitBufferAttachmentMask(osg::Camera::IMPLICIT_COLOR_BUFFER_ATTACHMENT); Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=52975#52975 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] osgFX question
Hi, We recently converted our stereo viewer to cull the scene graph in parallel. But now we are having a crash with some models that have bump mapping effects on them. The crash happens in Effect::traverse because both threads try to add new techniques. Is there a reason this is done during the cull traversal? From my first scan through this code it looks like this can also be done earlier, like in the constructor of the Effect class. Or will this break other code I'm not aware off? Anyone familiar with that piece of code who can shed some light on this issue? Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=51348#51348 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Multithreading Culling problems
We had a similar issue. We had a stereo rendering setup that used slave camera's to render the scene. The only thing the main camera did was to swap the buffers. Whats happened is when you do anything that will get bounding boxes of nodes invalidated, if you don't recalculate those they will be recalculated at cull traversal. But in multithreaded mode this is done in parallel and it will lead to flickering because of a race condition. What you can do is call the getBound method on your root node after the update traversal, just before the rendering traversal. After some investigation it turned out this is already done at the beginning of ViewerBase::renderingTraversals() but in our case we had a empty scenegraph attached to our main camera because it did not render anything. So the getBound method was not called on our actual scene. Seeing as you also render to textures and only display those, it could be that you also have some custom scenegraph going on and the bounding boxes are not calculated on the right scenegraph. Hope this helps! Cheers, Pjotr -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=50380#50380 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
