This issue can be reproduced:
1. Create osgViewer window,
2. Push right&left mouse buttons on the osgViewer window,
3. Move mouse out of window, and release right&left mouse buttons.
osgViewer window handle only first mouse release, as result window thinks that we did not released second mouse button.
I attached fix for this issue."
calculated model / view matrices up to that point. The IntersectionVisitor would instead keep the
view matrices calculated up to that point even though the Transform class will throw out the
calculated model matrix via “computeLocalToWorldMatrix.”
The change I made will push an identity matrix as the view matrix when running into a transform
with an absolute reference frame and will pop the matrix off after the traverse.
To test this, I created a camera with a perspective view and added a transform with some geometry
in it. Afterwards, I set the transform’s reference frame to ABSOLUTE_RF and spun the camera around
using the trackball manipulator. When trying to pick with a LineSegmentIntersector, it would not
pick the geometry in the transform with the reference frame set to ABSOLUTE_RF."
I fixed some bugs and did some more tests with both of the video-plugins. I integrated CoreVideo with osgPresentation, ImageStream has a new virtual method called createSuitableTexture which returns NULL for default implementations. Specialized implementations like the QTKit-plugin return a CoreVideo-texture. I refactored the code in SlideShowConstructor::createTexturedQuad to use a texture returned from ImageStream::createSuitableTexture.
I did not use osgDB::readObjectFile to get the texture-object, as a lot of image-related code in SlideShowConstructor had to be refactored to use a texture. My changes are minimal and should not break existing code.
There's one minor issue with CoreVideo in general: As the implementation is asynchronous, there might be no texture available, when first showing the video the first frame. I am a bit unsure how to tackle this problem, any input on this is appreciated.
Back to the AVFoundation-plugin: the current implementation does not support CoreVideo as the QTKit-plugin supports it. There's no way to get decoded frames from AVFoundation stored on the GPU, which is kind of sad. I added some support for CoreVideo to transfer decoded frames back to the GPU, but in my testings the performance was worse than using the normal approach using glTexSubImage. This is why I disabled CoreVideo for AVFoundation. You can still request a CoreVideoTexture via readObjectFile, though.
"
Added template readFile(..) function to make it more convinient to cast to a specific object type.
Added support for osgGA::Device to osgViewer.
Added sdl plugin to provides very basic joystick osgGA::Device integration.
macro, which could set version within brackets and reset it after
that. All related serializers are also modified so that the
backward-compatibility bug reported by Farshid can be fixed.
"
From Robert Osfield, removed the use of osg::Referenced and creating the proxy object on the heap.
--This line, and thosAttached is an update to ReaderWriterDAE.cpp/h and daeReader.cpp/h that implements
osgDB::ReaderWriter::ReadResult
ReaderWriterDAE::readNode (std::istream&, const osgDB::ReaderWriter::Options*)
This virtual function had never been implemented in ReaderWriterDAE. I implemented this function because the DAE plugin could not load files from other ReaderWriter derived objects that use protocol handlers.
I have updated function declarations in the header to have identical signatures with the base class declarations that include the default parameter.
readNode (std::istream&, …) is nearly identical to readNode(const std::string &, …) except it uses a new private function to convert the file from standard input:
bool daeReader::convert( std::istream& fin )
When this function is called fileURI is the string “from std::istream” to make the user aware where the file is coming from. Then instead of calling
_dae->open(fileURI)
we call
_dae->openFromMemory(fileURI, buffer.data())
Where buffer.data() is a pointer to the dae file text in memory.
Other changes include private functions to clear caches and to consolidate redundant code that appears between the two convert functions.
e below, will be ignored--
M src/osgPlugins/dae/ReaderWriterDAE.cpp
M src/osgPlugins/dae/daeReader.cpp
M src/osgPlugins/dae/ReaderWriterDAE.h
M src/osgPlugins/dae/daeReader.h
(KTX). The KTX file format is straightforward and designed to be easy to
use in OpenGL.
http://www.khronos.org/opengles/sdk/tools/KTX/file_format_spec/http://www.khronos.org/opengles/sdk/tools/KTX/
The attached plugin can read:
* 1D, 2D, and 3D textures
* uncompressed and compressed images
* mipmapped and non-mipmapped textures
* little-endian and big-endian files
* textures from files as well as seekable istream objects
It does not handle:
* array textures (not supported by the ReaderWriter API)
* cubemap textures (not supported by the ReaderWriter API)
* the "KTXorientation" key-value pair; support could be added later (see
the file format spec for more information)
* non-seekable istream objects (would require more complicated memory
management)
"
What happens is this:
A view is created, and then the viewers thread is created and runs.
The setReleaseContextAtEndOfFrameHint is true.
To create a second view, the viewer is setDone(true), and we wait for the thread exit.
At this point, inside the ViewerBase::RenderingTraversals code, there are places where it reads "if(_done) return;"
The problem, is that it won't reach the code that will releaseContext().
Apparently, this driver won't let any other thread to makeCurrent(), if another thread (dead or not) has ownership. So when the Viewers is re-started, the first view won't be able to use the gc.
The change attached (against rev 13153) corrects this."
Attached are changes to GraphicsWindowIOS.mm to support setting up the new buffer type when compiling for iOS5,
also attached is a small change to FrameBufferObject.cpp to report support for packed depth stencil via the
GL_OES_packed_depth_stencil extension.
For anyone reading this you can attach a packed depth stencil to your FBO like so
_rttCamera->attach( osg::Camera::PACKED_DEPTH_STENCIL_BUFFER, GL_DEPTH24_STENCIL8_EXT );
Luckily GL_DEPTH24_STENCIL8_EXT happens to have the same value as iOSs GL_DEPTH24_STENCIL8_OES"
But the layers are not always children of the "model root" node : there can be a matrix transform between "model root" and "layers parent", so I've added the name "Layers" on the node which contains all layers to easily retrieve the layers groups from application code."
Cocoa and when to use the old Carbon interface for the windowing system.
The old code had to be modified for every new OS X release to default to Cocoa.
The new code uses Carbon for <= OS X 10.4 and Cocoa on everything else."
- Also, a 'dontSaveNormals' was added. It allows to ignore normals when writing an STL file. For example, it is useful for me when writing an STL file for CFD simulations.
- Some comments and code formatting were improved (to be consistent with the formatting already used in the plugin).
- With 'separateFiles' option files are now named fooX.stl instead of foo.stlX
The changes have been tested on various STL, both ASCII and binary found on the net. The change was based on the trunk branch."
From Robert Osfield, changed assert in Piotr's code to a runtime check warning report.
This fixes problems with PolygonZ records where the previous code was reading past the end of the record since it thought it had M values even if it didn't. I suspect the problem that James McGlone had back in 2006 was the same but reversed, when he tried to simply comment out the check, which was a (correctly) refused submission.""
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."
