Changes to existing files:
ReaderWriter.cpp -- to support writeNode() of course.
ReaderWriterATTR.cpp -- to support writeObject -- we write .attr files for textures, if they don't already exist.
AttrData.cpp/.h -- Minor fixes.
CMakeLists.txt -- to include the new files in the build."
From Robert Osfield, port to non Windows platforms just required fixing of header capitilization errors
that windows lets through the net due to having a case insensitive file system.
key, but it didn't pick up the initial state. So, if NumLock was on for
the OS at startup (LED on), it was still off for OSG. And the first
keypress turned the LED off, and NumLock on for OSG. The attached fix
picks up the state on every FocusIn, just like it was done in the last
commits for CapsLock. The difference is, that the NumLock mask isn't
standardized (e.g. 0x10 for Linux, and 0x80 for AIX), so we have to do
a reverse lookup (::rescanModifierMapping()).
Note that I could not reproduce the problem on my system, but someone
else confirmed it twice on his, and the patch fixed it for him.
Changed files:
./include/osgViewer/api/X11/GraphicsWindowX11
./src/osgViewer/GraphicsWindowX11.cpp
"
and a new scheme for computing the scaling when using autoscale that introduces smooth
transitions to the scaling of the subgraph so that it looks more natural.
help manage the scaling of particles, whether they should be relative to the
local coordiante frame of the particle system, or be in world coordinates.
It sets osgGA's keymask when restoring keys on FocusIn, according
to the state values of XKeyEvent and XCrossingEvent. (These are
the only source for X11's current capslock state that avoids
pulling in the XKB extension.)
"
1) Full DOS paths are now correctly opened by OpenVRML. A URL containing
a DOS path should be "file:///C:data/blah" rather than "file://C:data/blah".
2) The last primitive defined in "coordIndex" is now added if the
"coordIndex" is not terminated by -1.
3) Smoothed normals are computed if no normal field is provided.
Currently, there is no support for "creaseAngle", so all edges (even the
ones sharper than the creaseAngle) are smoothed. I might add this in the
future if demand rises.
4) If an IndexedFaceSet contains only triangles or quads then the
primitive type is set to TRIANGLES or QUADS, and the primset becomes
DrawArrays rather than DrawArrayLengths.
Question: I noticed that for DrawArrays you can still provide an index
array. Would the rendering be faster if I'd create DrawElements primsets
rather than DrawArrays? Phrased differently, what is the benefit of
using DrawElements over DrawArrays, as there is clearly not a one-to-one
mapping of these concepts to their OpenGL counterparts?
5) Objects are added to the transparent bin and blend mode is enabled
only if the transparency is nonzero. Rendered transparent objects no
longer write the depth buffer."
"texture" paths. This is to drop absolute paths that some
3d editors export (even AC3D itself!). But this also strips
directories of relative paths, which is wrong and contradicts
the ac3d reference implementation. (The reference implementation
doesn't strip anything, though, and so takes the absolute paths
as they are. Definitely not what we want.)
The attached solution checks absolute paths and only strips
those:
(1) A:\\foo\\bar.png -> bar.png (as before)
(2) /foo/bar.png -> bar.png (as before)
(3) foo/bar.png -> foo/bar.png (new)
(4) ../foo/bar.png -> ../foo/bar.png (new)
"
The files are:
include/osgSim/ObjectRecordData -- The new class. Derives from Object to support .osg IO.
src/osgPlugins/OpenFlight/PrimaryRecords.cpp -- Reads data into that class.
src/osgPlugins/osgSim/IO_ObjectRecordData.cpp -- .osg IO support."
From Robert Osfield, made the OpenFlight read object record data optional via the -O readObjectRecordData ReaderWriter option.
osgViewer::StatsHandler and other handlers which allow you to change the
key(s) you would press to get them to do something. Pretty simple change
but useful in our context and possibly in others too."
The problem can be reproduced by simply changing the osgpick example to
use a CompositeViewer with a single view initialized using
setUpViewAcrossAllScreens(). I have attached a modified osgpick.cpp so
you can test it out quickly (please don't check this file in though :-)
) The eventState is then incorrect and picking does not work. The only
changes are in CompositeViewer.cpp (eventTraversal() method), and fix
the problem for me.
"
The win32 pbuffer implementation returned an error unless both the
WGL_ARB_pbuffer and the WGL_ARB_render_texture functions were present.
This was too restrictive, as a pbuffer can usefully be created without
render-to-texture, e.g. for use with glReadPixels. The osg 1.2/Producer
pbuffers worked without RTT, and osgUtil::RenderStage has all the code to
handle both RTT and non-RTT pbuffers, doing a read and copy in the
latter case.
With these changes I have successfully tested the osgprerender example
on a graphics card which supports RTT, and one which doesn't. Plus
tested in my own application.
In order to aid diagnostics I have also added more function status
return checks, and associated error messages. I have included the win32
error text in all error messages output. And there were some errors
with multi-threaded handling of "bind to texture" and a temporary window
context which I have corrected.
These is one (pre-existing) problem with multi-threaded use of pbuffers
in osgViewer & osgprerender, which I have not been able to fix. A win32
device context (HDC) can only be destroyed from the thread that created
it. The pbuffers for pre-render cameras are created in
osgUtil::RenderStage::runCameraSetUp, from the draw thread. But
closeImplementation is normally invoked from the destructor in the main
application thread. With the additional error messages I have added,
osgprerender will now output a couple of warnings from
osgViewer::PixelBufferWin32::closeImplementation() at exit, after
running multi-threaded on windows. I think that is a good thing, to
highlight the problem. I looked into fixing it in osgViewer::Renderer &
osgUtil::RenderStage, but it was too involved for me. My own
application requirements are only single-threaded.
Unrelated fix - an uninitialised variable in
osg::GraphicsThread::FlushDeletedGLObjectsOperation().
"
1:
Shadow map camera sets ABSOLUTE_RF_INHERIT_VIEWPOINT refernce frame.
2:
Light Direction by matrix multiplications replaced with transform3x3 multiplication.
3:
I made DebugingHUD functional by adding special draw callback. Former version was simply drawing pale square.
4:
I was tempted to make 4 th change but decided to not do it. Instead I put it whith #if VIEW_DEPNDENT_TEXGEN. If you decide you may let it go.
When objects are not centered at 0,0,0 coord but in some distant location (for example at surface of earth ellipsoid) shadow texgen suffers from inadequate precision of float matrices. I changed that by premultiplying Texgen matrix (using OSG double matrices) with inverse modelview and applying it later with ModelView identity matrix. This tweak may be appropriate for OverlayNode texgen as well.
I left former version because I suspect that this change will make osgShadow::ShadowMap view dependant. Currently texgen matrix remains the same no matter what View displays it. With my change it wuld be different for each view. This touches the subject of View Dependent Shadow Techniques that J-S asked recently."
there is a bug. The header file do specify something
like this:
FrameBufferAttachment(Texture3D* target, int zoffset,
int level = 0);
However in the .cpp file we have:
FrameBufferAttachment::FrameBufferAttachment(Texture3D*
target, int level, int zoffset)
Which means that the meaning of level and zoffset is
interchanged.
The file with the corrected line is attached. Should
go into src/osg/
"
remain in pressed state after revealing, even if they are no
longer pressed on the keyboard. This can have bad effects,
especially if the stuck keys are modifier keys. One has to
press and release the stuck keys again to reset the wrong state.
The fix keeps track of all key presses and releases. On FocusOut
and UnmapNotify it releases all keys that are in pressed state,
and on KeymapNotify (following a FocusIn), it sets the currently
pressed keys again. To avoid confusion in the OSG-using application
normal keys are always reported released /before/ and pressed
/after/ modifier keys.
As current key states are returned as char[32] keymap by
XQueryKeymap and XKeymapEvent, this format is also used to
recognize modifier keys and for maintaining the current
internal key state. Functions to set/clear/query bits in
such a keymap are added.
The patch was extensively tested with osgkeyboard and
FlightGear under KDE and fvwm2. It was not tested on a
Xinerama setup or with multiple windows, but as _eventDisplay
is used throughout, there should be no problems. The patch also
makes the following changes:
- removes old and obsolete handling of modifier keys in ::adaptKey().
This wasn't only unused, but also wrong (and for that reason commented
out in revision 7066). The modifier states are actually handled
in ./src/osgGA/EventQueue.cpp (EventQueue::keyPress/keyRelease).
- fixes some spelling"
The modifications I made are very small but they are absolutely usefull to use osgIntrospection with visual studio 7.1 or 8 in debug modes.
This should also solve other minor common problems (converter memory leak, virtual destructor for PropertyInfo, etc...).
I choosed two function names : Reflection::uninitialize() and Type::reset(), this can of course be changed if someone has a better idea...
I made the changes against OSG 2.2.0 public release. I tested the result with VS 7.1, VS 7.1 SP1, VS 8.0 SP1 and AQTime 5.0 on Windows XP SP2... All 4 seem to agree : they detected memory leaks before and don't anymore.
Sorry I haven't take the time to test that on linux but the changes are so small I doubt there could be a problem... I let you check that on your side :-).
I hope this will help making OSG an even more wonderfull library."
Attached is a fixed version of OverlayNode.cpp. I fixed CustomPolytope::cut( osg::Plane ) method. Bug was apparent in such scenario:
Let P1 be some random frustum polytope
Let P2 be the polytope that was created from P1 bounding box (P2 contains P1 entirely)
Then ignoring precision errors: P1.cut( P2 ) == P2.cut( P1 ) == P1. But this condition was not always met. Cut failed when some of the polytope reference points happened to lie exactly on some intersecting planes in both P1 & P2 (plane distance was = 0).
I only use CustomPolytope for my shadowing stuff so I did not test how this affects rest of OverlayNode.cpp.
----2----
Also attached is a minor precision improvement for osg::Plane intersect method (double version).
----3----
I have also one observation regarding osg::Plane - There are two intersect vertices methods (float and double flavour):
inline int intersect(const std::vector<Vec3>& vertices) const
inline int intersect(const std::vector<Vec3d>& vertices) const
I guess osg::Plane won't compile when someone changes default vec3 typedef to vec3d. Shouldn't the first method be changed to use vec3f explicitly ? Ie:
inline int intersect(const std::vector<Vec3f>& vertices) const"
pbuffer functions or exactly ask for the extensions we need to call the
apropriate glx extension functions for and around pbuffers extensions.
The glx 1.3 version of this functios are prefered. If this is not pressent we
are looking for the glx extensions and check for them.
Prevously we just used some mix of the glx 1.3 functions or the extension
functions without making sure that this extension is present.
"
carbon-implementation of GraphicsWindow. Now you can use an AGLDrawable
in conjunction with osgViewer/osgCompositeViewer."
Changes from Robert Osfield, changed std::cout to osg::notify(osg::INFO)
This is caused by the OSG_MSVC_VERSIONED_DLL hack.
there are hard-coded paths to place the dll's in the bin /dir that normally would go
in the lib/config (release/debug) dirs. Nmake has different locations for the files (no config dir).
fix: change the macro's in OsgMacroUtils.cmake for the IF(NOT MSVC_IDE) situation.
Libs go in lib/, and DLLs and executables go in bin/
To accopmplish this for MSVC_IDE the targets get a "../../bin" prefix,
for nmake this should be "../bin" (because there are no config folders).
This fix mimics the behaviour of the MSCV_IDE (visual studio) build system when building with nmake.
Note:
A change in the main CMakeLists.txt creates the needed plugin directory in the binary dir.
see included files for the changes:
r7885fix-v2/CMakeModules/OsgMacroUtils.cmake
r7885fix-v2/osgWrappers/CMakeLists.txt
r7885fix-v2/CMakeLists.txt
The behaviour of visual studio projects (and other build systems) remain unchanged.
Tested building and installing with nmake and visual studio 8 debug and release.
"
this fix strips whitespace off externally referenced material files.
fixes a bug where the obj listed something like:
mtllib FR_PARIS_ESPACE_UNESCO_S.MTL
and then that caused failures in the load later:
FindFileInPath() : trying /Users/rpk/Downloads/
FR_PARIS_ESPACE_UNESCO_S.MTL ...
this fix simply strips whitespace around that filename before passing
it on to the remainder of the loader."
Changes from Robert Osfield, change std::cout to osg::notify(osg::INFO)
It contained a bug that would cause freed memory to be written again.
Specifically, in FreeTypeLibrary::~FreeTypeLibrary(), calling
font->setImplementation(0); deletes the content pointed to by the
fontImplementation pointer, while the line the immediately follows
tries to access it.
My fix is to make the second instruction part of an else clause rather
than always executed. This way, the fontImplementation->_facade = 0
instruction is only executed when the font implementation is not set
to 0 before (although I have no idea what it is here for and if this
code path is ever followed, since I don't know the plugin's internals
very well).
Attached is the modified FreeTypeLibrary.cpp file."
