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."
last primary node inside a push-pop level would not get the dispose()
call. This would result in information from some ancillary records,
like the matrix (transform), being lost.
Changes are made to the latest version in the repository.
Thanks to Terry for the help to find and fix the bug and test the changes."
.shp ...) ogr is a part of gdal so i added the build of ogr plugin if
gdal is found.
to test it
osgviewerd -e ogr file.tab
or
osgviewerd -e ogr file.gml
or
osgviewerd -e ogr file.shp
"
use of parameter GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS which is only part
of the standard from 2.0 onwards. I've updated src/osg/State.cpp, so
that it attempts to be more rigorous regarding OpenGL version and
extension checking."
node has already been erased from the node list, causing childRemoved to be
performed on the consecutive node.
Lines 180 and 182 are swapped in the attached Group.cpp.
"
from Quicktime/Quicktime.h to QuickTime/QuickTime.h.
MacOsX filesystem is normally case insensitive, but in
my case I changed that option and the quicktime headers
were not found. Now compiles fine and on case insesitive
file systems should work correctly too. "
setScreenRefreshRate for systems support Xrandr. The include CMakeFile
makes this optional, and turns it OFF by default, in which case any
person trying to use these functions under Linux will be instructed to
build osgViewer w/ Xrandr support.
"
to STOP. Subsequently, you can restart it from the beginning by
setting the mode to START. This does not work as expected. The _now
time is not updated while the mode is STOP, which causes the items in
the sequence to flash by very quickly when the mode is set to START.
For example, if the mode was set to STOP and left that way for 30
seconds, and there are 10 items in the sequence, when the mode is set
to START all the items will flash by (in 3 loops) while the _now time
catches up with the real time, and then the sequence will go on at the
rate it should.
This is a simple fix for that, which updates the _now time regardless
of the mode the sequence is in."
to bugfixes in osg::Polytope.setToUnitFrustum and setToBoundingBox It was
sent at beginning of december. I read it when purging my Thrash emails and
found it there this because it was wrongly classified as SPAM.
What stroke me in this email was the fact that there was once an error in
Polytope class. Since I adopted CustomPolytope (osgSim OverlayNode.cpp) for
my minimal shadow area computations I checked my code for this error. And I
found it in CustomPolytope::setToUnitFrustum method.
CustomPolytope::setToBoundingBox seemed OK.
So I went back to the origin and fixed this error in OverlayNode.cpp as
well. I have not tested it in OverlayNode though (I don't know how) so
please look at this carefully. But it seems to work fine with my shadow
calculations."
File osgShadow/Version.cpp, Line 25:
const char* osgShaodowGetLibraryName()
should be:
const char* osgShadowGetLibraryName()
File CMakeModules/OsgMacroUtils.cmake, Line 224:
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES DEBUG_POSTFIX ${CMAKE_DEBUG_POSTFIX})
should be:
SET_TARGET_PROPERTIES(${TARGET_TARGETNAME} PROPERTIES DEBUG_POSTFIX "${CMAKE_DEBUG_POSTFIX}")
Otherwise setting CMAKE_DEBUG_POSTFIX to an empty string instead of "d" in
the main CMakeLists.txt does not work under Linux.
"
64 bit binary compatible OSGA archive reader/writer using mixed
stdio/iostream calls. But during this work I learned that it can be made in
much simpler way.
Attached is result of this new attempt. I hope its appropriate for inclusion
into OSG codebase. It was compiled and tested with latest SVN OSG, Windows
XP 32 bit and Windows Vista business 64 bit. OSG was built using VS 2005
Express SP1 for 32 bit environment and VS 2005 Std for 64 bit.
---
Solution description (there were two problems involved):
---
Problem 1: implicit conversions beetween file positions and 32 bit int. This
could be considered a MS compiler bug because this 32 bit int was
additionally implicitly converted to/from 64 bit. As far as I know compiler
is allowed to make only one implict conversion (but maybe this rule does not
refer to simple types).
Its actually possible to address OSGA files above 4 GiB range using 32 bit
windows iostreams. MS Iostreams in practice offer the same level of
functionality as stdio functions. There are functions fsetpos and fgetpos in
stdio lib which use 64 bit file pointers (fpos_t). These functions are
internally called by seekp( streampos ), seekg( streampos ), tellp(), and
tellg() methods. So its also possible to change and retrieve file postions
using iostream calls. But the problem lies in implicit handling of streampos
type.
streampos type is actually a template class used as seekp, seekg parameter
and returnd from tellp, tellg. Its capable of storing 64 bit file pointers.
But streampos can be also converted to/from simple type streamoff. It has
proper constructor and cast operator. In Win 32 environment streamoff is
defined as long (~32 bit int). So when seekp, and tellp arent used with
exact streampos objects but OSGA_Archive::pos_type complier makes implicit
casts to 32 bit int types loosing important bits of information.
So above problem could be easily handled by making conversion calls
explicit. My code defines 2 functions used to convert back and forth beetwen
64 bit OSGA_Archive::pos_type and std::streampos objects:
OSGA_Archive::pos_type ARCHIVE_POS( const std::streampos & pos );
std::streampos STREAM_POS( OSGA_Archive::pos_type & pos );
Rest of the OSGA implementation code was modified to call these conversions
explicitly with seekp, seekg, tellp, tellg.
---
Problem 2: seekp and seekg have two variants. Only one of these variants is
actually 64 bit proof.
When I solved my first problem and made use of explicit streampos conversion
functions, OSGA archive was able to read my example 11 GiB archive. But
there were still problems with write and append. I found that the reason for
this was pair of seekp( 0, std::ios_base::end ) and tellp() calls. It turned
out that use of seekp, seekg( offset, direction ) function variants was
setting file pos pointer to EOF when file was larger than 4GiB. But I
noticed that one arg seekp, seekg ( streampos ) versions worked correctly.
So the solution was to change OSGA write logic a little, and replace
seekp( offset, direction ) with seekp( absolute_pos ) calls.
I achieved this by modifing IndexBlock write method to record and restore
file pos after IndexBlock was written. This modification has the effect that
put pointer is generally kept at the end of file, so there is no need to
repostion to the end before writing the files. This allowed me to get rid of
those problematic seekp( 0, std::ios_base::end ) calls.
There was one place where I could not easily get rid of seekp( 0,
std::ios_base::end ). It was situation where existing OSGA was opened for
appending. I resolved this by computing file length by finding max position
from index block and file block endings. Then I replaced former seekp( 0,
std::ios_base::end ) with seekp( STREAM_POS( found_file_length ).
---
Description of these changes may sound bit hacky but in practice these were
fairly simple and straightforward modifications. I hope they pass your
review. There is one complex preprocessor condition which I based on few
lines taken from boost positioning.hpp. Boost licence does allow such
reproduction. In case of problems this condition may be easily simplified to
windows only implementation.
"
osg::Capsule subclass of osg::Shape in an osg::ShapeDrawable. Other
shapes worked fine. So I have fixed this. Code attached.
My modification is in the PrimitiveShapeVisitor, and is based on the
DrawShapeVisitor - I added methods called createCylinderBody and
createHalfSphere, and used them in apply(Cylinder&) and
apply(Capsule&). In my testing they work fine, tested even with
transforms and moving around the scene.
"
But writing BlinkSequence with empty sequence group caused a crash when IVE was accessing baseTime from NULL address.
Atttached is a fix for this situation.
"
creating subclasses of osg::Array that referenced data
stored an application's internal data structures. I took
a stab at implementing that and ran into a couple of
downcasts in Geometry.cpp. Enclosed is my take at fixing
those along with a simple example of how to do this."
1. DAE object no longer held onto by plugin.
2. Filename to URI conversion now handled internally by plugin.
2. User can supply an external DAE object for use by the plugin.
3. User can supply a std:string object for the plugin to return the URI of
the document just processed.
4. User can supply a std::string to receive the unit name information from
the document just read in. (e.g. meters, inches, etc.)
5. User can supply a float to receive the metric conversion factor from the
document just read in.
6. User can supply an enum to receive the up axis orientation information
from the document just read in.
7. Material transparency can be both read and written.
8. User can supply an experimental GoogleMode option on output. The plugin
will try to emulate the way Sketchup specifies transparency (i.e. the
inverse of what it should be!). I am still struggling to get GE to
understand transparency, anyone know what it expects?
9. Rudimentary support for Collada effect parameters (newparam, setparam,
param) on input. Basic nVidia FX Composer dae documents can now be read.
"
in the DatabasePager. The practical effects of these are to greatly reduce startup time
and the time to load an individual scenery tile in FlightGear.
- From my log message:
Minimize the number of StateSets and drawables that are compiled by checking
if they have already been compiled or will be elminated by the
SharedStateManager.
Move the sorting of the dataToCompile queue out of compileGLObjects
into the man pager run function.
Change the SharedStateManager to use maps instead of vectors."
Previously the complete StateSet was cleared, even the non clipping releted
state attributes and modes in this stateset on a call to
setLocalSetateSetModes.
With this change only those modes/attributes are changed that need to be
changed. That is, if a clip plane is removed from the ClipNode, only this
assiciated mode is removed from the state set, instead of throwing away the
whole state set.
In this way we have less surprising results if the state set of a clip node is
used for more state than just the clip state.
"
StateSet::removeAssociatedModes(const StateAttribute*)
and a
StateSet::removeAssociatedTextureModes(unsigned, const StateAttribute*)
call. These funktions are just missing for a complete api IMO."
