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."
- Added apply(Drawable) and apply(Geometry) to NodeVisitor
- Added accept(NodeVisitor) method to Drawable/Geometry
- Added traverse(NodeVisitor) to Geode which calls accept(NodeVisitor) on all Drawables
- Updated CullVisitor to use new apply(Drawable) to handle drawables. The apply(Billboard) method still manually handles the drawables since it is depends on the billboard settings. I needed to disable the traverse within billboard to prevent duplicate traversal of drawables.
- Update other osgUtil node visitors (GLObjectsVisitor, IncrementalCompileOperation, ..) to use new apply(Drawable) method.
"
pd->tid.set( (void*)_beginthreadex(NULL,static_cast<unsigned>(pd->stackSize),ThreadPrivateActions::StartThread,static_cast<void *>(this),0,&ID));
the method "pd->tid.set" sets the thread id, however via the startup function "ThreadPrivateActions::StartThread" that thread id is used (see further down the call hierarchy the line "int status = SetThreadPriority( pd->tid.get(), prio);".
Until now I never ran into any problem in debug or release builds, though. It seems that furtunately the tid.set method was executed always before the tid.get method in the startup code. However, this may make trouble in the furture. A simple solution is the following: just replace the line above with following two lines:
pd->tid.set( (void*)_beginthreadex(NULL,static_cast<unsigned>(pd->stackSize),ThreadPrivateActions::StartThread,static_cast<void *>(this),CREATE_SUSPENDED,&ID));
ResumeThread(pd->tid.get());
The trick is just starting the thread in suspended mode so the StartThread function does not get executed and we can safely store the tid by pd->tid.set. Then start the Thread by calling ResumeThread."
ran into two issues.
At first you get a bunch of warnings that osg::ComputeBoundCallback
and osg::UpdateCallback were unsupported wrapper classes when
converting fbx models with skeletal animation to osg(t/b).
The second issue was that when reading, the readers fail to read the
ComputeBoundCallback and UpdateCallback and set them to NULL which
messes up the RigGeometry.
Because a RigGeometry makes his own classes in the constructor it
might be preferable to not write them at all, because now those
classes are being made two times when reading a RigGeometry. But after
thinking about this that would place too much limits on them (you
won't be able to share or name them and save that information or make
a new inherited class from them and write that one) So I ended up
thinking the best way was to just write the files.
"
attributes in vec3b format. It looks like my compiler takes the wrong
overload and outputs integers instead of characters. The problem is
that vec3b is of type signed char and that is not the same as char (
see http://stackoverflow.com/questions/436513/char-signed-char-char-unsigned-char
) and visual studio 2013 will promote it to integer when choosing an
overload.
It looks like that the InputStream class already takes care of this
issue (if it didn't it would have read everything ok and I would have
not even stumbled upon this bug. :) )"
Currently this submission is Windows-only. I don't think OSX or Linux require any help in locating gl/glcorearb.h. But if they do, this submission can be easily modified.
Files:
- "CMakeLists.txt" is the top-level file.
- FindGLCORE.cmake" and "OsgMacroUtils.cmake" go in CMakeModules.
"
We were running into issues occasionally in osgEarth where multiple threads were writing out files like /1/2/3.jpg and /1/3/4.jpg. Both threads would try to create the /1 directory and only one of them would succeed. So the first thread would write out the full /1/2/3.jpg while the second thread wouldn't create the /1/3 directory b/c /1 was already created and the writing of /1/3/4.jpg would fail.
"
There was code in the osgViewer/Viewer.cpp and osgViewer/CompositeViewer.cpp that transformed the Y-coordinates of an event. The code in the composite viewer did however miss the touch-data of the event. I thought that it should really be the GUIEventAdapter that should know about this, and hence I added the
GUIEventAdapter::setMouseYOrientationAndUpdateCoords which is re-computing the coordinates. First I simply added a boolean to the setMouseYOrientation function:
setMouseYOrientation( MouseYOrientation, bool updatecooreds=false );
but then the serializer complained.
This function is called from both the Viewer and the CompositeViewer. We have not tested from the viewer, but I cannot see it would not work from visual inspection.
The other change is in MultiTouchTrackballManipulator::handleMultiTouchDrag. I have removed the normalisation. The reason for that is that it normalised into screen coordinates from 0,0 to 1,1. The problem with that is that if you have a pinch event and you keep the distance say 300 pixels between your fingers, these 300 pixels represent 0.20 of the screen in the horizontal domain, but 0.3 of the screen in the vertical domain. A rotation of the pinch-fingers will hence result in a zoom in, as the normalised distance is changing between them.
A consequence of this is that I have changed the pan-code to use the same algorithm as the middle-mouse-pan.
The rest of it is very similar from previous revision, and there has been some fine-tuning here and there.
"
