constructor issues:
Within the NullStream & NotifyStream classes the base class objects
(ostream) were being initialised before the class member _buffer objects
which they referenced, causing a crash.
I had to move the file scope g_NullStream & g_NotifyStream initialisation
into a function to get them to work.
Also there was a missing osg:: qualifier on getNotifyHandler."
This makes it possible to redefine the viewing direction of 'home' in the other manipulator - so home in a GIS app could be a plan view.
Since _homeUp is set to (0,0,1) and no current code changes it there shouldn't be any difference for current users."
-Changed the addition of lights to add the lightsource directly into the scenegraph (instead of below a switch node)
-All added lights are enabled in the root stateset and replace the head- or skylight.
(if no lights are available the head- or skylight will remain active)
-Ambient in osg::LightModel is zeroed out. All ambient now comes from separate ambient only light sources.
-Lights can now be written properly
-Replaced strings by constants defined in the Collada DOM"
The fix is to remove the call to bs.expandBy(v) and compute the radius directly. I believe this call was intended to be bs.expandRadiusBy(v), but it is superfluous when the radius is computed directly."
Two implementations of NotifyHandler are currently available:
- StandardNotifyHandler, calls fputs(message, stderr) for severity <= WARN and fputs(message, stdout) for severity > WARN
- WinDebugNotifyHandler, windows users can redirect notifications to windows debug output, notifications can be viewed in output window of the debugger i.e. MSVC or DebugView (http://technet.microsoft.com/en-us/sysinternals/bb896647.aspx) (see screenshot).
I have seen on osg-users that some people do std::cerr.rdbuf(otherStream.rdbuf()) to redirect notifications. This trick will no longer work since osg::notify() returns internal osg::NotifyStream not std::cout or std::cerr. You can use osg::notify().rdbuf(otherStream.rdbuf()) to do this instead.
Additionally I've made some minor fixes:
- Minor imrovements to osg::notify documentation
- NullStream could crash by deleting stream buffer other than default NullStreamBuffer in the destructor i.e. after osg::notify(osg::DEBUG_FP).rdbuf(otherStream.rdbuf())"
The changes are more or less just beautifications
(when looked at them from the C++ view), but make
wrapping OSG with SWIG easier.
I have tested the changes with both 2.8.1-rc4 and the
current head and would appreciate to incorporate the
changes in both branches.
Here is a description of the changes:
osg/BoundingSphere:
Use the following typedef (like used in BoundingBox)
typedef typename VT::value_type value_type;
instead of
typedef typename vec_type::value_type value_type;
SWIG reports errors on the latter construct.
Also makes it consistent with BoundingBox.
osg/Vec4ub:
Consistent use of "value_type" throughout the file.
osg/Vec?b:
Consistent use of "value_type" throughout the files.
Also changed
typedef char value_type;
to
typedef signed char value_type;
In the case of a simple "char", SWIG assumes a string.
Using "signed char" instead of "char" does not change
the behaviour of the class.
"
Windows doesn't define F_OK and access() is in io.h, rather than stdio.h
These are fixed in FileUtils.cpp, so I copied the fix from there - might be better to move this to FileUtils header and include it here and in FileUtils.cpp?"
implementation of GraoicsWindowCocoa:
Enhancements/Bugfixes:
+ now it's possible to integrate osgViewer better into existing
cocoa-applications:
* create one or more NSOpenGLView(s) and add these to your window(s)
* create one or more NSWindows
* disable the integrated event-polling of osgViewer, and let the work be
done by Cocoa / NSApplicationRun. You'll have to run the osgViewer's
runloop in a separate thread
+ missing menu-event-handling implemented
+ added NSAutoReleasePools where necessary, this fixes some memory-leaks
+ fixed some crashes and thread-issues"
