Hi everybody, long time no see!
I'm in the process of upgrading my development environment to new tools and
libraries. All my OSG-based applications still use OSG 1.2, so I'm now
switching them to the latest version of OSG in SVN. Some of them use my own
viewer library (which in turn uses
setenv OSG_WINDOW '0 0 1280 1024' (or equivalant)
osgviewer --window 0 0 1280 1024 cow.osg
osg-users mailing list
Another possibility I missed is the use of doubles in osg::Plane by
default, whereas 1.2 used float by default in osg::Plane.
thanks for the hint. However, I think the problem could be related to the
compile/apply of GL objects instead. If I disable the GLObjectsVisitor that
threading problems apparent in 1.2 the OSG-2.x versions initialization
the GL objects arrays to a larger default, if you app isn't setting
the number of context down to the number you are using then perhaps
this is where the discrepancy is occurring.
My viewer is already
Err, are you sure about that last one? SVN OSG cannot use the same 3rd
party libs as 1.2 (at least, if you used the 3rdParty libs zip that was
downloadable from the OSG site). In particular, there were some changes
in osgText that made it incompatible with the version of freetype that
Have you tested with --SingleThreaded option ? In my configuration
multithreaded configs usually eat more RAM. However its not twice as in
I'm using my own single-threaded viewer, so I don't even have to choose. :-)
I have read somewhere that NVidia OpenGL dirver
For now I'm ujst putting some logging code in OSG 1.2 and 2.3 to show the
number of compiled GL objects, which I suppose should be the same in both
versions. I'll let you know if I find any discrepancies.
Here are the results: upon firing the GLObjectsVisitor, the app built with
OSG 1.2 calls
It's a bit of long shot, but you could have a look at what the
osgUtil::Optimizer is doing with the data, perhaps OSG-2.x is being
more conservative with collapsing duplicate state.
Thanks, precious hint. I've just finished diff'ing the log messages emitted
else// - ADDED this block
So yes, UNSPECIFIED help solve the problem of deciding what data variance an
StateAttribute should have, if the user has explicitly set STATIC or DYNAMIC
then this is a formal decision made by the user and its inappropriate to
override this with automatic codes that try to work
I'm looking for feedback from users who have worked on clusters that
implement some forms of swap ready synchronization. In particular I'm
looking at any hooks into osgViewer to allow users to implement their own
swap ready implementation, also a software based swap ready could
I've just upgraded OSG from version 2.4 to latest SVN. As a result, I've lost
multitexturing on all objects imported via the LWO plugin.
According to the SVN log, a change in osgPlugins/lwo/Surface.cpp was committed
on behalf of Bob Kuehne on 18th June 2008. Reverting that change
Its really weird. I am pretty much sure we have tested this with Vista
but maybe not the latest drivers. May I send you simpified OpenGL only
I have sent to NVidia as a bug report ? I am curious if the crash will
happen with it as well ?
Sure, I'm glad to help.
your test case behaves exactly as osgViewer does. The app crashes when
wglMakeCurrent() gets called for the second time. Setting repeatMakeCurrent
to 0 fixes the crash.
One thing I forgot to say, is that it doesn't always crash: the
success/failure ratio is about 1 to 15. This
I'm trying to add multisampling capabilities to my floating-point FBOs, but
I've found what I think is a bug in osgUtil/RenderStage.cpp. Basically, when
I specify a number of samples greater than 0, I actually get a
See line 380 in RenderStage.cpp:
[...], or perhaps if it's 0 then
RenderStage.cpp code to look for an alternative as a fallback - first
it could check for a texture, then finally drop back to RGBA.
Yes, that's basically what my fix does.
Send me the changed file and I can pontificate on this. Could you
Mail list logo