and TabPlaneDragger.cpp:
TabPlaneDragger(float handleScaleFactor=20.0f);
The reason for this is that the default OSG tab sizes are way bigger than
those we used in our application so far. And since handleScaleFactor_
is already a (constant) class member, I see no objection against making
it user defined."
indexed draws instead of plain array draws to save some amount of main memory.
Draw performance does not change with the nvidia binary blob as well as with
the open source drivers."
- add non square matrix
- add double
- add all uniform type available in OpenGL 4.2
- backward compatibility for Matrixd to set/get an float uniform matrix
- update of IVE / Wrapper ReadWriter
implementation of AtomicCounterBuffer based on BufferIndexBinding
add example that use AtomicCounterBuffer and show rendering order of fragments,
original idea from geeks3d.com."
1) they use direct link to texture
-> this is already handle by current plugin : OK
2) they defined colors with only 3 color components
-> it leads to a crash when trying to acces to the fourth component
I fixed that
3) they contain empty primitive lists
-> reading is ok, but osgviewer crashes when trying to display the geometries
The reason is that osg assume that DrawElementsare never empty (blunt acces to DrawElements.front() in PrimitiveSet.cpp)
I corrected this (on the plugin side), but I wonder :
Is it the responsability of plugins to create non empty DrawElements, or of osg core not to crash when they occur ?
If the responsability is on the osg core side, I can submit a patch to PrimitiveSet.cpp regarding that aspect.
4) they use a material binding scheme not supported by the plugin
->I've implemented a mechanism to handle this binding scheme
You will also find in the patch an example of these evil dae and comments on the offending elements.
They seems to be produced by ComputaMaps (www.computamaps.com)
They load well in Google Earth
"
the following error:
Users/stephan/Documents/Projekte/cefix/cefix/ios/../../libs/ios/include/OpenThreads/Atomic:244:48:
error: cannot initialize a parameter of type 'void *' with an lvalue of
type 'const void *const'
return __sync_bool_compare_and_swap(&_ptr, ptrOld, ptrNew);
This can be solved by a cast to '(void*)ptrOld'. This should be benign since both
'ptrOld' and 'ptrNew' are only read and the cast is in fact in place for all other
implementations as well.
On OS X the cast compiles cleanly on both g++ (i686-apple-darwin11-llvm-g++-4.2 (GCC)
4.2.1) and clang++ (Apple clang version 3.1 (tags/Apple/clang-318.0.54)).
"
IF(${CMAKE_OSX_SYSROOT} STREQUAL "/Developer/SDKs/MacOSX10.7.sdk")
...
ELSEIF(${CMAKE_OSX_SYSROOT} STREQUAL "/Developer/SDKs/MacOSX10.5.sdk" OR ${CMAKE_OSX_SYSROOT} STREQUAL "/Developer/SDKs/MacOSX10.6.sdk")
...
ELSEIF(EXISTS /Developer/SDKs/MacOSX10.4u.sdk)
...
ELSE()
...
ENDIF()
Which is fragile because XCode could be installed into another directory than /Developer. (In case XCode is not installed into the /Developer directory CMake can automatically resolve the path via command line utility ${CMAKE_XCODE_SELECT} --print-path)
This issue bites me currently because the latest XCode (Version 4.3.1 - 4E1019) installed through the Mac App Store is per default installed in "/Applications/Xcode.app/Contents/Developer" and hence the 10.7 SDK in "/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk"
Searching the web to find the proper way to determine the version of the Platform SDK programmatically, I found no standard way. I came up with 2 options myself:
1) Parse the path string to extract the version number
2) Read a value from the SDKSettings.plist found in the root of each SDK (e.g., "defaults read ${CMAKE_OSX_ROOT}/SDKSettings.plist CanonicalName" gives "macosx10.7")
I implemented the last option and verified that at least the following Mac OS SDKs (10.3.9, 10.4, 10.5, 10.6, 10.7) support this method. It also looks reasonably future proof. An additional benefit of this method is that it also seems to be compatible with iOS and iOS Simulator SDKs (at least for version 5.1, but I assume this also applies to older versions). This is interesting because the CMake infrastructure to build OSG for iOS currently still contains similar hard-coded paths and even requires you to manually change the cmake file to build for another iOS SDK version. In the near future I hope to address these issues, but I haven't been able to try this yet."
viewMatrix.makeLookAt(frustum.center+positionedLight.lightDir*zMin, frustum.center, lightUp);
to
viewMatrix.makeLookAt(frustum.center+positionedLight.lightDir*zMin, frustum.center+positionedLight.lightDir*zMax, lightUp);
The reason I've done such a change is that for huge scenes like a city on the earth, the values of frustum.center can be extremely large, but zMin may be very small (e.g., when model depth in light coords equals the model radius by chance) in some cases so the result of (eye - center) might jiggle while moving around the shadow scene and thus make the shadow map suddenly disappear some time. The small change here also considers the effect of zMax to avoid such problems.
"
I have also made changes to the RotateCylinderDragger to provide a cylinder ring with a thickness. It is totally optional, but IMHO makes the default behavior work better than a solid cylinder (which typically obscures the geometry you are trying to drag). Gives it a bit more to grab, especially in the case where eyepoint and cylinder axis are near parallel.
"
Now examples/osgmultitouch really works ;-)
Based on yesterdays trunk.
* It should now work with all Visual Studio Versions.
* WIN_VER is left as-is
* I added the missing declarations from a recent SDK, if not supplied by the SDK
* If someone chooses to update WIN_VER, the declarations should not break.
* All API Calls are runtime detected.
* No CMake Variable, Support is enabled automatically ."
If an object is comming with texture and NULL image, the texture atlas builder crash when sorting textures according to texture height.
The fix is to skip textures with NULL image when inserting textures in the builder texture list.
"
* If the eyepoint and cylinder axis are close to parallel (given some tolerance), then it uses a plane perpendicular to the cylinder axis.
* Otherwise it uses a plane parallel to the cylinder axis oriented towards the eyepoint (previous behavior). This gives decent behavior and is the only path that was taken in the previous code. I kept with previous behavior and that allowed a good bit of code to be removed, simplifying things. There is now no need for the _onCylinder flag, but since there is a public accessor, I wasn't sure how to handle it for backwards compatibility, so I left it in. NOTE - there is no default initialized value, so if it is kept in, it should be set to 'false' to keep same behavior as before. I am not quite sure how the _onCylinder case was supposed to behave as even forcing that path gave undesirable behavior, even with carefully controlled dragging.
"
- correction to writeFace : the fourth point was defined with an incorrect code (http://www.autodesk.com/techpubs/autocad/acad2000/dxf/3dface_dxf_06.htm)
- if no layer name was found, an empty string was used, with is incorrect according to dxf specifications and was rejected by Autodesk DWG TrueView
- the plugin was writting polygons and triangles as LINE, as if PolygonMode GL_LINE was active, and didn't use 3DFACE primitive.
I changed this behaviour to write 3DFACE as default, and LINE when PolygonMode GL_LINE is active.
when reading back the file with osg, the result is now consistent with the source
Tested with osg plugin, FME (Safe software), Autodesk DWG TrueView
"
Here's a summary:
* Uses a separate ZIP file handle per thread
* Maintains a single shared (read-only) index, created the first time through
* Stress-tested with the DatabasePager using 24 threads under osgEarth
I also updated the member variables to use OSG's leading-underscore convention."
CLAMP all textures using only texcoord between [-0.001 1.001] to give a
chance to create an Atlas.
If the atlas creation failed for other reason (texture size, only one
compatible texture, ...) the texture remain modified in CLAMP mode.
But if you use texcoords between [0.0 1.0] using CLAMP mode instead
REPEAT it is not safe because you will have a blend to the border color
at extremities.
If we want to have exactly the same rendering after changing mode from
REPEAT to CLAMP we should use the CLAMP_TO_EDGE mode instead of CLAMP to
avoid blending to border color at extremities.
Please find as attachment the proposed patch against latest svn version.
"
state.applyTextureMode(0,GL_TEXTURE_2D,osg::StateAttribute::ON);
into the #if defined(OSG_GL_FIXED_FUNCTION_AVAILABLE) block to solve problems under GLES and GL3.x/GL4.x
Bug description:
Let's say we have class A
namespace Bug
{
class A : public osg::Object
{
public:
//...
typedef std::vector<osg::ref_ptr<A> > AList;
protected:
AList _alist;
//...
}
}
REGISTER_OBJECT_WRAPPER( A,
new Bug::A,
Bug::A,
"osg::Object Bug::A" )
{
ADD_LIST_SERIALIZER(A,Bug::A::AList);
}
Bug:
We create say 3 instances of class A: A1,A2,A3 and then we add A2 and A3 and A1 as child instances of A1 so we get next structure:
A1
|- A2,A3,A1
we call osgDB::writeObjectFile(A1,"/data/a.osgt") -> saved correctly( third element in list is saved as unique id that references parentClass
now we call
A1 = osgDB::readObjectFile("/data/a.osgt");
Everything is deserialized correctely except last element in list which should be same instance as parent A1.
The attached code resolves this issue by passing UniqueID in readObjectFields method and saving object in _identifierMap as soon as we have valid object instance so we can make reference to parent object from any child instance.
"
I added AFAIK proper defaults for several Macos X Version API targets.
* In order to determine which defaults to apply, consult the CMAKE_OSX_SYSROOT variable pointing to the used SDK, not the pure existence of an SDK.
* Defaults are now:
10.7: Support Intel 32 and 64 Bit Cocoa with imageio picture reader
10.6 + 10.5: Support Cocoa with imageio on Intel and PowerPC
10.4: Carbon, Quicktime and PowerPC
Now OSG compiles out of the box for MacOSX 10.7. , tested with gcc and clang with FlightGear."
which simply set by default the internal pixel format to GL_RGB32F_ARB where appropriate.
In the current version there's a comment saying that the plugin set it to GL_RGB8 (even when reading from float) to support old graphics cards,
but the comment dates back to 2004...
What's more I believe that it's correct to expect a floating texture format if you're loading an hdr image.
It was quite troublesome for us to discover why our background image wasn't showing hdr data...
In case you accept the submission, I've removed the comment as it would be misleading to leave it there."
Without the change the application does not work properly. First I get the notification that an OpenGL error occured. After some more of this error messages I see broken textures on the screen. With the changes attached to this message my application works as intended."
Note from Robert Osfield, changed the Image::supportsTextureSubloading() to be const and to be implemented in the .cpp rather than inline.
(http://gta.nongnu.org). This allows to read and write floating point
image data. Unlike other formats, GTA also allows very good compression
ratios for floating point data. The compression method can be selected
with the COMPRESSION option of the plugin.
"
Here's another small submission for IOS, which adds unique ids to the
touchpoints, so the ids stay the same during a touch-sequence.
(and some minor code enhancements)"
working on some junk low-end graphics cards which I still have to
support. They worked ok with osg 2.8 and earlier.
The problem turned out to be with gl proxy textures, which are
unreliable on those devices. Proxy textures are used by the glu
mipmap build routines to determine if a texture size is
supported. The external glu library had a nice fallback
behaviour, so that if proxy textures didn't work then the mipmap
texture was still created. But in the work on the new embedded
glu routines that fallback behaviour has been inadvertently
lost. I have restored the fallback in
src/osg/glu/libutil/mipmap.cpp. It doesn't add any extra
complexity."
find attached my modifications to osgfilecache.
It now allows also the caching of LOCAL terrain databases. In combination with the extends and level cmd parameter it allows to extract parts of terrain databases and write it in a new "Sub database".
I also modified osgDB::FileCache to create correct filenames if the data source is local."
OpenSceneGraph-3.0.1/src/osgPlugins/xine/video_out_rgb.c:2772:25:
error: ?video_driver_class_t? has no member named ?get_identifier?
OpenSceneGraph-3.0.1/src/osgPlugins/xine/video_out_rgb.c:2773:25:
error: ?video_driver_class_t? has no member named ?get_description?
This has been reported on Gentoo: https://bugs.gentoo.org/397643
The relevant commit to the xine-lib repository is
http://anonscm.debian.org/hg/xine-lib/xine-lib-1.2/diff/806b590a4d38/src/xine-engine/video_out.h
This change addresses the issue. I'm sending the full modified file as
an attachment. It is based on the 3.0.1 release of OSG. I'll also paste
a diff below. You will find a colorized view in the Gentoo bugzilla.
The xine-lib API changed in the following way: the identifier and
description members are now "const char*" strings instead of "char*
(*)(video_driver_class_t*)" getter function. As the functions in the osg
plugin will always simply return a string literal, without accessing
their argument, it is safe to simply call them with a NULL argument and
use the returned string. This makes it easy to support both API
versions. When you drop support for older xine one day, you might want
to move the string literals to the assignment, getting rid of the
functions in the process.
The modified code compiles for me. I'm not sure how to test it, as I've
only got OSG around in order to build (and hopefully one day even use)
Flightgear.
I'm assigning my copyright in this change to the osg project leads.
"
auto-rotated (e.g. HUD text) is not always correct, because it
doesn't take account of the base line offsets added by the
various alignment options such as CENTER_TOP, CENTER_BOTTOM etc.
The attached src/osgText/TextBase.cpp fixes the problem."
I have attached a correction to daeRTransforms.cpp based on trunk at [12892] which corrects this problem.
This is the changed section:
Code:
if (scale.x() == scale.y() && scale.y() == scale.z())
{
// This mode may be quicker than GL_NORMALIZE, but ONLY works if x, y & z components of scale are the same.
ss->setMode(GL_RESCALE_NORMAL, osg::StateAttribute::ON|osg::StateAttribute::OVERRIDE);
}
else
{
// This mode may be slower than GL_RESCALE_NORMAL, but does work if x, y & z components of scale are not the same.
ss->setMode(GL_NORMALIZE, osg::StateAttribute::ON|osg::StateAttribute::OVERRIDE);
}"
I guess the previous behaviour of giving the cwd precedence over any path configured in the "database path list" (osgDB::Options) wasn't intentional. Otherwise, if it was intentional after all, it'd be good to add another feature instead, to make this configurable - e.g. a flag in osgDB::Options to disable this, if an application doesn't want the cwd being considered.
"
Note from Robert Osfield, this submission will change the default behaviour of searching for files so can potentially break existing applications as it
won't search the current working direction unless it's included in the DataFilePathList entry in the Options or Registy. I'll add a follow
up submission to add back in this feature.
"I've made a few changes to osgUtil::PolytopeIntersector so that it
actually uses double precision floating point numbers everywhere (as
long as OSG_USE_FLOAT_PLANE is not defined).
I needed double precision intersections in a project I am working on.
These changes fixed the problems I was having -- this is all testing I
have done.
Notice that I have changed
osgUtil::PolytopeIntersector::Intersection's members to use doubles
(osg::Vec3d, instead of osg::Vec3). I could have added #ifdef's there
too, but I think it is better to not change the types of stuff in the
public interface depending on some preprocessor definition.
The modified files are attached. A diff also follows, for those who like it."
With the following changes from Robert Osfield:
"I've just reviewed your changes and have just tweaked them a little to
streamline them. What I have done in the PolytopeIntersector header
is add:
typedef osg::Plane::Vec3_type Vec3_type;
And then use this typedef in the definition of the vertices rather
then Vec3d as you did. Next changes were to PolytopeInteresector.cpp
where to the PolytopeIntersectorUtils defintions of the Vec3_type, and
value_type which now simply read:
typedef osg::Plane::Vec3_type Vec3_type;
typedef Vec3_type::value_type value_type;
This way I was able to complete avoid any if def's and have essential
the same implementation as you achieved. Changes now checked into
svn/trunk."
retessellatePolygons was applying the winding and boundary option.
Moved the gluTessProperty calls into beginTessellation().
There's a comment typo fix, removing an unused VertexPointList
typedef, and allocates one _tobj instead of one per tesellation.
Protections were added to check that _tobj was allocated in the few
remaining places it wasn't being checked.
---
On a side note, I would like to avoid the 'new Vec3d' in
Tessellator::addVertex for each call to
gluTessVertex(tess, location, data).
The RedBook leaves it ambiguous if the location pointer must
remain valid after gluTessVertex or not.
http://www.opengl.org/sdk/docs/man/xhtml/gluTessVertex.xml
says that changing location is not safe, so being conservative, I'll
leave it as is, even though the Mesa GLU library copies the data not
the pointer, so it is currently safe."
"Currently issuing a mouse scroll DOWN event would stop updating
animations in progress.
The fix consists of changing the line
us.requestContinuousUpdate( false );
to:
us.requestContinuousUpdate( isAnimating() || _thrown );
in OrbitManipulator::handleMouseWheel() as has been done for the
GUIEventAdapter::SCROLL_UP case a couple of lines earlier or in
src/osgGA/FirstPersonManipulator.cpp."
Copying user objects was missing."
Note from Robert Osfield, in submission changed
_objectList.push_back((*itr)->clone(copyop));
to
_objectList.push_back(copyop(*itr));
and makes the glyphs aspect ratio match their 12x8 bitmaps.
I am not exactly sure about osgTexts current internals but it matches the
changes that happened lately to the txf font.
"
the global locale was generating bad dot files. Specifically, the node
numbers had comma separators in them (like 1,234 rather than 1234).
The attached file simply forces the stringstreams used to build up the
dot file to use the "C" locale."
- apply() and reset() methods made virtual to allow overriding
- added apply(StateSet&) to make more easier to gather StateAttribute
statistics in user-derived classes
"
I found that some of the items that had been paged in were being expired on the first frame that they were not visible (as the cache was full). This resulted in excessive paging every time the view was moved. With the following changes I could only allow children to be expired if they had not been used for e.g. 30 seconds or 60 frames."
10.6), which will forward all multi-touch events from a trackpad to the
corresponding osgGA-event-structures.
The support is switched off per default, but you can enable multi-touch
support via a new flag for GraphicsWindowCocoa::WindowData or directly
via the GraphicsWindowCocoa-class.
After switching multi-touch-support on, all mouse-events from the
trackpad get ignored, otherwise you'll have multiple events for the same
pointer which is very confusing (as the trackpad reports absolute
movement, and as a mouse relative movement).
I think this is not a problem, as multi-touch-input is a completely
different beast as a mouse, so you'll have to code your own
event-handlers anyway.
While coding this stuff, I asked myself if we should refactor
GUIEventAdapter/EventQueue and assign a specific event-type for
touch-input instead of using PUSH/DRAG/RELEASE. This will make it
clearer how to use the code, but will break the mouse-emulation for the
first touch-point and with that all existing manipulators. What do you
think? I am happy to code the proposed changes.
Additionally I created a small (and ugly) example osgmultitouch which
makes use of the osgGA::MultiTouchTrackballManipulator, shows all
touch-points on a HUD and demonstrates how to get the touchpoints from
an osgGA::GUIEventAdapter.
There's even a small example video here: http://vimeo.com/31611842"
10.6), which will forward all multi-touch events from a trackpad to the
corresponding osgGA-event-structures.
The support is switched off per default, but you can enable multi-touch
support via a new flag for GraphicsWindowCocoa::WindowData or directly
via the GraphicsWindowCocoa-class.
After switching multi-touch-support on, all mouse-events from the
trackpad get ignored, otherwise you'll have multiple events for the same
pointer which is very confusing (as the trackpad reports absolute
movement, and as a mouse relative movement).
I think this is not a problem, as multi-touch-input is a completely
different beast as a mouse, so you'll have to code your own
event-handlers anyway.
While coding this stuff, I asked myself if we should refactor
GUIEventAdapter/EventQueue and assign a specific event-type for
touch-input instead of using PUSH/DRAG/RELEASE. This will make it
clearer how to use the code, but will break the mouse-emulation for the
first touch-point and with that all existing manipulators. What do you
think? I am happy to code the proposed changes.
Additionally I created a small (and ugly) example osgmultitouch which
makes use of the osgGA::MultiTouchTrackballManipulator, shows all
touch-points on a HUD and demonstrates how to get the touchpoints from
an osgGA::GUIEventAdapter.
There's even a small example video here: http://vimeo.com/31611842"
between the contexts, using the GraphicsContext::Traits sharedContext
and setting the same contextID.
When one of these shared contexts is closed, GraphicsContext::close
deletes all GLObjects for that contextID, regardless of the fact that
they are shared. This means that all of the other contexts sharing the
objects have to recompile them.
The attached tweak makes GraphicsContext::close a bit less brutal for
shared contexts. I have also changed a misleading diagnostic message.
"
to ensure the correct methods on constraints and callbaks are called for each Command. Also fixed the handling of
Constraints when applied to composite Draggers.
To reproduce the problem I attach a minimally modified osgviewer that just prints resize events. You can check what's printed in the console when you go fullscreen and windowed a few times.
The attached version of GraphicsWindowX11 fixes the problem for me, but I'm not sure this is the right approach. Maybe you can see a fix for the problem clearer.
The only place where the RESIZE event is generated in GraphicsWindowX11 is in CheckEvents and it then depends on the ConfigureNotify message. For some reason, either ConfigureNotify is not sent when going fullscreen or the traits already reflect the latest window size."
This patch add "FirePro" to the black list of renderers in State.cpp / initializeExtensionProcs
It allows to avoid an OpenGL error on Viewer initialization.
Tested on FirePro M7740 / Windows7 x64 Driver 8.85.7.2"
I used the latest version available via subversion.
My fix is using some API only available on 10.4 and later. I used some preprocessor statements to gain compatibility with 10.3 and earlier using (now) deprecated API.
Only tested on OS X Lion (10.7). Please do some testing as well since I'm fairly new to OpenSceneGraph. Someone should also test the code for 10.3 and earlier."
parameter in osg::Image. To support this Image::setData(..) now has a new optional rowLength parameter which
defaults to 0, which provides the original behaviour, Image::setRowLength(int) and int Image::getRowLength() are also provided.
With the introduction of RowLength support in osg::Image it is now possible to create a sub image where
the t size of the image are smaller than the row length, useful for when you have a large image on the CPU
and which to use a small portion of it on the GPU. However, when these sub images are created the data
within the image is no longer contiguous so data access can no longer assume that all the data is in
one block. The new method Image::isDataContiguous() enables the user to check whether the data is contiguous,
and if not one can either access the data row by row using Image::data(column,row,image) accessor, or use the
new Image::DataIterator for stepping through each block on memory assocatied with the image.
To support the possibility of non contiguous osg::Image usage of image objects has had to be updated to
check DataContiguous and handle the case or use access via the DataIerator or by row by row. To achieve
this a relatively large number of files has had to be modified, in particular the texture classes and
image plugins that doing writing.
the type of the virtual function ImageStream::getCurrentTime(), and with this fixing a compile and runtime error.
Changed time variables all to use doubles rather than float to be consist with the change to getCurrentTime().
the required header mathematics.h is not being included explicitly.
I have just included it, and verified that this also works with current
version 0.7, since the header is also available there."
