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."
"From David Glenn and Paul Martz. This change adds support for the NO_COLOR bit in the Vertex records' flags field. If NO_COLOR is set, and PACKED_COLOR is not set, the code will now properly default to using the face color at those vertices. See the osg-users thread "Open Flight characteristic not reflected in the current OSG" for more info."
and
"In consultation with David Glenn, it appears we needed to change a second file to correct how OpenFlight handles transparency when vertices have NO_COLOR. "
functionality when using Terrain::setVerticalScale. This was caused by
the following call sequence resulting in a lockup:
void Terrain::setVerticalScale(float scale)
CALLS dirtyRegisteredTiles();
void Terrain::dirtyRegisteredTiles(int dirtyMask)
SETS LOCK OpenThreads::ScopedLock<OpenThreads::Mutex> lock(_mutex);
and CALLS (on every tile) setDirtyMask(dirtyMask);
void TerrainTile::setDirtyMask(int dirtyMask)
CALLS _terrain->updateTerrainTileOnNextFrame(this);
void Terrain::updateTerrainTileOnNextFrame(TerrainTile* terrainTile)
SETS LOCK OpenThreads::ScopedLock<OpenThreads::Mutex> lock(_mutex);
******* PROBLEM - since lock has already been set! ********
The suggested fix submitted changes from using Mutex to ReentrantMutex.
"
You can now set a "intersection mask" and it will be used when looking for intersections.
So you can now easily "hide" some objects from manipulators."
I don’t have access to an OSX or Linux dev machine to make the changes required to the quick time plugin. This plugin will just default to returning 0."
(41e23f466d)
for GraphicWindowsIOS.mm broke the compilation for OpenGL ES 1.x as
GL_DEPTH_COMPONENT32_OES is not defined for 1.x. I added a #define-guard."
Improved the computation of the light direction from non-dimensional mouse coords so that they now project onto a hemisphere making
the interaction more intuitive.
Added support into .vnc plugin for passing in the keywords "swap", "RGB", "RGBA", "BGR", "BGRA" as OptionString values to allow .p3d presentations to control
whether the pixelformat should be swapped or set to a specific format.
changed the shadow map texture assigment to StateSet so that it doesn't use OVERRIDE, enabling subgraphs to use the same texture unit for other textures if they so required.
tidied up indentation.
Motivation ;
When using PagedLODs, you don't always know the real size of loaded children,
If it occurs that they are out of predefined bounds, picking on the parts that are out of bound will fail
They also can be culled out too soon.
The problem often occurs with long object (roads).
I've modified LOD and ProxyNode to include this option."
and later email:
"Attached the UNION_OF_BOUNDING_SPHERE_AND_USER_DEFINED version
There are impacts on some serializers (dae, osgWrapper).
I haven't modified deprecated osg, since it's deprecated"
OpenSceneGraph\src\osgPlugins\ffmpeg\FFmpegDecoderAudio.cpp
It solves a wrong sample format being set for audiostreams type S32 and F32, for the
enum AVSampleFormat (in include/avutil/samplefmt.h) doesn't match
enum SampleFormat (in include/osg/AudioStream) for anything but
SAMPLE_FORMAT_U8 and SAMPLE_FORMAT_S16
"
and follow up that address versioning issue
"I can find the change, avutil version 50.38.0 introduced a new header file:
libavutil/samplefmt.h
older versions use
libavcodec/avcodec.h
with the sampleformats without AV_
an intermideate fix with the FF_API_OLD_SAMPLE_FMT is removed from ffmpeg 0.8.3 so
I think this is the correct fix:
#if LIBAVUTIL_VERSION_INT < AV_VERSION_INT(50,38,0)
#define AV_SAMPLE_FMT_NONE SAMPLE_FMT_NONE
#define AV_SAMPLE_FMT_U8 SAMPLE_FMT_U8
#define AV_SAMPLE_FMT_S16 SAMPLE_FMT_S16
#define AV_SAMPLE_FMT_S32 SAMPLE_FMT_S32
#define AV_SAMPLE_FMT_FLT SAMPLE_FMT_FLT
#define AV_SAMPLE_FMT_DBL SAMPLE_FMT_DBL
#define AV_SAMPLE_FMT_NB SAMPLE_FMT_NB
#endif
"
So with the 3.0 api change we propose the following change:
- put OSG_EXPORT on the QueryGeometry class so that we get access to the getNumPixels method.
- Create a function called getQueryGeometry that returns a casted _queryGeode->getDrawable(). Or a function called getQueryGeode that returns _queryGeode."
The osgUtil::CullVisitor class will display an OSG_INFO notification when attempting to clamp the projection matrix with invalid near/var values. This usually appears when the scene graph is empty or all objects are culled. I don't think this scenario warrants having this message appear every frame. It makes it very difficult to debug other issues when this notification floods the output window.
I'd prefer to have the notification removed, but there might be legitimate cases where you want this displayed. Instead, I just disabled the output if the near/far values are equal to FLT_MAX (their initial values). This should at least prevent the notification for the common case where everything was culled."
"Here a patch that correct like the previous assign collada material name
to stateset."
and
"I changed how the collada reader set object name in osg. Current
implementation use collada ID to setup name. with this patch I use
collada name to setup name in osg object and if collada provide no name
I use as fallback ID. I am not sure we want this fallback.
The motivation of this change is that when an artist set names to its
objects and export to collada, I am not able to use those names in osg
to retrieve the node."
and
"Here the update of the file that fix the light id stuff"
Added COMPUTE_NEAR_FAR_USING_PRIMITIVES option that provides the original functionality where only the near plane
is computed in a fine grained way, with the far plane being computed simply from bound volumes.
