svn merge -r 8852:8853 http://www.openscenegraph.org/svn/osg/OpenSceneGraph/trunk .
From Robert Osfield, "Introduced Geometry::containsSharedArrays() and Geometry::duplicateSharedArrays() to
support a fix to the osgUtil::Simplifier that couldn't handle shared arrays"
Also, from Daniel Olivier. Fix for windows based on GraphicsWindowWin32 not switching to the resize mouse cursors when the mouse goes close to window borders.
The following link shows a very comprehensive list of .mtl file options:
http://local.wasp.uwa.edu.au/~pbourke/dataformats/mtl/
Attached is a patch that should fix spacey filenames and optional texture scale/offset. I have tested it with files I have that I modified to contain spaces in the texture filenames."
viewer.addEventHandler(new osgViewer::ScreenCaptureHandler(
new osgViewer::WriteToFileCaptureOperation("filename", "jpg")));
and the filename will be what you want. The WriteToFileCaptureOperation will add the context ID and the file number (if in SEQUENTIAL_NUMBER mode) to the file name.
(The attached also clarifies some notify messages, and corrects the comment when adding the handler in osgviewer.cpp)
I also remembered, the current architecture could allow a different CaptureOperation for each context, but currently the API only allows setting one CaptureOperation for all contexts. This could be improved if need be.
"
with gcc (version 4.3.1) I got the following error message in
include/osgUtil/TriStripVisitor and Tessellator
error: type qualifiers ignored on function return type
The errors belong all to a INLINE function definition. Find attached my
modified version."
Notes from Robert Osfield, I've merged osgWidget trunk, and added/changed CMakeLists.txt file to make it suitable for inclusion in the core OSG, and moved imagery/scripts/shaders out into OpenSceneGraph-Data
1. Added options to control wether the osgUtil::Tessellator or osgUtil::TriStripVisitor are run. By default they still run just as before.
2. Added support for the Emissive material. The data was being read from the mtl file but was never being applied to the model.
3. This is the main bug addressed, when a model is read in with an alpha value specified like:
newmtl Material__8
Ns 24
d 0.33
illum 2
Kd 0.204 0.204 0.204
Ks 0 0 0
Ka 0.153 0.153 0.153
where the alpha value is d. The loader would then overwrite the alpha value when reading the diffuse, specular, and ambient colors. I have changed all the material color readers to only set the values they read and to use the default colors specified in the constructor of the obj class. With these changes, the obj reader now handles opacity correctly if the alpha value is specified before the material colo"
It check the data type of the image ( img.getDataType() ) and if it's GL_FLOAT :It save the tiff with float values.
Otherwise it does the same thing as before."
does not process I/O for osg::Light. Now I have fixed it as follows:
2. In DataInputStream.cpp, I add support code in DataInputStream::readStateAttribute
for osg::Light.
3. In DataOutputStream.cpp, I add support code in DataOutputStream::writeStateAttribute
for osg::Light.
"
"Opcodes.h:
* Added INVALID_OP as -1 in the Opcodes enum. Note that INVALID_OP is not an actual opcode defined in the OpenFlight format. The purpose of INVALID_OP is to mark an opcode variable as invalid or uninitialized.
ReaderWriterFLT.cpp:
* The header node is returned if it exists, even if the file does not contain a node hierarchy. The old behaviour returned a ERROR_IN_READING_FILE error.
* Changed opcodes initialized to -1 to the new enum value INVALID_OP."
/users/mvalle/OSG/OpenSceneGraph/src/osg/BufferObject.cpp: In member function `virtual void osg::ElementBufferObject::compileBuffer(osg::State&) const':
/users/mvalle/OSG/OpenSceneGraph/src/osg/BufferObject.cpp:600: warning: cast to pointer from integer of different size"
and Text3D, FadeText inout :
1. in DataInputStream.cpp, add 1286--1293 lines;
2. in Text.cpp, add some code for text's Backdrop setting;
3. in IveVersion.h, add line 39, increase the VERSION to VERSION_028(line 41)
4. in ReadWrite.h, add line 146,147
5. add file FadeText.h, FadeText.cpp, Text3D.h, Text3D.cpp."
to optimize away duplicate state with dynamic, static and unspecified DataVarience. By default
the code now optimizes away duplicate state with either static and unspecied state, previously
it was just handling static state.
MemoryBarrier() is used in the implementation, so it should be checked.
This in effect disables the faster atomic ops on msvc 7.1 and older, even if
only the MemoryBarrier() call is missing. But it ensures for the fist cut
that it will build everywhere. If somebody cares for msvc 7.1 enough and has
one for testing installed, he might provide the apropriate defines to guard
that MemoryBarrier() call.
I tested that msvc8 32/64bit still passes the configure tests and compiles.
"
1) The "highest res" child is assumed to be the child with index "getNumFileNames()-1" or "getNumChildren()-1". As a result, PagedLODs that do not sort children from furthest to nearest will intersect with the wrong child. (see attached "case1.osg" to reproduce this problem.)
2) The code assumes there is only one highest res child. As a result. PagedLODs with multiple children at the same highest res range can only intersect one of those children. ("case2.osg" demonstrates this issue; you can only pick the quad on the right.)
I've attached a modified IntersectionVisitor.cpp that attempts to resolve these issues. It identifies a highest res range based on the range mode, then continues traversal on all valid children corresponding to that range description. Only in the case of a malformed PagedLOD does the code fall back to getting the last child in the list.
"
implementation of the atomic increment and decrement into a implementation
file.
This way inlining and compiler optimization can no longer happen for these
implementations, but it fixes compilation on win32 msvc targets. I expect
that this is still faster than with with mutexes.
Also the i386 gcc target gets atomic operations with this patch. By using an
implementation file we can guarantee that we have the right compiler flags
available."
atomic related compile failures with msvs2005. Attached changes to make win32
really use the atomic stuff. There are pointer typecast problems and some
historic alignment restrictions that I just took from a previous similar
implementation of mine without looking deep enough. "
I needed a -DCMAKE_DEBUG_POSTFIX="d" not a -D"CMAKE_DEBUG_POSTFIX=d".
This corrects the build for the CMake 2.4 and 2.6 series
The error was in compiling osgDB/Registry.cpp
"
- Added osgviewerCocoa example to APPLE builds
- Fixed corrupt Xcode project generation with CMake 2.6 dealing with ADD_DEFINITIONS and CMake Policy CMP0005 on Leopard
- Resolved CMP0006 warning for examples and programs by setting BUNDLE DESTINATION to same as RUNTIME DESTINATION with CMake 2.6
- Fixed freetype plugin on Leopard to avoid OpenGL linking problem
- Figured out how to use a custom Info.plist included in the project (see osgviewerCocoa application CMakeLists.txt)"
From Robert Osfield, made a range of changes to Terry's visitor integrating it into osgUtil::Optimizer and
changing the code to use a style more like the rest of the OSG.
"I have taken the liberty of updating a few files so that there is no longer any derivation from std::vector. I have done this by adding a new file osg/MixinVector and by updating only two others: osg/PrimitiveSet and osg/Array. You will notice that this actually removes what is acknowledged as a \u2018hack\u2019 in osg/PrimitiveSet.
With the original code I did manage to find memory leaks with some compiler options on VC 8 and 9, as well as Intel compiler. I determined the leak existence by instrumenting the destructor code, and by use of a garbage collector as a leak detector (in a similar manner to the Firefox project). Hence in contrast to what I said originally, it is exhibiting symptoms on at least some platforms.
Since I am trying to be a good OSG citizen I got out my editor and started hacking! I have built and tested on Linux (Ubuntu) with GCC 4.x and Windows VC 8 SP1. It appears that nothing is broken, and that I\u2019m using less memory J"
In the OSG OpenFlight plugin these names are ignored when reading, and
empty strings are written.
As we need these names in the OSG scene graph by our application, I
changed the plugin code, so the names are now stored in class
"osg::Material" (derived from "osg::Object") by
material->setName();
(see "PaletteRecords.cpp, line 195) when reading the file, and written
to file by
dos.writeString( m.Material->getName(), 12 );
(see MaterialPaletteManager.cpp, line 80).
As these names otherwise get lost when reading an OpenFlight file and
writing it again e.g. by
osgconv example.flt converted_example.flt
these changes make the plugin more complete.
The changes were made to OSG revision 8425, and were tested by
osgconv example.flt converted_example.flt
comparing the material palettes of both files inside Multigen Creator."
viewport settings in stereo mode. It seems that the SceneView::cull()
method will pass the full size viewport to the left/right
cullvisitors, instead of the modified stereo viewport. I made quite a
few changes to SceneView to fix the issue. The SceneView::cullStage()
method will now receive the viewport as an argument, instead of using
the global viewport. The SceneView::cull() method will pass the
modifed viewport to cullStage when rendering in stereo.
There are 2 new private methods computeLeftEyeViewport() and
computeRightEyeViewport() that will compute the stereo viewports. I
also modified the draw() function so it applies the correct viewport
to the prerender stages. These changes are only necessary for
horizontal/vertical split stereo."
via StateSet::setNestedRenderBin(bool) whether the new RenderBin should be nested
with the existing RenderBin, or be nested with the enclosing RenderStage.
"1. Location: <OSG_SOURCE_ROOT>\src\osgPlugins\osg\Fog.cpp
Reason: ".osg" writter plugins output incorrected string for osg::Fog's Mode.
How to Fix:
Line 138 in Fog.cpp: case(Fog::LINEAR): return "NERVER";
Change to: case(Fog::LINEAR): return "LINEAR";
2. Location: <OSG_SOURCE_ROOT>\src\osgPlugins\ive\
Reason: ".ive" writter plugins missing to process "osg::Fog".
How to Fix:
(1). Line 86 in ReadWrite.h:
Add: #define IVEFOG 0x00001133
(2). In CMakeLists.txt
"SET(TARGET_SRC" section Add: Fog.cpp
"SET(TARGET_H" section Add: Fog.h
(3). In DataInputStream.cpp
Line 54,Add: #include "Fog.h"
Line 1185,Add: else if(attributeID == IVEFOG){
attribute = new osg::Fog();
((ive::Fog*)(attribute))->read(this);
}
(4). In DataOutputStream.cpp
Line 57,Add: #include "Fog.h"
Line 832,Add: // This is a Fog
else if(dynamic_cast<const osg::Fog*>(attribute)){
((ive::Fog*)(attribute))->write(this);
}
(5). Add newly created ive::Fog Object in Fog.h and Fog.cpp.
"
I added a call to allocateDataArray() if rhs has (at least) one valid array, which should allocate the right array according to the type. Since the type was copied from rhs, it should create the same array as rhs has, so then it should copy the data in the following lines.
"
This was easy to implement simply by overriding IntersectionVisitor::apply(PagedLOD). My question is: Are there any opinions on whether this should be the default behavior? If it makes sense, I will submit the change; if not, no worries."
is based on suggested fix from Marco for fixing a crash due to lack of
thread safety in std::ofstream("/dev/null"); The fix is to use a custom stream
buffer that just discards all data. The implementation is also twice as fast
as the old /dev/null based approach.
calling wglMakeCurrent twice.
This bug has been reported to NVidia, confirmed and fixed by NVidia but awaits verifiaction and release if a driver which fixes this bug.
is an example). This can happen in circumstances that are not
manageable by the OSG itself (e.g. 3rd party buggy program) but one
would expect the plugin to be able to recover by returning
ReadResult::ERROR_IN_READING_FILE.
libpng provides two callbacks for warnings and errors - those are
currently unused. By default, they point to function that call exit()
or something similar (the default error callback never returns). This
patch registers the callbacks using libpng's mechanisms, makes the
warning callback emit an osg::notify(osg::WARN) message and the error
callback throw an error. The reading process is enclosed in a
try...catch block. Upon error, the memory is freed and
ReadResult::ERROR_IN_READING_FILE is returned.
"
osgViewer::GraphicsWindow::setCursor() the new cursor type is recorded
but not applied until windows sends another WM_SETCURSOR message. This
delays the application of the cursor to the next mouse event.
The attached file fixes this by setting the new cursor with a call to
::SetCursor() immediately.
"
nvidia 6 months ago and the issue is still "in progress". I've given up
waiting for them!
Platform - various Intel Windows XP SP2 PCs with various nvidia cards
including GeForce 8800 GTS and Quadro FX 4500, and various driver
versions including the latest WHQL 175.16.
I investigated your concerns about glGenerateMipmapEXT being slower than
GL_GENERATE_MIPMAP_SGIS, and for power-of-two textures, to my surprise
it is. For a 512*512 texture, glGenerateMipmapEXT takes on average 10ms,
while GL_GENERATE_MIPMAP_SGIS takes on average 6ms. Therefore I have
modified the code to only use glGenerateMipmapEXT if the texture has a
non-power-of-two width or height. I am resubmitting all the files
previously submitted (only "Texture.cpp" has significant changes since
my previous submission, I've also replaced tabs with spaces in
"Texture").
"
first post:
"I had the problem that debug and release version of the plugins had the same name under linux. These minors modification to Registry and the CMake support files enable to have both Release and Debug version of the plugins to coexist and be found by there respective runtimes."
follow up post:
"I've gone ahead and added a preprocessor directive with the editable CMAKE_DEBUG_POSTFIX. I modified Registry.cpp to take this new preprocessor directive called OSG_DEBUG_POSTFIX while looking for libraries in Debug mode for the windows (msvc) and the linux platforms.
MinGW, cygwin and Apple are still left out this proposal."
Notes from Robert Osfield, completed the work in change d entries to use OSG_DEBUG_POSTFIX
GL_GENERATE_MIPMAP_SGIS is very slow (over half a second for a 720*576
texture). However, glGenerateMipmapEXT() performs well (16ms for the
same texture), so I have modified the attached files to use
Texture::generateMipmap() if glGenerateMipmapEXT is supported, instead
of enabling & disabling GL_GENERATE_MIPMAP_SGIS."
Notes, from Robert Osfield, I've tested the out of the previous path using
GL_GENERATE_MIPMAP_SGIS and non power of two textures on NVidia 7800GT and
Nvidia linux drivers with the image size 720x576 and only get compile times
of 56ms, so the above half second speed looks to be a driver bug. With
Muchael's changes the cost goes done to less than 5ms, so it's certainly
an effective change, even given that Michael's poor expereiences with
GL_GENERATE_MIP_SGIS do look to be a driver bug.
The first bug is that the terrain tiles will page out to a lower LOD when they are right in front of you. The issue appears to be with the blacklisting heuristic which forces a tile to LOD 1, commenting out the usage of blacklisting with the LOD Nodes fixes our problem. This code change was made to line 29 of TXPPageLOD.cpp.
The second bug we were experiencing is that the database reader options never make it through to the archive loader. The use case for us appeared when the FID codes for the terrain were no longer on the materials. As it turns out the archive was being created twice, once by TXPNode and once by the ReaderWriterTXP on getArchive() so the options never actually got set on the archive that was being loaded. The fix is to first create the archive by calling getArchive on the ReaderWriterTXP, which stores it in a map for reference later, and then passing that archive into the TXPNode for it to set its internal member. With this code change we only create one archive (not sure what creating two did) and our options flags get set properly on the database.
The changes made are in TXPNode.h line 72 where the TXPArchive is now passed in. In the TXPNode.cpp the loadArchive(TXPArchive*) was changed to have the default behavior if NULL is passed in, if an archive is passed in then it does not load it since all the loading is done in the ReaderWriterTXP::getArchive(). The only other place that loadArchive is called is in TXPIO.cpp where a modification was made to pass in NULL which will have the same behavior as it used to. The last change is the little block of code starting on line 57 of ReaderWriterTXP.cpp, this was changed so that it first calls getArchive() which caches the archives in a map does some loading stuff and returns a pointer to it which is then passed in as a parameter to TXPNode::loadArchive().
The performance changes were made to TXPParser.cpp line 163 where we use to osgUtil::Optimizer on the node before passing it off, and on line 1456 we changed the geometry to use display lists. These small changes actually made drastic performance increases for us, as much as 1000% on certain laptops.
As far as testing goes, we have tested these changes with at least 5 txp databases on a variety of different computers including Mac OS and Linux. The base version used is 2.4."
The reason is if you want to build an application that use a library that use openscenegraph you have to build the full chain in debug or in release.
On windows you have no choice, but on linux you can link with both version without rebuilding everything ...
The patch consist only to change the line on one line
SET(CMAKE_DEBUG_POSTFIX "d")
with
SET(CMAKE_DEBUG_POSTFIX "d" CACHE STRING "add a postfix, usually d on windows")"
now holds the dirty flag and enables/disables event traversal in response dirty
being set/unset. This allows terrain to be automatically updated in response
to Terrain scale and sample ratio changes.
osg::ref_ptr<osg::Node> ReaderWriterVRML2::convertFromVRML(openvrml::node *obj)
The fixes are:
* Added the source's parent directory as search directory for image files.
* The material properties are now set in the stateset of the Geode rather than the Geometry. This will allow geometries to be reused with different material properties in future updates.
NB: I planned for a caching scheme in which multiple occurences of the same primitive (e.g., Cylinders with radius 0.8 and height 1.2), would use the same Geometry object. Unfortunately, my planning moved me to other areas, but I might still finish the caching scheme in a quiet hour. For the time being I decided it would be a good thing to already submit my current changes.
"
Cause: possibly a copy/paste typo in src/osgPlugins/osg/LineStipple.cc, line 61:
if (fr[0].matchWord("functionMask") && fr[1].getUInt(mask))
Solution: change to:
if (fr[0].matchWord("pattern") && fr[1].getUInt(mask))"
Finally it seems to not come from the empty geode. The origin of the problem seems to be the uniform initialization during the building of the program which call a glUseProgram.
If your scene never display the node that contains the shader and if there is no other shader on the scene, this "glUseProgram" is the only one that is called during your simulation. So, this shader is applied on all the scene.
I fix this bug by switching off the shader (by calling glUseProgram(0) ) during the compilation of a state which does not contain the shader.
"
Changes includes:
1. A new GifImageStream class (inherit from osg::ImageStream and OpenThreads::Thread) have already been added to implement different operations of a GIF movie, such like playing, pausing, rewinding, setting time and so on.
2. Some small changes to decode_row() and gif_read_stream(), which make the transparency of GIF images correctly.
3. Just a few changes to the ReaderWriterGIF::readGIFStream() function, which ensure that animate GIFs are loaded by GifImageStream (and the function returns GifImageStream objects) and static GIFs unchanged (still use the old method and returns osg::Image objects!).
Attachments are the cpp file and an animate GIF file for further test. Just rebuild the osgdb_gif project and use osgviewer or osgmovie to view it.
The plugin has been tested on Windows and Arch Linux."
"Here is a collection of changes which should fix issues building the OSG with CMake 2.6.0 (along with some other changes)
CMakeLists.txt:
* Set CMP0003 to supress warning about linking against -lpthread (which is a
non-absolute library location). (CMake 2.6.x fix)
* Modified the WIN32_USE_MP and a couple of other Visual Studio specific flags
to be in an IF(MSVC) block (minor tweak to reduce exposing this stuff on MinGW builds)
* Includes my second set of glu tesselator autodetection changes that you
seemed to want but haven't committed yet.
src/OpenThreads/pthreads/CMakeLists.txt:
* Eliminates warning when compiling on Linux about spaces in link line (CMake 2.6.x fix)
CMakeModules/OsgMacroUtils.cmake:
* Tweaks to make the macros behave properly under CMake 2.6.0 (doesn't change behavior under CMake 2.4.x)
CMakeModules/Find3rdPartyDependencies.cmake:
* Adds the NO_DEFAULT_PATH option to all of the search options so that things in C:\Program Files\OpenSceneGraph aren't accidently picked up during configure time and instead only things in the "3rdParty" folder are discovered. (general bugfix)
"
post 2:
"Ok, hold the presses. I just discovered that for some odd reason the osgdb_* plugins under Linux aren't getting put under the osgPlugins-2.5.0 folder. Not exactly sure why this broke, the folder was there, just empty. I'll have to look into it this evening."
post 3:
"Fixed, was caused by the switch to CMAKE_LIBRARY_OUTPUT_DIRECTORY and some code in osgPlugins/CMakeLists.txt that effectively overrides LIBRARY_OUTPUT_PATH on non-MSVC compilers to dump the plugins in the plugins folder. I tweaked it to override CMAKE_LIBRARY_OUTPUT_DIRECTORY as well. Seems to work fine."
osgconv cessna.osg cessna.dae
Examination of the resulting .dae file reveals several out-of-range tristrip indices; viewing the .dae file in osgviewer causes a crash when OSG tries to lookup those indices.
Attached resolves this issue."
- Solves issues of loading image data into the texture memory
- Print a warning if images are of different dimensions or have different internal formats (GL specification requires images to be the same)
Patch is tested and seems to work fine. It shouldn't break any other functionality. It should go into include/osg and src/osg
"
CLAMP ->GL_CLAMP_TO_EDGE
NONE->GL_CLAMP_TO_BORDER
The current 2.5.0 daePlugin assumes the following binding
CLAMP ->GL_CLAMP
NONE->GL_REPEAT
Notably the GL_CLAMP binding will result in visible black seams on input files that use otherwise matching textures. Replacing GL_CLAMP by GL_CLAMP_TO_EDGE solves this problem. I've updated both the read and write functions.
"
* I split the mouse handling from a monolithic method to separate ones, slightly cleaner than a whole bunch of if()'s, especially with another case of the mouse entering the canvas.
* I changed the EVT_KEY_DOWN handler to an EVT_CHAR handler, although that now makes the up and down handler assymetric. The new down-handler returns translated key codes, so when you press the S key (without anything else), it actually returns 's' and not 'S' as the EVT_KEY_DOWN did. This means that statistics can be called up in the viewer window, while the example previously only printed a "Stats output:" line to the console. I'm not truly happy that the up handler returns _untranslated_ key codes. But solving this completely would probably mean adding some table that translated from wxWidgets' untranslated key codes to OSG's internal ones. This might be interesting to add, as anyone using OSG + wxWidgets in any serious manner would also have to add this.
* I commented out the evt.Skip()'s in the keyboard handlers as these would only be necessary if there were some key events that are not handled. But currently all key events are simply forwarded.
* I changed the handling of a mouse drag to a more general mouse move"
multi-threaded paging, where the Pager manages threads of reading local
and http files via seperate threads. This makes it possible to smoothly
browse large databases where parts of the data are locally cached while
others are on a remote server. Previously with this type of dataset
the pager would stall all paging while http requests were being served,
even when parts of the models are still loadable virtue of being in the
local cache.
Also as part of the refactoring the DatabaseRequest are now stored in the
ProxyNode/PagedLOD nodes to facilitate quite updating in the cull traversal,
with the new code avoiding mutex locks and searches. Previous on big
databases the overhead involved in make database requests could accumulate
to a point where it'd cause the cull traversal to break frame. The overhead
now is negligable.
Finally OSG_FILE_CACHE support has been moved from the curl plugin into
the DatabasePager. Eventually this functionality will be moved out into
osgDB for more general usage.
ReaderWriter::ReadResult now has a FILE_REQUEST enum.
ReaderWriter::Options now has a s/getAsynchronousFileReadHint() parameter methods.
libcurl based plugin now detects enabing of the AsynchronousFileReadHint, but
as yet does not handle async requests - handling everything syncronously.
DatabasePager now by default will enable AsynchronousFileReadHint for http
based file requests
There was a problem converting a file to Collada by using osgconv like this:
osgconv file.osg file.dae
You would get an error message:
I/O error : Permission denied
I/O error : Permission denied
error : xmlNewTextWriterFilename : out of memory!
Error: daeLIBXMLPlugin::write(file://cessna.dae) failed
Warning: Error in writing to "cessna.dae".
This was due to some bad URI processing code in the Collada plugin. The attached file fixes this by using the Collada DOM's URI processing functions. After this change the file will convert successfully in the local directory.
"
It might seem odd that the change actually removes the stub apply(Billboard&) method, but it turns out Billboards are easily supported in subordinate routines of the existing apply(Geode&) method with s dynamic_cast, so there's no need for a separate apply(Billboard&)."
avoid threading issues associated with compile running in a parallel with
update/cull on the first frame.
Also added automatic recompile when a new SceneData is applied to a View.
get an excess Tab key report when switching back to an OSG
application (usually FlightGear :-). Although KDE has consumed
the Tab, it's sometimes still in the XKeymapEvent's key_vector,
and followed by a Tab KeyRelease event.
Avoid this artifact by
- asking for a "fresh" keymap (via XQueryKeymap()), rather than
using the unreliable(?) XKeymapEvent's key_vector, and by
- flushing all key events on focus-in (to avoid the KeyRelease)
After Super-press, Tab-press, Super-release, Tab-release (note
the wrong release order!) I still get an extra Tab event. But
this is not surprising and not exactly wrong either. Also it's
hard to avoid, as we can't see what happened to the keyboard
before we regained focus.
Files changed:
src/osgViewer/GraphicsWindowX11.cpp
include/osgViewer/api/X11/GraphicsWindowX11"
I've spotted huge memory leaks int ShapeParser and fixed them.
Also, there was a missing destructor (PolygonM) and a missing member initialization (PolygonZ)
Would be nice if someone could test the changes.
To release the memory just if no reading error happened (and therefore the arrays would be valid) I've added an macro to release and reset the pointers at once. I'm not using macros myself very often as I don't like them, but I think it doesn't hurt in this code.
"
In essence, the FLT exporter was emitting a full set of Mesh records each time it encountered a PrimitiveSet.
Attached is a fix. The code now emits the Mesh set up records, then iterates over all PrimitiveSets and emits a Mesh Primitive record per PrimitiveSet.
It also loops over PrimitiveSets twice, first writing Face records according to the mode, the writing Mesh records (again according to the mode).
The final change included here is support for GL_POINTS as single-vertex Face records.
Billboards are still to come."
It's implemented in the same way that 3D Spherical Display and Panoramic Spherical Display.
You can test it running:
osgviewer --wowvx-20 cow.osg
osgviewer --wowvx-42 cow.osg
depending on the size of your Philips WOWvx display (20" or 42")
Other arguments you can use to control the 3D effect are:
--wow-content <value>
This value defines the kind of content that can be:
0: No depth
1: Signage
2: Movie
3: CGI
4: Still
--wow-factor <value>
Percentage of the display recommended depth value. Default 64, Range [0-255]
--wow-offset <value>
Amount of range behind the screen. Default 128, Range [0-255]
0: Range is shifted in the direction of the viewer.
128: Range is equally divided in front and behind the screen.
255: Range is shifted away from the viewer.
"
find libcurl. Mike's 3rdParty only has curllib.
I realize now that the in appended file I have earlier removed
searching for freetype219 since I have it but it will break the build
of osg."
I removed QTtexture.h/.cpp and added QTImportExport.h/.cpp. I updated the CMake-files, I hope they are alright. I used the submitted code in my own apps since two months or so and it seems pretty stable, but as always the migration to the osg-quicktime plugin may have introduced new bugs, so perfect for developer release :)"
from: DEEP_COPY_STATESETS = 8,
to: DEEP_COPY_STATESETS = 1<<3,
showing clearly that this isn't the _value_ 8, but the _bit_ 8. this is an old pattern i see (and like to promulgate) to make code a bit more readable and maintainable.
"
From Robert Osfield, refactored the FrameBufferObejcts::_drawBuffers set up so that its done
within the setAttachment method to avoid potential threading/execution order issues.
osgText/Text.cpp: Line 502
...
else
{
++itr;
}
if (itr!=_text.end())
{
// skip over spaces and return.
while (*itr==' ') ++itr; // New
if (*itr=='\n') ++itr;
}
// move to new line.
switch(_layout)
{
.."
* Support for Vec4ubArray for color data
* Support for material transparency
Thanks to Neil Hughes, Jason Daly, yourself, and others for testing and reporting issues."
in Microsoft compilers as discussed in osg-users. There is now an
advanced option called WIN32_USE_MP (which defaults to OFF) that will
enable the /MP switch for all builds. I tucked this code block safely
within a IF(WIN32) branch."
hyper keys defined already, but these modifiers were missing in
GUIEventAdapter::ModKeyMask, and the EventQueue ingored them as well.
The attached diff/archive adds the missing parts for Super/Hyper
modifier key support.
I'm aware that this might not be supported on all systems/keyboards
out of the box, but decided to submit it anyway because:
- developers are aware of differences between input devices
(Some mice have scroll wheels, others don't. Some have five or
more buttons, some have only one. Some keyboards don't have
numpads, some have AltGr, some don't etc.)
- even if someone relies on Hyper/Super in distributed software,
this is easy to fix and doesn't create lock-in conditions
- while the names Hyper/Super may only be common on X11, they are
just symbol names and not OS-specific
- even though some systems might not offer these additional modifiers
by default, it's likely that all of them have at least 8 modifier
levels internally, so it should only be a matter of OS configuration
to make them work
- having super/hyper available is useful to offer a user ways
to define local key definitions that are safe from collisions with
predefined "official" key assignments"
filesystem is case-sensitive. Here are the modifications needed to make
the compiler happy. These are only some include lines rewritten (Io.h to
io.h, Windows.h to windows.h etc.) for version 2.3.7."
2) complementarily add a "--overallNormal" to replace
per-vert/per-facet normals with an overall. simplifier doesn't work
in certain cases without less complex normals. this gets that done.
3) add env var output with full verbose output so people realize it's
active when the app is run - i see this all the time in training where
people run osgconv, with unintended data transformations due to
osgUtil:;Optimzer, for example"
Introduced code in BoundgingSphere, BoundingBox, ProxyNode and LOD to utilise the above settings.
Added Matrix::value_type, Plane::value_type, BoundingSphere::value_type and BoundingBox::value_type command line
options that report where the types of floats or doubles.
unconditionally sets the X11 error handler routine, replacing anything
that was previously set. This is a bit unfriendly, as the X11 error
handler is a global attribute which the application, or the GUI toolkit
being used, may well have set itself.
So I have modified X11WindowingSystemInterface to only replace the error
handler if it is the default i.e. if the application has not set it."
images with BGR order but not read them. My 2-liner fixed it for me
but it may be that someone with more knowledge of the plugin want to
insert more pixel formats in the reading part of the plugin."
requests for files in a archive are made with unix style paths. So to
be able to match an entry in map(_indexMap) it's keys needs to be
stored in unix style even on Win32"
Note from Robert Osfied, simplified this submission so that the added conversion to
unix slahes is done on all platforms as this should be safe and simpler to maintain.
This change has been done to make it easier for OpenSceneGraph users to check out the svn via https
without any conflicts introduced with a http externals.
as not expiring subgraphs quick enough to enable reasonable load balancing.
New version isn't perfect and will need further work, but does at least reduce
the memory footprint by as much as half on test paths on big databases.
The rewritten method no longer uses the the MaximumNumOfRemovedChildPagedLODs
and MinimumNumOfInactivePagedLODs variables so these and associated methods
for accessing them have been removed.
- /** Set the maximum number of PagedLOD child to remove per frame */
- void setMaximumNumOfRemovedChildPagedLODs(unsigned int number) { _maximumNumOfRemovedChildPagedLODs = number; }
-
- /** Get the maximum number of PagedLOD child to remove per frame */
- unsigned int getMaximumNumOfRemovedChildPagedLODs() const { return _maximumNumOfRemovedChildPagedLODs; }
-
- /** Set the minimum number of inactive PagedLOD child to keep */
- void setMinimumNumOfInactivePagedLODs(unsigned int number) { _minimumNumOfInactivePagedLODs = number; }
-
- /** Get the minimum number of inactive PagedLOD child to keep */
- unsigned int getMinimumNumOfInactivePagedLODs() const { return _minimumNumOfInactivePagedLODs; }
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.
Attached is modified source of AdapterWidget.cpp file from osgviewerQT
example. Original was token today from SVN - trunk. (2.3.6).
--mdi option needs to be set to run MDI version.
Few notes:
- tested on Windows box (Win XP)
- using QT4
- I was not able to execute the example with QOSGWidget - had same
error like described in [osg-users] "fate error using QOSGWidget in
develop release
2.3.0" thread from Shuxing Xiao, 2008-01-08.
- problems are described in source
--
And Later post:
The problem of keypress events was solved by QT community, attached is
repaired AdapterWidget.cpp file.
In the AdapterWidget class constructor following line was added:
setFocusPolicy(Qt::ClickFocus);
Scene disappearing by resizing to minimum still needs to be fixed..."
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."
other GUI toolkit examples. It now takes a model file as command-line
argument (complaining if there isn't one), and its startup window size
is now actually applied (it used to be too small). I tested this with a
unicode-build of wxWidgets, as that is the recommended build type on
Linux with GTK. I'm pretty sure this version of the example will work
for the ANSI build as well, but I have no way of testing."
"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."
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.
"
Added several missing plugins (e.g. osgdb_osgShadow, osgdb_osgViewer, osgdb_Terrain).
Added dependency information hoping that the Xcode 3 parallel target building will work now.
contain better support for environmental variables to pre-empt the
autodection default search path order which is very helpful for people
who do automated builds. (I recommend that the remaining modules
consider adding the same system to make things consistent and easier
for those people that want to do the automated builds.)
The CMAKE_PREFIX_PATH has also been added to help people. I don't
recommend adding this to the other modules because it looks like CMake
agreed with my idea and will be adding the support in 2.6. So when
that ships, people will get it for free. (In the meantime, my modules
that do have it, it can be used.)
Finally, I've submitted all of these modules to official CMake plus
more so they will be in the next version of CMake. It looks like I may
need to sort some compatibility issues out with the KDE people who
seem to have conflicting modules, but this is unrelated to the updates
submitted here as OSG already has these conflicts. I figured I would
just sync OSG up with my current/best versions.
Also of note, I added the large batch of Findosg*.cmake modules to
CMake so people building against OpenSceneGraph can use these without
writing their own. I wasn't sure if I should submit them here or not
since they are for building against OSG and not for building OSG
itself. So they are not included.
"
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."
file. The code works well but the SectorPlacer comments stayed in the new
file. I have altered those comments so they now contain valid information for
the BoxPlacer class and the doxygen generated documentation is correct.
"
fullscreen mode and back between views. (To activate, double click on
the view to toggle.) It demonstrates/uses the new one-liner fullscreen
method introduced in Leopard. Code will still compile and run in
pre-Leopard (thanks to Obj-C dynamic/late binding), but code path is
treated as a no-op in those cases."
CullVisitor/SceneView:
*Feature: This version supports multiple clearnodes in the graph, one per renderstage.
Text:
*Feature: Performance Enhancement when calling SetBackdropColor
Material:
*Fix: OpenGL calls are now made according to the OpenGL Standard
"
- Material class contained both 'shininess' and 'Ns' member variables
- 'Ns' and 'Ni' are initialized to 0 ('Ni' is unused at the moment)
- only 'Ns' was read from .mtl file but 'shininess' was used for osg::Material
- 'illum' was read from .mtl file but never used; it is now used as follows
-- illum==0 -> no osg::Material created/attached therefore no lighting
-- illum==1 -> osg::Material specular is set to black
-- illum==2 (default) -> specular read from .mtl file is used
- 'map_Kd' and 'map_Ks' may contain additional arguments (e.g. '-s 1 1 1'),
these are now skipped over and the texture filename is properly extracted
"
* Support for Box, Sphere, Cone, and Cylinder. These nodes are converted
to osg::Geometry conform the VRML97 spec.
* Backface culling is enabled/disabled according to the "solid" flag for
geometries that are converted from IndexFaceSets.
* PROTO instances can now be used for "appearance" and "geometry" fields
in a Shape node.
The file ReaderWriterVRML2.cpp is adapted for the latest stable public
release:
http://www.openscenegraph.org/svn/osg/OpenSceneGraph/tags/OpenSceneGraph-2.2.0
The changes where needed for being able to read VRML file which are
output by VMD (http://www.ks.uiuc.edu/Research/vmd/). A sample VRML file
is enclosed in this submission.
The plugin has been tested against a number of VRML samples that include
texturing. The texturing is found to be VRML97 compliant for all added
geometry nodes.
"
with the shader for textured objects. This works very well in cases
where there could be a mix of textured and non-textured objects in the
scene, and it makes the initialization more robust.
The idea is from PSSM, to add a 1pixel texture to the main rendering as
to provide white for any objects missing textures."
You were right about the CMAKE_MODULE_LINKER_FLAGS option for CMake, so here is a modification allowing to not generate the manifest files for the plugins making them a lot more easy to redistribute. I have also made the same modification to the wrappers as they are also put into the osgPlugin folder when generated.
"
case is the more tested case, and therefore it is correct to set
_supportsVertexBufferObjects to the same value as _fastPath. So here's a
change that does the same thing for the env var case."
both Jeremy and Anders added static build support as an option, but one was
for Unix and one for Windowsm, but the two mods were also inconsitent in naming
and implementation. I have had a bash at merging them both, but don't know yet
if these changes will work yet on either configuration... user testing will tell...
enhanced version of PolytopeIntersector.
New features of PolytopeIntersector :
* Dimension mask: The user may specify the dimensions of the
primitives to be tested. Checking polytope-triangle and
polytope-quad intersections is rather slow so this can
be turned off.
* Reference plane: The resulting intersections are sorted
by the distance to this plane.
New memebers of PolytopeIntersector::Intersection :
* distance: Distance of localIntersectionPoint to the reference plane
* maxDistance: Maximum distance of all intersectionPoints to the
reference plane.
* intersectionPoints: The points intersecting the planes of the polytope
or points completely inside the polytope.
* localIntersectionPoint: arithmetic mean of all intersection points
* primitiveIndex: Index of the primitive that intersected
I added some more output to the example osgkeyboardmouse."
with the original AdapterWidget implementation still available by default. The new implementation can be accessed by running:
osgviewerQT cow.osg --QOSGWidget
all wonky when I resize the SDL window. I'm not sure if this bug has
always existed or not, but according to the SDL documentation this
operation should be safe regardless, and doesn't not introduce the need
for extra memory management (that is: there is no need to "cleanup" the
old screen variable, that is all handled by SDL for us).
"
highlighted problems with Light, ClipPlane and Hint usage in osg::State's usage of cloneType
and reassignment of target/num in StateSet/these StateAttributes.
size of the image data is greater than the actual image size. This
causes the memcpy call to go out of the array bounds. I modified the
code so that it copies the data during the iteration, instead of
memcpy'ing. This fixes the problems i was having.
If you are curious, the writer was crashing when trying to write an
RGB image that was 2050 x 1280. You might be able to reproduce it by
allocating an empty image of that size and writing it to a file."
window. This breaks rendering in for example MFC SDI applications and in
MFC MDI applications if user resizes the window so that client area has
zero height. Current safeguard for minimized window:
LRESULT GraphicsWindowWin32::handleNativeWindowingEvent( HWND hwnd, UINT
uMsg, WPARAM wParam, LPARAM lParam )
...
/////////////////
case WM_MOVE :
case WM_SIZE :
/////////////////
...
if (clientRect.bottom==0 && clientRect.right==0)
...
does not cover this situation. In these situations clientRect.bottom = 0
and clientRect.right > 0.
Quick fix to this is relax condition:
if (clientRect.bottom==0 || clientRect.right==0)
Modified file is attached.
Tested with osgviewerMFC from 2.2.0 release (Windows XP sp2)
Before fix:
- execute from command line osgviewerMFC.exe cow.osg.
- the cow is rendered nicely.
- resize window to zero height by dragging from bottom border upwards.
- resize window back to original height
- just blue screen, no cow
After fix:
- execute from command line osgviewerMFC.exe cow.osg.
- the cow is rendered nicely.
- resize window to zero height by dragging from bottom border upwards.
- resize window back to original height
- the cow is where it is supposed to be.
"
- Get or set the target number of PagedLOD children to remove per frame.
- Get or set the minimum number of inactive PagedLOD to keep.
Corresponding environment variables have been added too.
The default values reproduce the previous DatabasePager behavior."
Ugh. Another fix for the cycle problem. It seems that the SDKROOT didn't necessarily solve the problem, but there were some unneeded library dependencies that weren't in my test fork which allowed my test to work, but caused SVN to fail.
I have removed some of the excess libraries and it seems to build without the Q&A fix.
CMake build system, enabling this option will build the OSG against the (...) version
of the tesselation callback functions.
One can also set the default value of this option via the DEFAULT_GLU_TESS_CALLBACK_TRIPLEDOT
variable that is set locally to OFF for all platforms except AIX and OSX, but can
be overriden by setting it via command line option i.e.
cmake . -DDDEFAULT_GLU_TESS_CALLBACK_TRIPLEDOT=ON
- set the resolution of the shadow map; it calls dirty() to
re-initialize at next update
- keep a list of Shader objects to use instead of the default ones, if
the list is empty, the default shaders are used
- explicitly create the Uniform variables, so that subsequent additions
that require more Uniforms can put them in a central place
- set a Light or LightSource to use explicitly for shadow casting,
allows multiple lights in the scene, with one casting shadows
There are two additions that do not ( yet ) function correctly, but in
the present usage they do not interfere with the regular usage of the
techique:
- support for using spotlights, it's using Light.spotCutoff to determine
if it's a spot-light and not point-light,
there is an error in the setup of either the shadow camera or the
texgen, most likely due to the direction of the spotlight, since the
position is being used just like in point or directional lights.
- creation of a debugHUD
the hud is created properly, ( the example included shows it ), but
it displays only white, there has been some discussion of displaying the
shadow map, but I could not find it, the addition of a simple fragment
shader with the appropriate color transform should get this going."
"" for all platforms except Cygwin where its set to "cygwin_" and Mingw where
it is set to "mingw_". Updated osgDB::Registry to look for these for the plugins.
Updated the osgintrospection example to search for these names as well.
The options are intended to match the existing read options. By default it will only write RGB32F format; if the "RAW" option is selected, it will output 8 bit RGBA as "raw" RGBE. Note also that the writer inserts a flipVertical(); although the RGBE format, according to spec, should support top-to-bottom or bottom-to-top ordering, no software I've found, including that from the formats originator, actually respects this."
attached code adds this, along with a member variable to keep track of
the setting. It is based on the latest subversion version, and was
tested by creating a new text object with the same axis alignment as an
existing one (e.g.
new_text->setAxisAlignment(old_text->getAxisAlignment()); )."
From Robert Osfield, " I originally didn't add a getAxisAlignment()
as all setAxisAlignment does is set the Rotation member variable, and
potentially one could apply user defined Rotation setting after the
setAxisAlignment() which would bring it out of sync with the
setAxisAlignment.
Rather than reject your submission on the ground of potentially
getting out of sync and therefore misleading users I've added a
USED_DEFINED_ROTATION to AxisAlignment enum, and set this in the
serRotation and then override this setting of _axisAlignment in the
setAxisAlingment method. I've also removed the lazy updating
optimization you've added to the top of setAxisAlignment to avoid
potential problems as well."
I've done some additional small modification regarding constness in ReaderWriter and added
mutable on _pluginData so passing data back would be possible too.
Have updated the collada plugin (ReaderWriterDAE.cpp) to use the map to handle options and
have attached the changes.
The stuff in daeReader.h and daeWriter.h are just cosmetic changes to get rid of a warning."
"This is a fix for the issue reported by Anders a week ago (see \u201c[osg-users] BUG?: mouse coordinate changes after window move\u201d discussion thread on Sept. 20). The issue was that the initial implementation added a few months back was not converting the window coordinates to client-area coordinates resulting in a slight offset each time a decorated window was moved (caused by the window border). This was also causing windows to move out of their assigned screen."
and
"Attached is a fix for the taskbar repaint issue that occurs when a graphics window is toggled from full-screen mode to windowed mode (as identified by Gert van Maren a couple of weeks ago).
Also included is a fix derived from the \u201cEvents from the past\u201d discussion thread that took place on July 11."
(a) some objects behind the camera can cast shadow
(b) object aboive the camera can cast shadow
then i fixed the shadow map orientation, now screen x coordinate alinged which improve the quality"
obj-files. It is not feature complete but usable.
Known issues:
* not all materials are handled correctly (especially when using
osg::StateAttribute::OVERRIDE), not all properties are supported
* could not test point and lines, all of my programs which are capable
to read obj-files only import triangle-meshes.
* only simple texture-handling"
of the OverlayNode.
I change the overlay subgraph dynamically and when I remove all the
subgraph nodes that is inside the current main camera FOV (others
outside still exist), the overlay texture does not update because of the
early return in the traversal. I then get a kind of ghost texture moving
around the terrain.
The attached file fixed the problem for me, but I'm not sure if it is
the best way to address the problem."
two lines has to be included into the Image.cpp in the
computeNumComponents(...) method:
case(GL_RGBA16F_ARB): return 4;
case(GL_RGBA32F_ARB): return 4;"
- When using a large numbrer of files, the command line was too long;
Added a -files option that allow to store filenames in a file (one file
per line)
- Added some more intuitive key bindings for controls (left, right, + ,
-)
- Set the texture wrapping to CLAMP_TO_EDGE (it's cleaner now)
"
It does not like that the prototype of ClipNode::setStateSetModes() differs
from implementation of that function in the constness of the second
parameter.
On SunOS it compiles fine, but I get link errors when the variant that is
declared in the header is referenced.
The attached src/osg/ClipNode.cpp file removes the const qualifier from the
implementation to match exactly the prototype in the header file.
The file is based on revision 7386 as of today.
"
- GL2Extensions, Program and Program.cpp
Features:
- Support for fragment output binding. (e.g. You can now specify in the fragment shader varying out vec3 fragOut; fragOut = vec3(1,0,1); to write to the fragOut variable. In your program you call glBindFragDataLocation(program, 1, "fragOut") to bind the fragOut variable with the MRT 1 - GL_COLOR_ATTACHMENT1_EXT)
- new methods Program::add/removeBindFragDataLocation Program::getFragDataBindingList
"
- Implementation of integer textures as in EXT_texture_integer
- setBorderColor(Vec4) changed to setBorderColor(Vec4d) to pass double values
as border color. (Probably we have to provide an overloading function to
still support Vec4f ?)
- new method Texture::getInternalFormatType() added. Gives information if the
internal format normalized, float, signed integer or unsigned integer. Can
help people to write better code ;-)
"
Futher changes to this submission by Robert Osfield, changed the dirty mipmap
flag into a buffer_value<> vector to ensure safe handling of multiple contexts.
local function pointer to avoid compiler warnings related to case void*.
Moved various OSG classes across to using setGLExtensions instead of getGLExtensions,
and changed them to use typedef declarations in the headers rather than casts in
the .cpp.
Updated wrappers
"A new texture class Texture2DArray derived from
Texture extends the osg to support the new
EXT_texture_array extensions. Texture arrays provides
a feature for people interesting in GPGPU programming.
Faetures and changes:
- Full support for layered 2D textures.
- New uniform types were added (sampler2DArray)
- FrameBufferObject implementation were changed to
support attaching of 2D array textures to the
framebuffer
- StateSet was slightly changed to support texture
arrays. NOTE: array textures can not be used in fixed
function pipeline. Thus using the layered texture as a
statemode for a Drawable produce invalid enumerant
OpenGL errors.
- Image class was extended to support handling of
array textures
Tests:
I have used this class as a new feature of my
application. It works for me without problems (Note:
Texture arrays were introduced only for shading
languages and not for fixed function pipelines!!!).
RTT with Texture2DArray works, as I have tested them
as texture targets for a camera with 6 layers/faces
(i.e. replacement for cube maps). I am using the array
textures in shader programming. Array textures can be
attached to the FBO and used as input and as output."
CmakeLists.txt and to the FindPerformer.cmake module.
Under Windows libs are: libpf.lib (we need to add the lib prefix) and
libpfdu-util.lib (libpfdu and libpfutil are compiled into one lib)
We need to add PFROOT to the search path for libs and includes (default
environment variable for Performer path)
And at last we need to put PFROOT/include and PFROOT/include/Performer
as include dir for compiling."
is targeted by a rigid body which is the reason why the .h-file was changed too.
So now there'll be Group as often as possible, otherwise PostitionAttitudeTransform."
Note from Robert Osfield. A couple of lines of code in ConvertToInventor.cpp
would not compile under g++ 4.1.2, so rather than hold back the dev release till
this is resolved I've optional compiled out the problem section.
The #define DISABLE_PROBLEM_COMPILE_SECTIONS is used to compile out the problem
section, this define is add via the CMakeLists.txt file.
GL_LUMINANCE data instead of GL_RGB data. You can easily check with
"osgViewer --image klink1_l.tif".
The bug is in ReaderWriterTIFF.cpp function simage_tiff_load, where
numComponents_ret is incorrectly set to 1 instead of 3 for color mapped
data."
Attached the modified version of MFC_OSG_MDIView.cpp and MFC_OSG_MDIView.h."
Note from Robert Osfield, submission came with wrong header file, so have had
to guess at what it should be, fingers crossed it worn't break windows build... :-)
osgviewerWX: "To make the example compile using a wx build non UNICODE based.
Tested on Linux with wxGTK 2.8.4"
osgviewerFOX: "Added removeChore() call in the FOX_OSG_MDIView destructor to get rid of a Trace/BPT trap
error on exit on Linux. BTW this is suggested also in the FOX documentation."
stereo format to work. It's a good thing I tested these on a TV
before submitting them since I did indeed have a bug. One thing I
did not test was to see how this would work in windowed mode. Does
the interlaced stereo code have support for 'absolute' positions?
For example a given pixel on the screen is always shown in a given
eye no matter where the graphics context is placed?
"
src/osgDB/FileUtils.cpp to implement the official Windows DLL search
order as described on the page
http://msdn2.microsoft.com/en-us/library/ms682586.aspx . As mentioned,
the search order is now:
1. The directory from which the application loaded.
2. The system directory. (C:\Windows\System32 by default, gotten using the
GetSystemDirectory function)
3. The 16-bit system directory. (C:\Windows\System by default, gotten by
adding "\System" to the path gotten in the next step...)
4. The Windows directory. (C:\Windows by default, gotten using the
GetWindowsDirectory function)
5. The current directory. (".")
6. The directories that are listed in the PATH environment variable. (as
before)
The first four directories are obtained using Win32 API calls, so they
should work correctly even on non-standard Windows installs.
The changes are well commented and should be clear, even to someone
not familiar with the Win32 API.
I have tested in a few scenarios and it works as expected. Serge Lages
has also tested the changes and confirmed they worked as described. I
have not had any other reports though (positive or negative).
I also fixed the issue with a trailing semicolon on the PATH adding an
empty string to the end of the search paths, as this was an
inconsistent side effect rather than a desirable effect. This change
will take effect on other platforms as well, but since it tests for an
empty string in the last item added to the search paths, it should
have no adverse effect.
"
will bring the change in line with what is done on other OSes (Linux)
and works in all tested cases.
For reference, this was tested with:
osgviewer <file>.wrl (file in current directory)
osgviewer <dir>\<file>.wrl (file in child directory, relative)
osgviewer .\<dir>\<file>.wrl (file in child directory, specify current)
osgviewer <drive>:\<dir>\<file>.wrl (absolute path)
"
geometrytechnique in submethods to made more easy the inheritance
between the user and osg-class. This is a first step to add more
functions in osgTerrain. Maybe the subdivision of the method have to
be in the terraintechnique because is the base class of
GeometryTechnique. If Robert or anyone think that this is better i
change this class too."
precise, the shader does not compile on os x because of some
type-conflicts ala "can not convert from const int to const float"
So I changed the offending lines to force the type of the vars. It works
now on OS X (albeit very slowly, 3fps on a 7300), perhaps you find the
changes useful. Note: perhaps there is a better way in shaders to
cast/convert from int to float and viceversa."
updatevisitor in osgViewer::Viewer.
The bug prevented DOF animations because osgSim::DOFTransform checks
the traversal number before doing any updates."
1) added texture->setResizeNonPowerOfTwoHint(false); when loading an
image. It speeds up by 10 the loading of large images.
2) added a --disk option : only a filelist is read, images are only
loaded when needed. It allows to handle very large set of very large
images that would not fit in memory. Nothing change when the option is
not set."
OpenVRML 0.14.3 and is without the Boost dependency.
The changes:
- - Fixed loading of textures and normals when no corresponding indices
are specified. It uses vertex indices now, compliant with the VRML spec.
- - Added colour per vertex support.
- - Added group node support.
- - Changed the code to use osg::ref_ptr instead of naked pointers to
avoid memory leaks.
- - Fixed breakage for loading files specified by relative path."
"I have adapted to osgShadow the soft shadow map technique described in "Efficient Soft-Edged Shadows Using Pixel Shader Branching" by Yury Uralsky, Chapter 17 of GPU Gems 2 (Matt Pharr ed. Addison-Wesley).
Here is my code in attachment: basically, it works in the same way as osgShadow/ShadowMap (core code is copied from it) but implements a specific GLSL shader for the soft rendering of penumbra.
I have tested it under Linux with a NVidia graphic card, but there should be no dependency on platform nor on the graphics driver (as far as they support GLSL 2). Screenshots attached show the current results (frame rate bound to v-sync, but the shader takes actually not much time)."
to the view to be done during syncronous updateTraversal().
This feature can be used for doing things like merging subgraphs that have been loaded
in a background thread.
Attached a modification that read the HeigthField position and X,Yintervals.
I also removed the limitation to 1024*1024 to 4096*4096, because when you are preprocessing your data with OSG, it can be useful to read large images/heigthfields. Is there a reason (other than hardware limitations for textures) for this limit ?"
various operating system differences between socklen_t and int have
broken the FreeBSD build. Change was to add __FreeBSD__ to the list of
defines that are checked."
I just add ReinterpretCastConverter in the Reflector to convert void* in T* and T* in void*
files joint :
OpenSceneGraph/include/osgIntrospection/Reflector // modified file
OpenSceneGraph/src/osgIntrospection/Reflector.cpp // modified file
"
of the source file:
The "delete [] path" appears before the "osg::notify", causing the data pointed to by
"filename" to be deleted before access causing an access violation.
...
I have put a comment on
line 521 where I have moved the "delete []path" below.
"
Changes:
MFC_OSG.cpp:
Removed pixelformatdesciptor from the class initialization.
Used setInheritedWindowPixelFormat to true so it will setup the pixelformat for the window.
Added class destructor code.
MFC_OSG.h:
Removed the ref_ptr on osgViewer::Viewer
MFC_OSG_MDIViewer.cpp:
Changed the OnDestroy function code.
Added WaitforSingleObject with thread handle for the MFC render handle.
MFC_OSG_MDIView.h:
Added class variable for MFC Render Thread Handle for use with the WaitforSingleObject.
"
multiple GraphicsWindows, this singleton is accessable via GUIEventEvent::getAccumulatedEventState().
Added use of this new singleton in GraphicsWindow* implementations.
Added WindowSizeHandler to osgkeyboard to help with debugging of event state
between windows.
Created a new GraphicsThread subclass from OperationThread which allows the
GraphicsContext specific calls to be moved out of the base OperationThread class.
Updated the rest of the OSG to respect these changes.
completed the new registration of the plugin-readerwriters
("REGISTER_OSGPLUGIN") according to your osgstaticviewer-example (see
attachment, based on today's svn)."
Added and cleaned up DeleteHandler calls in osgViewer to help avoid crashes on exit.
Changed DatabasePager across to dynamically checcking osg::getCompileContext(..)
Updated wrappers.
I've also added a little offset to the windows' positions so that their decoration falls inside the desktop and we can manipulate them - it looks a bit less "made out of wood"."
The current code takes the mouse cursor position and adds it to the
window (left,top) position, and sends the mouse cursor there. But this
doesn't take into account the window decoration.
The new code converts the given (x,y) coordinates from the client area
coordinate system to the screen instead using ClientToScreen. I think
this is the natural windows way to do it.
Tested on XP with osgviewer
"
Note from Robet Osfield, made a few changes to layout to make it more consistent
with the rest of the OSG and used #if 0 instead if (0) blocks.
"
Found in the join file the fix for the bug found by Rafa.
Problem :
osgIntrospection::Value grp(new osg::Group);
osgIntrospection::ValueList vlcall;
vlcall.push_back(osgIntrospection::Value("toto"));
const osgIntrospection::MethodInfo *m =
grp->getType.getCompatibleMethod("setName", vlcall, true);
if (m)
{
m->invoke(grp, vlcall); // ** SEGFAULT here
}
Algorithm explanation :
The "invoke" method try to convert "grp", which reflect an
"osg::Group*", in a
"osgIntrospection::Value", which reflect a "osg::Node*".
This because
the "setName(const char *)" method found by
"grp->getType.getCompatibleMethod"
is an "osg::Object" type method.
When osgIntrospection do this conversion it try :
- to found a "osgIntrospection::Converter" to convert
from "osg::Group*" to "osg::Node*"
- to found a chain of "osgIntrospection::Converter" to convert
from "osg::Group*" to "one or many type" to "osg::Node*"
- to converte an Enum to int or unsigned int
- to convert the value in its "value string representation",
then converte this string in the destination value
Else it throw a "TypeConversionException".
Bug :
1)
When osgIntrospection try to found a chain of
"osgIntrospection::Converter"
It could do any downcast or (Type to SuperType) or upcast
(SuperType to Type).
This mean the the chain could be :
osg::Group to osg::Transform to osg::Camera to
osg::CullSettings to osg::CullStack to
osg::CollectOccludersVisitor to
osg::NodeVisitor to osg::Referenced to osg::Object
During the convertion with this chain, A METTRE failed and
the pointer in
"grp" is set NULL. But the "grp" is always a valid
"osgIntrospection::Value"
and so, osgIntrospection accept the conversion. Then it try
to use this pointer
to call the "setName" function. And Bing SEGFAULT.
2)
In "bool Reflection::accum_conv_path( ... )"
the convection path isn't accumulate in the recursive loop.
this cause multi request of a conversion path, and a
slowdown in the
conversion algorithm.
3)
Use of the last conversion way in a conversion from
pointer to pointer
this mean you can do this :
"osg::Node*" to " value string representation" to "osg::Material*"
What a bad thing !!!
Solution :
1)
Introduce the concept of dynamic_cast and static_cast.
now, to do a conversion, osgIntrospection does this :
- to found a "osgIntrospection::Converter" to convert
from "osg::Group*" to "osg::Node*"
- to found a chain of "osgIntrospection::Converter" to convert
from "osg::Group*" to "one or many type" to "osg::Node*"
only with static_cast, downcast (Type to SuperType)
- to found, if the source and the destination are two pointer,
a chain of "osgIntrospection::Converter" to convert
from "osg::Group*" to "one or many type" to "osg::Node*"
only with dynamic_cast, upcast (SuperType to Type)
- to convert an Enum to int or to unsigned int
- to convert the value in its "value string representation",
then convert this string in the destination value
Else it throw a "TypeConversionException".
Add the "enum CastType" to distinguish the static_cast or
dynamic_cast converter.
Add file OpenSceneGraph/include/osgIntrospection/CastType
2)
add a line to accumulate converter in converter Path.
3)
add a line to check if source and destination are pointer.
"
COLLADA modules STLDatabase, LIBXMLPlugin and stdErrPlugin are
statically included in the main COLLADA library on Linux and shouldn't
be linked separately - those libraries do not exist in the default Linux
build and the compilation will fail.
Second issue - the current version of the COLLADA plugin (both current
HEAD in Subversion and the one in stable 2.0) do not work right with the
stable COLLADA DOM 1.4.1. I am getting the following error:
"
MESSAGE("Warning: A critical CMake bug exists in 2.4.6 and below. Trying to build Universal Binaries will result in a compile error that seems unrelated. Either avoid building Universal Binaries by changing the CMAKE_OSX_ARCHITECTURES field to list only your architecture, or upgrade to the current CVS version of CMake or a newer stable version if it exists.")
MESSAGE("Warning: disabling versioned options 2.4.6 exibits inconsintencies in .pdb naming, at least under MSVC, suggested upgrading at least to 2.4.7")
# To select a specific version of QT define DESIRED_QT_VERSION
# via cmake -DDESIRED_QT_VERSION=4
IF(DESIRED_QT_VERSION)
IF(DESIRED_QT_VERSIONMATCHES4)
FIND_PACKAGE(Qt4)
ELSE(DESIRED_QT_VERSIONMATCHES4)
FIND_PACKAGE(Qt3)
ENDIF(DESIRED_QT_VERSIONMATCHES4)
ELSE(DESIRED_QT_VERSION)
FIND_PACKAGE(Qt4)
IF(NOTQT4_FOUND)
FIND_PACKAGE(Qt3)
ENDIF(NOTQT4_FOUND)
ENDIF(DESIRED_QT_VERSION)
#use pkg-config to find various modues
INCLUDE(FindPkgConfigOPTIONAL)
IF(PKG_CONFIG_FOUND)
INCLUDE(FindPkgConfig)
PKG_CHECK_MODULES(GTKgtk+-2.0)
IF(WIN32)
PKG_CHECK_MODULES(GTKGLgtkglext-win32-1.0)
ELSE(WIN32)
PKG_CHECK_MODULES(GTKGLgtkglext-x11-1.0)
ENDIF(WIN32)
PKG_CHECK_MODULES(RSVGlibrsvg-2.0)
PKG_CHECK_MODULES(CAIROcairo)
ENDIF(PKG_CONFIG_FOUND)
#
# Enable workaround for OpenGL driver crash with occlusion query
#
OPTION(OSG_FORCE_QUERY_RESULT_AVAILABLE_BEFORE_RETRIEVAL"Set to ON to build OcclussionQueryNode with a workaround for multi-threaded OpenGL driver occlussion query crash. "OFF)
OPTION(OSG_GLU_TESS_CALLBACK_TRIPLEDOT"Set to ON to build build with variable parameter (...) version of GLU tesselator callback"${DEFAULT_GLU_TESS_CALLBACK_TRIPLEDOT})
IF(OSG_GLU_TESS_CALLBACK_TRIPLEDOT)
ADD_DEFINITIONS(-DGLU_TESS_CALLBACK_TRIPLEDOT)
ENDIF(OSG_GLU_TESS_CALLBACK_TRIPLEDOT)
# Platform specific:
# (We can approach this one of two ways. We can try to FIND everything
# and simply check if we found the packages before actually building
# or we can hardcode the cases. The advantage of the former is that
# or we can hardcode the cases. The advantage of the former is that
# packages that are installed on platforms that don't require them
# will still get built (presuming no compatibility issues). But this
# also means modules that are redundant may get built. For example,
# will still get built (presuming no compatibility issues). But this
# also means modules that are redundant may get built. For example,
# OS X doesn't need GIF, JPEG, PNG, TIFF, etc because it uses QuickTime.
# Also, it will clutter the CMake menu with "NOT_FOUND".
# The downside to the latter is that it is harder to build those
# Set defaults for Universal Binaries. We want 32-bit Intel/PPC on 10.4
# Set defaults for Universal Binaries. We want 32-bit Intel/PPC on 10.4
# and 32/64-bit Intel/PPC on >= 10.5. Anything <= 10.3 doesn't support.
IF(APPLE)
# These are just defaults/recommendations, but how we want to build
# out of the box. But the user needs to be able to change these options.
# So we must only set the values the first time CMake is run, or we
# So we must only set the values the first time CMake is run, or we
# will overwrite any changes the user sets.
# FORCE is used because the options are not reflected in the UI otherwise.
# Seems like a good place to add version specific compiler flags too.
IF(NOTOSG_CONFIG_HAS_BEEN_RUN_BEFORE)
# This is really fragile, but CMake doesn't provide the OS system
# version information we need. (Darwin versions can be changed
# This is really fragile, but CMake doesn't provide the OS system
# version information we need. (Darwin versions can be changed
# independently of OS X versions.)
# It does look like CMake handles the CMAKE_OSX_SYSROOT automatically.
IF(EXISTS/Developer/SDKs/10.5.sdk)
SET(CMAKE_OSX_ARCHITECTURES"ppc;i386;ppc64;x86_64"CACHESTRING"Build architectures for OSX"FORCE)
IF(EXISTS/Developer/SDKs/MacOSX10.5.sdk)
# 64-bit compiles are not supported with Carbon. We should enable
# 64-bit compilation by default once osgviewer has been
# rewritten with Cocoa.
#SET(CMAKE_OSX_ARCHITECTURES "ppc;i386;ppc64;x86_64" CACHE STRING "Build architectures for OSX" FORCE)
SET(CMAKE_OSX_ARCHITECTURES"ppc;i386"CACHESTRING"Build architectures for OSX"FORCE)
SET(CMAKE_CXX_FLAGS"${CMAKE_CXX_FLAGS} -mmacosx-version-min=10.5 -ftree-vectorize -fvisibility-inlines-hidden"CACHESTRING"Flags used by the compiler during all build types."FORCE)
ELSE(EXISTS/Developer/SDKs/10.5.sdk)
ELSE(EXISTS/Developer/SDKs/MacOSX10.5.sdk)
IF(EXISTS/Developer/SDKs/MacOSX10.4u.sdk)
SET(CMAKE_OSX_ARCHITECTURES"ppc;i386"CACHESTRING"Build architectures for OSX"FORCE)
SET(CMAKE_CXX_FLAGS"${CMAKE_CXX_FLAGS} -mmacosx-version-min=10.4 -ftree-vectorize -fvisibility-inlines-hidden"CACHESTRING"Flags used by the compiler during all build types."FORCE)
@@ -352,22 +617,55 @@ IF(APPLE)
# Should break down further to set the -mmacosx-version-min,
# but the SDK detection is too unreliable here.
ENDIF(EXISTS/Developer/SDKs/MacOSX10.4u.sdk)
ENDIF(EXISTS/Developer/SDKs/10.5.sdk)
ENDIF(EXISTS/Developer/SDKs/MacOSX10.5.sdk)
ENDIF(NOTOSG_CONFIG_HAS_BEEN_RUN_BEFORE)
OPTION(OSG_BUILD_APPLICATION_BUNDLES"Enable the building of applications and examples as OSX Bundles"OFF)
= !OpenSceneGraph 2.6 release adds osgWidget library, KdTree intersections, Anti-aliased FBOsand much more. =
PERTHSHIRE, Scotland - 5th August 2008 - !OpenSceneGraph Professional Services announces the release of !OpenSceneGraph 2.6, the industry's leading open-source scene graph technology, designed to accelerate application development and improve 3D graphics performance. !OpenSceneGraph 2.6 written entirely in Standard C++ and built upon OpenGL, offers developers working in the visual simulation, game development, virtual reality, scientific visualization and modeling markets - a real-time visualization tool which eclipses commercial scene graph toolkits in functionality, stability and performance. !OpenSceneGraph 2.6 runs on all Microsoft Windows platforms, Apple OS/X, GNU/Linux, IRIX, Solaris, HP-UX, AIX and FreeBSD operating systems.
=== Open-source development delivers industry-leading features and performance ===
The !OpenSceneGraph 2.6 release is the culmination of 9 years of work by the lead developers and the open-source community that has grown up around the project. The real-time graphics industry and academia embraced it from the very beginning, deploying it in real-world applications, and actively participating in its development, testing and refinement. The end result is a high-quality library with a feature set relevant to application developers' needs.
=== Updates include: ===
* New osgWidget library for scene graph based graphics user interface elements (beta release).
* KdTree support, with automatic KdTree generation on load and use of KdTree during line intersections which massively improves intersection speeds.
* Precision improvements to line intersections, provide accurate whole earth intersection.
* OpenGL Multi-sample FrameBufferObject support.
* New osg::ImageSequence class for doing texture animation of a series of image files.
* New database optimizer that is able to remove static transforms by duplicating shared geometries.
* Use glGenerateMipmap to speed up mipmap generation in non power-of-two textures.
* New osgViewer::ScreenCaptureHandler for adding screen shot support to osgViewer applications.
* New osgscreencapture example that demonstrates use of double buffer PixelBufferObject's for streaming of imagery from the screen.
* New utility application osgfilecache which can be used to populate the local cache for given lat/lon ranges and levels.
* Rewritten DatabasePager that now supports multiple database reading threads. This includes handling of HTTP requests via a separate reading thread, vastly improving the speed of updates when handling HTTP hosted databases that have already partially been downloaded to local file cache.
* Support for a file cache for locally caching paged databases hosted over HTTP.
* Support for http authentication in osgDB and the libcurl plugin
* New osgconv --format <fmt>, --formats and --plugins command line options for listing available plugins and the file formats/options they support.
* Performance improvements in handling TerraPage.
* Animated GIF support.
* New SVG image loader.
* Improvements to the .obj loader to support a wider range of .obj files and material properties.
* Support for thread safe Atomic reference counting.
* Support for COLLADA DOM 2.x
* Support for Philips WOWvx 3D auto-stereoscopic displays
* New include/osg/Config and include/OpenThreads/Config configuration files, that are automatically generated by CMake, which make more straight forward to build end users applications against OpenSceneGraph versions built with non default build options.
* Support for CMake 2.6
* A wide range of build and bug fixes
=== Downloads and Licensing ===
!OpenSceneGraph is open-source so full source code is provided, and can be copied, modified and used free of charge for commercial and non-commercial use. Access to the source allows end users greater flexibility in how they develop, debug and deploy their applications. They gain productivity and freedom by being able to leverage the tool chain in accordance with their own release cycles. Downloads of binaries and source can be found in the [http://www.openscenegraph.org/projects/osg/wiki/Downloads Downloads] section of the openscenegraph.org website.
!OpenSceneGraph is released under the [http://www.openscenegraph.org/projects/osg/wiki/Legal OpenSceneGraph Public License], which is based on the Lesser GNU Public License (LGPL), permitting the software to be used free of charge across the full spectrum of commercial and open-source applications. Furthermore, it allows both static and dynamic linking of the !OpenSceneGraph libraries without restricting the licensing of the user's software.
=== !OpenSceneGraph Books now available ===
The !OpenSceneGraph Quick Start Guide is now available in Chinese as well as English, and alongside the Reference Manual books can be found at [http://www.osgbooks.com OsgBooks].
=== Professional support and services ===
!OpenSceneGraph project is backed up with professional services by [http://openscenegraph.com OpenSceneGraph Professional Services], based in Scotland, and [http://www.skew-matrix.com Skew-Matrix] and [http://www.blue-newt.com Blue-Newt Software] both based in the USA, and a range of [wiki:Community/Contractors Contractors] from around the world. Services available include:
* Confidential Professional Support
* Bespoke development
* Consultancy
* Training
=== Community support and contributions ===
The diverse and growing community of over 1900 developers is centred around the public osg-users mailing list, where members discuss how best to use !OpenSceneGraph, provide mutual support, and coordinate development of new features and bug fixes. Members of this community come from many different countries with backgrounds ranging from some of the world's largest aerospace companies, game companies, and visual simulation specialists to university researchers, students and hobbyists.
The !OpenSceneGraph project owes a great deal to the community for its development and support, in particular we wish to thank the [http://www.openscenegraph.org/projects/osg/wiki/Support/Contributors/TwoPointSix 324 individuals] from around the world that have directly contributed to the development and refinement of the !OpenSceneGraph code base.
----
About !OpenSceneGraph:[[BR]]
!OpenSceneGraph Project was founded in September 1999 by Don Burns and Robert Osfield.
Further information, screenshots, downloads, documentation, and support links can be found on the !OpenSceneGraph project website http://www.openscenegraph.org.
About !OpenSceneGraph Professional Services:[[BR]]
!OpenSceneGraph Professional Services, founded by project lead Robert Osfield in April 2001, is based in Callander, Perhshire, Scotland, and provides professional services on top of !OpenSceneGraph. Further information about the services it provides can be found at http://www.openscenegraph.com.
= !OpenSceneGraph 2.4 release adds geometry shaders, multiple render targets, support for terrabyte scale terrain databases, writing to !OpenFlight and much more. =
PERTHSHIRE, Scotland - 25th April 2008 - !OpenSceneGraph Professional Services announces the release of !OpenSceneGraph 2.4, the industry's leading open-source scene graph technology, designed to accelerate application development and improve 3D graphics performance. !OpenSceneGraph 2.4 written entirely in Standard C++ and built upon OpenGL, offers developers working in the visual simulation, game development, virtual reality, scientific visualization and modeling markets - a real-time visualization tool which eclipses commercial scene graph toolkits in functionality, stability and performance. !OpenSceneGraph 2.4 runs on all Microsoft Windows platforms, Apple OS/X, GNU/Linux, IRIX, Solaris, HP-UX, AIX and FreeBSD operating systems.
=== Open-source development delivers industry-leading features and performance ===
The !OpenSceneGraph 2.4 release is the culmination of 9 years of work by the lead developers and the open-source community that has grown up around the project. The real-time graphics industry and academia embraced it from the very beginning, deploying it in real-world applications, and actively participating in its development, testing and refinement. The end result is a high-quality library with a feature set relevant to application developers' needs.
=== Updates include: ===
* Support for OpenGL Geometry shaders
* Support for OpenGL Multiple Render Targets extension to Frame Buffer Objects
* Support for OpenGL Occlussion Query extension
* New !OpenFlight writer
* New libcurl based plugin for reading http hosted databases
* Quicktime based reading of live video streams under Windows and OSX
* Better load balancing in database pager
* Improvements to osgTerrain for support of terrabyte scale whole earth terrain databases
* Additions to the Shapefile loader with .dbf attribute file, .proj projection file support and loading data as doubles
* Enhanced intersection functionality including double support for line intersections
* Parallel build support under Visual Studio
* Support for reading Producer .cfg viewer configuration files
* A wide range of build and bug fixes
=== Downloads and Licensing ===
!OpenSceneGraph is open-source so full source code is provided, and can be copied, modified and used free of charge for commercial and non-commercial use. Access to the source allows end users greater flexibility in how they develop, debug and deploy their applications. They gain productivity and freedom by being able to leverage the tool chain in accordance with their own release cycles. Downloads of binaries and source can be found in the [http://www.openscenegraph.org/projects/osg/wiki/Downloads Downloads] section of the openscenegraph.org website.
!OpenSceneGraph is released under the [http://www.openscenegraph.org/projects/osg/wiki/Legal OpenSceneGraph Public License], which is based on the Lesser GNU Public License (LGPL), permitting the software to be used free of charge across the full spectrum of commercial and open-source applications. Furthermore, it allows both static and dynamic linking of the !OpenSceneGraph libraries without restricting the licensing of the user's software.
=== !OpenSceneGraph Books now available ===
The !OpenSceneGraph Quick Start Guide is now available in Chinese as well as English, and alongside the Reference Manual books can be found at [http://www.osgbooks.com OsgBooks].
=== Professional support and services ===
!OpenSceneGraph project is backed up with professional services by [http://openscenegraph.com OpenSceneGraph Professional Services], based in Scotland, and [http://www.skew-matrix.com Skew-Matrix] and [http://www.blue-newt.com Blue-Newt Software] both based in the USA, and a range of [wiki:Community/Contractors Contractors] from around the world. Services available include:
* Confidential Professional Support
* Bespoke development
* Consultancy
* Training
=== Community support and contributions ===
The diverse and growing community of over 1800 developers is centred around the public osg-users mailing list, where members discuss how best to use !OpenSceneGraph, provide mutual support, and coordinate development of new features and bug fixes. Members of this community come from many different countries with backgrounds ranging from some of the world's largest aerospace companies, game companies, and visual simulation specialists to university researchers, students and hobbyists.
The !OpenSceneGraph project owes a great deal to the community for its development and support, in particular we wish to thank the [http://www.openscenegraph.org/projects/osg/wiki/Support/Contributors/TwoPointFour 306 individuals] from around the world that have directly contributed to the development and refinement of the !OpenSceneGraph code base.
----
About !OpenSceneGraph:[[BR]]
!OpenSceneGraph Project was founded in September 1999 by Don Burns and Robert Osfield.
Further information, screenshots, downloads, documentation, and support links can be found on the !OpenSceneGraph project website http://www.openscenegraph.org.
About !OpenSceneGraph Professional Services:[[BR]]
!OpenSceneGraph Professional Services, founded by project lead Robert Osfield in April 2001, is based in Callander, Perhshire, Scotland, and provides professional services on top of !OpenSceneGraph. Further information about the services it provides can be found at http://www.openscenegraph.com.
= OpenSceneGraph 2.2 release adds support for advanced displays, soft and parallel split shadow maps and easier builds =
PERTHSHIRE, Scotland - 4th October 2007 - !OpenSceneGraph Professional Services announces the release of !OpenSceneGraph 2.2, the industry's leading open-source scene graph technology, designed to accelerate application development and improve 3D graphics performance. !OpenSceneGraph 2.2 written entirely in Standard C++ and built upon OpenGL, offers developers working in the visual simulation, game development, virtual reality, scientific visualization and modeling markets - a real-time visualization tool which eclipses commercial scene graph toolkits in functionality, stability and performance. !OpenSceneGraph 2.2 runs on all Microsoft Windows platforms, Apple OS/X, GNU/Linux, IRIX, Solaris, HP-UX, AIX and !FreeBSD operating systems.
=== Open-source development delivers industry-leading features and performance ===
The !OpenSceneGraph 2.2 release is the culmination of 8 years of work by the lead developers and the open-source community that has grown up around the project. The real-time graphics industry and academia embraced it from the very beginning, deploying it in real-world applications, and actively participating in its development, testing and refinement. The end result is a high-quality library with a feature set relevant to application developers' needs.
=== Updates include: ===
* Improved build support under Windows including versioning of dll's to avoid problems with mixing !OpenSceneGraph versions on a single system.
* Support for Texture2DArray and integer texture OpenGL extensions.
* Support for spherical displays.
* Support for checkerboard stereo displays.
* Soft Shadows and Parallel Split Shadow Maps now supported.
* Viewer configuration file support
* Writer support for Inventor, OBJ 3D formats
* Writer support for HDR imagery
* Viewer Configuration file support
* Unification of threading models and viewer event handlers so that all now work for both Viewer and !CompositeViewer classes.
* GDAL plugin for support for a wide range of geospatial imagery and digital elevation maps formats.
* A wide range of build and bug fixes.
=== Downloads and Licensing ===
!OpenSceneGraph is open-source so full source code is provided, and can be copied, modified and used free of charge for commercial and non-commercial use. Access to the source allows end users greater flexibility in how they develop, debug and deploy their applications. They gain productivity and freedom by being able to leverage the tool chain in accordance with their own release cycles. Downloads of binaries and source can be found in the [http://www.openscenegraph.org/projects/osg/wiki/Downloads Downloads] section of the openscenegraph.org website. [Downloads Downloads]
!OpenSceneGraph is released under the [http://www.openscenegraph.org/projects/osg/wiki/Legal OpenSceneGraph Public License], which is based on the Lesser GNU Public License (LGPL), permitting the software to be used free of charge across the full spectrum of commercial and open-source applications. Furthermore, it allows both static and dynamic linking of the !OpenSceneGraph libraries without restricting the licensing of the user's software.
=== !OpenSceneGraph Books now available ===
The !OpenSceneGraph Quick Start Guide is now available in Chinese as well as English, and alongside the Reference Manual books can be found at [http://www.osgbooks.com OsgBooks].
=== Professional support and services ===
!OpenSceneGraph project is backed up with professional services by [http://openscenegraph.com OpenSceneGraph Professional Services], based in Scotland, and [http://www.skew-matrix.com Skew-Matrix] and [http://www.blue-newt.com Blue-Newt Software] both based in the USA.
* Confidential Professional Support
* Bespoke development
* Consultancy
* Training
=== Community support and contributions ===
The diverse and growing community of over 1700 developers is centered around the public osg-users mailing list, where members discuss how best to use !OpenSceneGraph, provide mutual support, and coordinate development of new features and bug fixes. Members of this community come from many different countries with backgrounds ranging from some of the world's largest aerospace companies, game companies, and visual simulation specialists to university researchers, students and hobbyists.
The !OpenSceneGraph project owes a great deal to the community for its development and support, in particular we wish to thank the [http://www.openscenegraph.org/projects/osg/wiki/Support/Contributors/TwoPointTwo 282 individuals] from around the world that have directly contributed to the development and refinement of the !OpenSceneGraph code base.
----
About !OpenSceneGraph:[[BR]]
!OpenSceneGraph Project was founded in September 1999 by Don Burns and Robert Osfield.
Further information, screenshots, downloads, documentation, and support links can be found on the !OpenSceneGraph project website http://www.openscenegraph.org.
About !OpenSceneGraph Professional Services:[[BR]]
!OpenSceneGraph Professional Services, founded by project lead Robert Osfield in April 2001, is based in Callander, Perhshire, Scotland, and provides professional services on top of !OpenSceneGraph. Further information about the services it provides can be found at http://www.openscenegraph.com.
For details on how to patch VisualStudio6.0 see the above website link.
Note, osgIntrospection, src/osgWrapper plugins and the
osgintrospection example cannot be compiled under VisualStudio plugin.
You will also need to run the fixup-vc6-dsps.pl script to clean up the
project files that won't otherwise compile to do new elements required
for support of Window 64 bit build under VS 7.x and 8.x.
Several of the plugins and examples require external dependancies. Full details on where to obtain
these can be found in doc/dependancies.html.
--
For syntax highlighting in VisualStudio which the standard C++ style headers
found in the OSG :
VisualStudio6.0
Substiture the LANDEXT.DAT file found in this directory with the one found
*\Common\MSDev98\Bin
VisualStudio7.x & 8.x/.NET
Install the syntaxhighlight.reg (just double click it). This will update
Extensionless file for Visual Studio. Don't worry, it will keep the
current extensionless files (STL ones) intact.
--
How to use the Visual Studio projects:
To build the OpenSceneGraph code in Visual Studio, you normally must use the VisualStudio.sln solution file provided. The individual projects won't build as-is, because they depend on each other and only the VisualStudio.sln file provides those dependencies.
To create a program based on an example, probably the easiest way is to do this:
1. Copy the VisualStudio.sln project to a new file in the same directory
2. Copy the project you want to base your new project on to a new directory in the same level of the directory tree
3. Open the new .sln file you copied in step 1
4. Remove unneeded projects from it, but keep the core libraries (osg, osgDB, etc.). Shift-clicking to select a bunch of projects at once makes this easier to do
5. Add the new project to that solution
6. Set the dependencies for your new project. This is most easily done by opening the Solution Properties dialog, going to Project Dependencies, and checking off the libraries your project depends on
--
Building 64 bit binaries
64 bit OpenSceneGraph and OpenThreads binaries can be built in Visual Studio 8, but several extra steps are required due to limits of the Visual Studio 6 project files:
1. For each of the OpenSceneGraph, and OpenThreads .dsw files, :
a. Open the .dsw or .sln file and convert all projects to VS 8 format.
b. Open the Configuration Manager window under the Build menu, bring up the New Solution Platform window by selecting <New...> in the Active solution platform drop-down menu. Select x64 as the new platform and copy settings from Win32 (you need to have the x64 compiler installed to see the x64 platform option). Ensure the Create new project platforms checkbox is selected. Click OK, then close the Configuration Manager window.
c. Do a "Save All" to save the project files.
2. Visual Studio unfortunately chooses its own Output Directory setting for the x64 configurations in step 1.b., and this must be reset to the Win32 setting.
IF PERL _IS_ INSTALLED (native or Cygwin), do the following:
a. Close all Visual Studio solutions.
b. Open a command shell and cd to the OpenSceneGraph/VisualStudio directory.
c. Run the command "perl reset-64bit-outdirs.pl".
d. Reopen the solutions.
IF PERL _IS NOT_ INSTALLED, do the following to accomplish the same thing manually:
a. In the OpenThreads solution, open the properties window for the OpenThreads project.
i. Select multiple configurations, Debug and Release. Under the General page, overwrite the Output Directory path of the x64 platform with the corresponding Win32 path. For static builds, do the same thing for the Debug Static and Release Static configurations.
b. In the OpenSceneGraph solution:
i. Select all the "Application" and "Example" projects in the Solution Explorer window and repeat step 2.a.i. Note there are no static configurations.
ii. Select all the "Core" projects _except "Core osgIntrospection"_ and repeat step 2.a.i.
iii. Select "Core osgIntrospection" and repeat step 2.a.i. Note there are no static configurations.
iv. Select all the "osgPlugin" projects and repeat step 2.a.i.
v. Select all the "osgWrapper" projects and repeat step 2.a.i. Note there are no static configurations.
c. Do a "Save All" to save the project files.
3. Select the desired x64 configuration, and build away!
This is the readme for the entire OpenThreads/OpenSceneGraph distribution for the OS X frameworks and Xcode projects. This readme was originally written for the binary distribution, but there is a lot of useful information in here so it has also been included with the source code in the Xcode section. This was sync'd with the OSG 1.2 release.\
This is the readme for the entire OpenThreads/OpenSceneGraph distribution for the OS X frameworks and Xcode projects. This readme was originally written for the binary distribution, but there is a lot of useful information in here so it has also been included with the source code in the Xcode section. This was sync'd with the OSG 2.2 release.\
\
The source code is available at {\field{\*\fldinst{HYPERLINK "http://www.openscenegraph.org/"}}{\fldrslt http://www.openscenegraph.org/}}\
\
Also included is a framework for GDAL. You can get the source code and the full GDAL package at {\field{\*\fldinst{HYPERLINK "http://www.gdal.org/"}}{\fldrslt http://www.gdal.org/}}\
\b \
Quick Start:
\b0 \
Screencasts of how to install and get going with OSG for Mac OS X can be found here:\
\b0 \cf0 (See {\field{\*\fldinst{HYPERLINK "http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/MacOSX10.5"}}{\fldrslt http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/MacOSX10.5}} for up-to-date information.)\
\
\b Broken Binary Compatibility:
\b0 \
Apple has broken binary compatibility in a limited way between 10.4 and 10.5 when using OpenGL and C++. Under 32-bit, the GLenum type was changed from long (in 10.4 and before) to int (in 10.5).\
\
Under 32-bit, sizeof(long) == sizeof(int) == 4-bytes.\
(In 64-bit, sizeof(long) == 8-bytes, sizeof(int) == 4-bytes)\
So in C 32-bit, binary compatibility is preserved.\
\
But under C++, even though both types are 4-bytes under 32-bits, C++ name mangling rules treat int and long as fundamentally different types. Thus binary compatibility is broken if you try linking two pieces of code that use different types for GLenum.\
\
\
This means:\
1) If you have a 10.4 SDK (or before) built OSG framework, you cannot build an application using the 10.5 SDK or you will get strange undefined symbol errors if GLenum is used. This means don't develop against the 10.5 SDK on Leopard.\
\
2) You cannot use a 10.5 SDK built OSG framework to build an application using the 10.4 SDK, otherwise this will also give you undefined symbol errors. This means don't develop with 10.5 built OSG frameworks when using the 10.4u SDK on Leopard or developing on 10.4 itself.\
\
3) If you have a 10.4 SDK built OSG framework and a 10.4 SDK built application that uses it, this does *not* present a binary compatibility problem and you may be able to run on 10.5 (ignoring any different compatibility issues).\
\
4) Similarly to #3, if you have a 10.5 SDK built framework and a 10.5 SDK built application that uses it, this does *not* present a binary compatibility problem and you may be able to run on 10.4 presuming there are no specific 10.5 dependencies. (But it is safer to build against the 10.4 SDK if you plan on deploying to 10.4 and use no 10.5 specific features.)\
\
Basically, this means you can't intermix 10.4 and 10.5 frameworks.\
\
You can slip around this problem if you manage to avoid the use of any code that uses GLenum. And pure C is not affected.\
\
\b \
OSG 10.4 and 10.5 SDKs:\
\b0 Xcode 3.0 introduces formal support for SDKs created by 3rd parties (like us). Since we now have binary incompatible frameworks, developing binaries for both 10.4 and 10.5 on the same system is a pain. Having a separate OSG 10.4 and 10.5 SDK may help minimize that pain.\
\
Stay tuned for the SDKs and instructions.\
\
\
\
\f0\b What's New in this release:
\f1\b0 \
\b X11 Link problems:\
\b0 Another common problem developers might experience is:\
Some people have reported a problem similar to this and/or used the solution posted in this Q&A to resolve a problem building the osgdb_freetype plugin. However, I believe this is the wrong solution to this specific problem. In the osgdb_freetype case, the problem was one of two things:\
1) The wrong libfreetype.dylib was being used (wrong SDK)\
2) The libfreetype.dylib was not found (wrong path)\
\
For #1, the Xcode project was linking to /usr/X11R6/lib, but we should have been linking to $(SDKROOT)/usr/X11R6/lib. You would normally experience this problem when compiling against the 10.4u SDK on 10.5.\
\
For #2, the problem was usually experienced by people building against the 10.5 SDK (on 10.5). The problem here is that Leopard has moved from XFree86.org to X.org and the path is now /usr/X11/lib instead of X11R6. Within the SDK, there is no X11R6 path, so the library was not found.\
\
The solution is quite simple and change the link path line to:\
-L$(SDKROOT)/usr/X11/lib -L$(SDKROOT)/usr/X11R6/lib in the Other Linker Flags for the osgdb_freetype plugin.\
\
This is now fixed in the Xcode project in Subversion.\
\
\
\
\b CMake:\
\b0 The CMake/OSG build system is still not quite ready for prime time. CMake has some general Leopard issues and the OS X/CMake community is trying to work through SDK support issues as the SDKs have become a more prominent part of building on OS X correctly. Framework support is still lacking in the CMake/OSG build system, though CMake CVS is gradually adding/fixing this feature to its code base. \
\
\
\b 64-bit:\
\b0 OSG for OS X 64-bit is not ready. There are two major obstacles:\
1) osgViewer\
2) osgdb_qt\
\
The osgViewer backend is written in Carbon and as far as I know, uses some deprecated APIs that are not available in 64-bit. I do not know if this can be easily cleaned up or not. However, I still believe the better long term solution is for a Cocoa based osgViewer backend to be written. However, nothing yet has been written for this as far as I know.\
\
The example, osgviewerCocoa is close to if not already 64-bit clean. However, because the example uses osgViewer::GraphicsWindowEmbedded which needlessly pulls in all the osgViewer Carbon backend dependencies, you will be unable to actually build osgviewerCocoa as 64-bit. But if you are in a hurry to get 64-bit on OS X, this might be where you want to start. Either strip away the Carbon dependencies from osgViewer, or take osgviewerCocoa and transform it into a Cocoa backend for osgViewer.\
\
\
osgdb_qt is a QuickTime based plugin that handles all image handling and movie handling on OS X. However, it is based on the old QuickTime API which has been marked deprecated and will not survive the 64-bit transition. Thus this plugin needs to be replaced.\
\
I have already submitted a new plugin called osgdb_ImageIO to osgSubmissions which attempts to assume all the image handling duties. This plugin is based on Apple's ImageIO framework which is the new low-level entry point to deal with all image types handled by the platform. Thus this plugin should handle a lot more image formats than the old QuickTime plugin (e.g. JPEG2000, RAW, etc) and will get more as Apple adds support their system. It also adds support for C++ stream support which was missing from the QuickTime plugin. ImageIO is available on 10.4 and 10.5.\
\
However, the osgdb_ImageIO plugin does not handle movies unlike the old QuickTime plugin. The current plan is to introduce a second plugin (osgdb_QTKit), which is based on the new QuickTime Kit framework (10.4 and 10.5). This plugin will replace the movie handling capabilities of the old QuickTime plugin. \
\
Once both new plugins are in place and osgViewer is sorted out, we should be able to build a 32-bit/64-bit Universal Binary of OSG for OS X.\
\
Mac OS X 10.3 and earlier users and QuickTime for Windows users will still need to use the old QuickTime plugin.\
\b0 \cf0 {\listtext \'95 }OpenThreads now uses Subversion 'externals' to make it look like part of the OSG source distribution.\
{\listtext \'95 }Producer has been removed from the distribution. osgViewer is supposed to replace it. The Mac OS X backend is currently Carbon based.\
{\listtext \'95 }GDAL has been removed as it is no longer a dependency.\
{\listtext \'95 }osgviewerCocoa (previously osgsimpleviewerCocoa in CVS) is an example program demonstrating tight integration between OpenSceneGraph and Cocoa. It demonstrates many of the things you should consider in building a first-class OS X application that uses OSG.\
\cf0 OSG has changed its versioning number scheme. 2.0 is the stable release following 1.2.\
\
Producer has been removed from the distribution with osgViewer as its intended replacement.\
\
GDAL has also been removed from the distribution as it is no longer a dependency.\
\
OSG is in the process to moving to a new CMake based build system. Once the remaining Mac OS X support needed is implemented in CMake, the Xcode projects will be removed in favor of the new unified CMake system.\
\
With Leopard on the horizon, the need to deal with 64-bit readiness and deprecated APIs is becoming more critical. In a nutshell, we need a Cocoa based version of osgViewer, and the QuickTime plugin needs to be replaced. Currently, there is a new ImageIO based plugin to assume the image reading/writing duties of the old qt plugin. We are in need of a QTKit based plugin to assume the movie responsibilities of the old plugin. And we are in need of volunteers to write the Cocoa osgViewer backend. Currently, the example osgviewerCocoa demonstrates a lot of similar functionality and could be used as a reference. However, the example needs to be turned 'inside-out'. The example is an NSView class that contains OSG classes; the osgViewer needs to be the opposite where the OSG class needs to contain the NSView class.\
\f1\b0 \cf0 1.2 was originally intended as a bug fix release for 1.1 (going for 1.1.1), but OSG broke ABI again so the number was bumped to 1.2. There are no significant changes to the Xcode projects or significant OS X specific changes.\
\b0 \cf0 1.2 was originally intended as a bug fix release for 1.1 (going for 1.1.1), but OSG broke ABI again so the number was bumped to 1.2. There are no significant changes to the Xcode projects or significant OS X specific changes.\
\
Since the 1.1 release, we have learned of serious problems (freezing of the window manager) on the (Intel) MacBook Pros using osgText. We believe the problem is with a serious driver bug for ATI in OS X 10.4.7. We believe the bug affects the ATI Radeon X1600. (You can get this string by calling glGetString(GL_RENDERER) when you have a valid OpenGL Context. The string returned to us on affected MacBook Pros is "ATI Radeon X1600 OpenGL Engine".)\
\f2\i \cf0 osgText subloads small glyphs one by one rather than the whole image, so I'd suspect it is this that is broken. There is a path way in osgText::Font for uploading the whole image at once, which original was specifically implement as a work around for an Octane driver bug, but for 1.1 I enabled this pathway to be selectable via an env var to see if OSX users could work around the OSX driver bug.
\f1\i0 \
\i \cf0 osgText subloads small glyphs one by one rather than the whole image, so I'd suspect it is this that is broken. There is a path way in osgText::Font for uploading the whole image at once, which original was specifically implement as a work around for an Octane driver bug, but for 1.1 I enabled this pathway to be selectable via an env var to see if OSX users could work around the OSX driver bug.
\f2\i \cf0 you can set environement variables that work with applications by creating a file ~/.MacOSX/.environment.plist and put them in there. easiest way is to use the preference pane called RCEnvironment at\
\i \cf0 you can set environement variables that work with applications by creating a file ~/.MacOSX/.environment.plist and put them in there. easiest way is to use the preference pane called RCEnvironment at\
@@ -98,16 +254,17 @@ Don't forget to link against Carbon (-framework Carbon) if you use Gestalt.\
\
If you are affected by this, please file a bug report at {\field{\*\fldinst{HYPERLINK "https://bugreport.apple.com"}}{\fldrslt https://bugreport.apple.com}}. Apple lives and dies by the bug report system. If anything is to get done, it must be in the bug reporter. And they keep count of how many people file the same bug, so duplicates are good.\
\f1\b0 \cf0 We are now distributing Universal Binaries. These binaries were built using Xcode 2.3 and gcc 4.0.1.\
\b0 \cf0 We are now distributing Universal Binaries. These binaries were built using Xcode 2.3 and gcc 4.0.1.\
The Xcode projects are also set to build as Universal Binaries for both Development and Deployment\
targets. If you do not need this and want to save build time, you should change the architecture option\
to your desired setting (most likely to $(NATIVE_ARCH)). It is overridden in the top-level "OpenSceneGraph" project in the Group & Files panel. Don't forget to change OpenThreads \
@@ -130,8 +287,8 @@ We have stopped maintaining the Xcode 1.5/2.0 projects.\
These projects were primarily developed with gcc 4.0.1 under Tiger 10.4.3 using Xcode 2.2. Starting with gcc 4.0, Apple no longer statically links in the C++ runtime. Apple has made available the g++ 4.0 dynamic runtime for Panther under the 10.3.9 release. To run under Panther, your system must have this update (or you must recompile the binaries for your system).\
\
With gcc 4.0, serious bugs have been fixed from gcc 3.3 and new features are available to us so we have experimented with more aggressive optimizations. For these binaries we have enabled -O3 optimization and -mtune=G5. We have also enabled autovectorization. We also enabled -fvisibility-inlines-hidden which is expected to shrink the binary sizes, but noticed very little difference. (There may be something wrong.) We have not done the proper benchmarking with these options, so feedback is welcome.\
@@ -143,8 +300,8 @@ With Apple's announcement of the Intel transition, Xcode 2.1 was released to hel
\
\
\f0\b Acknowledgments:
\f1\b0 \
\b Acknowledgments:
\b0 \
\
Many thanks should be given to the people that have helped make these projects possible and for their contributions to make OSG run well on OS X through the multiyear run-up to 1.0. I unfortunately don't have a comprehensive list as many contributions have been submitted directly to OpenSceneGraph, but I wanted to give mention to these specific people I've had the pleasure of working with in trying to make this corner of the universe work.\
\
@@ -152,14 +309,14 @@ James Hopper (work on Xcode templates, GDAL frameworks)\
David Guthrie (various patches, testing, Xcode project compiler options refinement)\
Jeremy Bell (original comprehensive discussion on OS X frameworks, patches)\
Stephen Travis Pope (provider of the OSG on OS X website)\
Markus St\'9abe (web site design, documentation reviewer and formatter)\
Markus St\'f6be (web site design, documentation reviewer and formatter)\
(And for the curious) Eric Wing (Xcode projects and frameworks, patches, documentation)\
\
\
\
\f0\b Installation:
\f1\b0 \
\b Installation:
\b0 \
\
To "Install" the Frameworks, copy the Frameworks inside the \
frameworks folder to a standard location.\
@@ -196,8 +353,8 @@ Also be aware that if using the 10.4 Universal SDK, you may have to explicitly s
\
\
\f0\b Running the examples:
\f1\b0 \
\b Running the examples:
\b0 \
\
Now that osgViewer supports a native Window manager, we have attempted to provide double clickable .app bundles. We cheat a little to keep the download size smaller by symbolically linking the Frameworks, PlugIns, and Resources directories for each .app bundle instead of giving each its own copy. This allows the apps to find their resources when trying to run directly from the .dmg without having to copy anything to your computer. \
\
@@ -229,15 +386,15 @@ Also remember that OSG will still respond to standard OSG environmental variable
After doing this, when doing a File->New Project, you will see "OSG Application" under the Application category. Selecting this will create a simple OSG project with some sample source code already in place which currently renders 2 colored tetrahedrons.\
\
All the OSG related frameworks are listed already, though gdal and osgTerrain are not checked by default. To link against them, you must check their checkboxes to enable them. Feel free to uncheck or remove frameworks you don't need.\
@@ -299,8 +474,8 @@ Finally, there may still be issues with Zerolink. If you have problems seeing th
The binaries are built using gcc 4.0.1 under Tiger 10.4.7. These binaries also will run under Panther 10.3.9 (which has the needed C++ runtime library). \
\
@@ -310,39 +485,39 @@ Also keep in mind that the prebinding addresses are finicky. Changing the compil
\
If you are compiling under Xcode 1.5 and are using our Xcode 1.5/2.0 projects, there have been reports of problems I have been unable to reproduce. If you do encounter these problems, please try the following. \
\ls2\ilvl0\cf0 {\listtext \'a5 }I have more rigorously tested the Deployment build style than the Development build style so use the Deployment build style. Make sure you are compiling using -Os or -O0 optimization. -O3 is known to have problems under gcc 3.3. \
{\listtext \'a5 }The -mtune=G4 is has been tested more under Xcode 1.5 than -mtune=G5. \
{\listtext \'a5 }I noticed that for some reason, Xcode has problems compiling the Carbon header with the OpenThreads framework when autovectorization and precompiled headers were enabled. You might try disabling precompiled headers if it is not already. If the problem persists, you may also need to delete the entry that enables autovectorization. In the Groups and Files panel (left side panel), open the Info inspector for the project (top item) and click on the Build tab. Scroll down to the bottom, and remove the autovectorization option. \
\ls3\ilvl0\cf0 {\listtext \'95 }I have more rigorously tested the Deployment build style than the Development build style so use the Deployment build style. Make sure you are compiling using -Os or -O0 optimization. -O3 is known to have problems under gcc 3.3. \
{\listtext \'95 }The -mtune=G4 is has been tested more under Xcode 1.5 than -mtune=G5. \
{\listtext \'95 }I noticed that for some reason, Xcode has problems compiling the Carbon header with the OpenThreads framework when autovectorization and precompiled headers were enabled. You might try disabling precompiled headers if it is not already. If the problem persists, you may also need to delete the entry that enables autovectorization. In the Groups and Files panel (left side panel), open the Info inspector for the project (top item) and click on the Build tab. Scroll down to the bottom, and remove the autovectorization option. \
Be aware, when building you're own Universal Binaries and you use the 10.4 SDK, you must explicitly\
list the search path to the frameworks in the project options. It seems that using any SDK will cause\
the standard places like /Library/Frameworks to not be searched.\
\
\f0\b Known Issues:
\f1\b0 \
\b Known Issues:
\b0 \
\
There is one known serious bug that appears sometimes. With Xcode 2.0 and 2.1, in some cases when you build OpenThreads/OSG from scratch, when you run the examples, they will crash on load. The workaround seems to be to delete just the OpenThreads framework after everything is built. Then rebuild just the OpenThreads framework. Bug reports have been filed with Apple, but the root cause remains to be a mystery. (We have some guesses, but nothing substantial.) I have not yet seen this issue emerge with Xcode 2.2, so maybe the problem is fixed.\
\
The osgdb_geo plugin is not big endian safe. The Makefile system does not build it for OS X. We have added it for the Xcode projects, but you probably shouldn't use it unless you're on Intel.\
\
Do not use the
\f4\fs22 -fvisibility=hidden
\f1\fs24 flag unless you know what you're doing. In some cases, Xcode 2.2 seems to enable this by default in the project settings. You should verify your project settings and make sure this is disabled. Among other things, this flag will hide RTTI information causing dynamic_cast<> operations to fail. Since parts of OSG are dependent on RTTI, this option should remain off. The flag
\f4\fs22 -fvisibility-inlines-hidden
\f1\fs24 may be safe to use. (This is actually enabled in our Xcode projects. If there are problems, please let us know.)\
\f2\fs22 -fvisibility=hidden
\f0\fs24 flag unless you know what you're doing. In some cases, Xcode 2.2 seems to enable this by default in the project settings. You should verify your project settings and make sure this is disabled. Among other things, this flag will hide RTTI information causing dynamic_cast<> operations to fail. Since parts of OSG are dependent on RTTI, this option should remain off. The flag
\f2\fs22 -fvisibility-inlines-hidden
\f0\fs24 may be safe to use. (This is actually enabled in our Xcode projects. If there are problems, please let us know.)\
\
Finally, there may still be issues with Zerolink. In the Project Template, we defer to the default for this option and in current Xcode versions, the default is on. The OSG Xcode projects themselves have explicitly disabled Zerolink. In the worst cases, scenes will not render correctly or the application may crash. The worst thing about this is that the problems are so strange, you may not realize Zerolink is the problem. To see this for yourself (we tried in Xcode 2.2), you might try comparing the osgdelaunay example with and without Zerolink, toggling through all values of 'n'. With Zerolink certain objects do not even appear and it crashes. So you are probably should disable this to be safe. However, for the daring, Zerolink does seem to work for some projects though we do not fully understand the criteria for this. Furthermore, Apple constantly works on improving this feature so maybe one day it will all just work right.\
\
\f0\b Misc:
\f1\b0 \
\b Misc:
\b0 \
\
Included with the OSG Xcode projects are some of the little scripts I used to help put everything together. The build script might be of interest to those who wish to produce their own automated nightly builds.\
\
@@ -358,7 +533,7 @@ On the topic of feature requests, another potentially useful thing to have is a
\
\
-Eric Wing\
ewing 2121 - at - yahoo (in the commercial domain)\
ewing . public - at - gmail (in the commercial domain)\
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
