- 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.
"
says that modules that are found and ran from cmake modules dir should
prefer cmake-provided modules. find_package() and include() still look
in CMAKE_MODULE_PATH first.
After some investigating I've come up with a proposal examplified in
the attached FindGDAL.cmake script. It simply calls the cmake provided
FindGDAL.cmake if it exists and returns if it succeeds in finding GDAL
using that, otherwise continue with our local cmake code.
Pro: Wont clutter our root CMakeLists.txt
Con: If we begin to write more advanced Findxxx modules (using
COMPONENTS, REQUIRED etc.) we may have to revise this scheme.
"
To select standard OpenGL 1/2 build with full backwards and forwards comtability use:
./configure
make
OR
./configure -DOPENGL_PROFILE=GL2
To select OpenGL 3 core profile build using GL3/gl3.h header:
./configure -DOPENGL_PROFILE=GL3
To select OpenGL Arb core profile build using GL/glcorearb.h header:
./configure -DOPENGL_PROFILE=GLCORE
To select OpenGL ES 1.1 profile use:
./configure -DOPENGL_PROFILE=GLES1
To select OpenGL ES 2 profile use:
./configure -DOPENGL_PROFILE=GLES2
Using OPENGL_PROFILE will select all the appropriate features required so no other settings in cmake will need to be adjusted.
The new configuration options are stored in the include/osg/OpenGL header that deprecates the old include/osg/GL header.
- ReaderWriterFBX.cpp: add "z up scene axis" support: FBX provides facility to convert model scene axis during conversion. Currently fbx plugin convert axis to fbx:opengl axis system (which is arbitrarily at Y up, as opengl is in reality axis agnostic) and sometimes what is needed is Z up so added an option for Z up conversion
- FindFBX.cmake: add support for latest fbx sdk ( 2014.2 )"
Using the trunk together with osgEarth 2.5 will fail to build, due to the missing type.
Attached is the file forward declaring osgGA::GUIEventAdapter."
format. Turned out that the serializer didn't handle bone names with
spaces very well (the 3ds studio max biped for instance has spaces by
default). Here is a small fix for the problem."
- materialName used to be not stripped of whitespace, making number of models
fail to load materials; now fixed
- stripping was considering spaces only, thus models using tabs had problems
to load correctly; fixed
- fixed references to textures; they did not performed conversion to native
directory separators
- make d (dissolve) takes precedence over Tr (transparency); there seems to be
a confusion about the Tr item - some claiming 1 to be opaque and 0
transparent, while number of models uses exactly the opposite. d (dissolve),
if present in the model, does not suffer from this confusion, thus using it
instead fixes the problem for many many models.
I put many comments to the file concerning d and Tr item as others may further
investigate. Let me know in the case of any problems."
This behavior is also described in the pthreads man page (http://man7.org/linux/man-pages/man3/pthread_create.3.html):
>
> Linux-specific details
> The new thread inherits copies of the calling thread's capability
> sets (see capabilities(7)) and CPU affinity mask (see
> sched_setaffinity(2)).
>
To prevent this behaviour I wrote a patch that explicitly sets the affinity mask to all cores of the system, if no specific affinity was defined with PThread::setProcessorAffinity(unsigned int) .
Thank you!
"
