* When used PDS RenderStage::runCameraSetUp sets flag that FBO has already stencil,depth buffer attached. Prevents adding next depth buffer.
* Sets correct traits for p-buffer if used PDS and something goes wrong with FBO setup or p-buffer is used directly.
* Adds warning to camera if user add depth/stencil already attached through PDS.
* Sets blitMask when use blit to resolve buffer.
There is also new example with using multisampled FBO."
I have not reverted added Compiler options. I assume that one may want to have warnings enabled for the application but may not want to see them while OSG libraries and examples compile.
Modified files:
osg/Export - now explicitly includes osg/Config to make sure OSG_DISABLE_MSVC_WARNINGS is read
osg/Config.in - declares OSG_DISABLE_MSVC_WARNINGS flag to be added to autogenerated osg/Config
CMakeLists.txt - declares OSG_DISABLE_MSVC_WARNINGS as option with default ON setting
"
New features
+Read and write of osg::LOD, osg::Switch, osgSim::Sequence, osgim::MultiSwitch and osgSim::DOFTransform data in <extra>
+Read and write of osg::Node description data in <extra>
+Plugin option "NoExtras" to prevent writing of <extra> data and only traverse the active children when saving
Changes/additions
+instanced_geometry and instanced_controller are now loaded in a single Geode with multiple Geometries instead of multiple geodes with a single Geometry
+Changed all calls to the deprecated createAndPlace() to the new add() methods
+All transformation elements <scale>, <rotate>, <translate>, <lookat>, <matrix>, <skew> are now concatenated properly in to a single MatrixTransform.
Previously this was not done in order as required by Collada and and not all elements were included.
+Complete skew matrix creation
+Automatically add GL_RESCALE_NORMAL if scale is non-identity
+Blinn shininess remapping to [0,128] when in range [0,1]
+Changes to CMake file to make it compile on Windows
+Coding style and code documentation
Bug fixes
+Transparent texture writing fixed
+Fixed bug in using osg node name as collada node ID
+Fixed usage of double sided faces in GOOGLEEARTH extra
+Not adding blendfunc and blendcolor when opaque
TODO/Wishlist
-solve differences in drawables, DAE reader should place multiple collation elements into multiple primitivesets in a single geometry where possible (only when same material)
-solve differences in matrices
-multitexture support
-skinned mesh and generic animations using osgAnimation
-profile_GLSL based on COLLADA OpenGL Effects Viewer http://ati.amd.com/developer/rendermonkey/downloads.html
-handling more <extra> to more closely mimic the intended lighting"
The set up for this to work is a bit more complex than most files, since the engine expects all files to be in a certain place, and it tends to mix case a lot. I tried to explain everything in the VBSP_README.txt file."
This plugin has been integrated with the pre-exisiting bsp plugin.
After taking a look at the current state of the BMP loader I decided it might be worth a shot at reimplementing that part. For example: the current loader doesn't properly handle 1- and 4-bit files, incorrectly loads 16-bit files as intensity-alpha (they are RGB555), is full of dead code, and generally not in very good shape.
Attached is my re-implementation for review.
I've checked it against the test images from http://wvnvaxa.wvnet.edu/vmswww/bmp.html and models that use BMP files.
"
Before:
1. if the camera is not a slave camera
1.1 set the eventState's graphics context to the current context.
2. if the current master view is not the view which has the focus
2.1 set the current master view to be the view which has the focus
2.2 use the new master view's eventState instead of the old one
Now as you can see from this sequence, the graphics context is set on the eventState before switching to the view which has focus (and thus using another eventState). So the new eventState, in the case we need to switch views, will contain an old graphics context, not the correct one.
Just inversing these steps fixes the problem:
1. if the current master view is not the view which has the focus
1.1 set the current master view to be the view which has the focus
1.2 use the new master view's eventState instead of the old one
2. if the camera is not a slave camera
2.1 set the eventState's graphics context to the current context.
Now, the eventState will refer to the correct graphics context in both cases.
Attached is a fixed CompositeViewer.cpp (based on today's SVN) which does this. Note that some other things are done in the 1. and 2. cases, but they have no influence on each other so they can just be swapped without problems.
"
I suggest moving the definition of OSG_DEFAULT_LIBRARY_PATH (which is responsible for this global rebuild) into osgDB/CMakeLists.txt which is the only library in the code where this definition is (and is likely ever to be) used. This way if the user changes it, only osgDB will rebuild."
set to off. But could be activated/decativated via CMake as well as system
environment variable. I also modified src\osgViewer\CMakeLists.txt to turn
off this workaround by default as suggested."
parts of their scene graphs. Within these common part some nodes have
event handlers which use the action adapter argument to the event
handler to determinate which view received the event.
Here is the problem, osgViewer::CompositeViewer::eventTraversal sets
the action adapter field in the EventVisitor always to the last view
which received an event, instead of using the view which actually
received the event, so determination of the correct view does not work.
I looked at the code a bit, and moved the code for setting the action
adapter to a IMO better place"
facilitate the subclassing of Image providing interactive behaviours so as
used in the vnc interactive VncImage class.
osgViewer::InteractiveImageHandler provides an event handler that convertes osgGA
mouse and keyboard events into the coordinate frame of an image based on ray intersection with geometry in
the associated subgraph.
Changed the ordering of events processing in Viewer and CompositeViewer to allow
scene graph event handlers to take precidence over viewer event handlers and camera manipulators
---------------------------
function FltExportVisitor::writeExternalReference( const osg::ProxyNode& proxy ):
Line 423 in file expPrimaryRecords.cpp has to be changed from
const ParentPools* pp = static_cast<const ParentPools*>(proxy.getUserData() );
to
const ParentPools* pp = dynamic_cast<const ParentPools*>(proxy.getUserData() );
"
The semantic change that went into the ac loader with the past patch was
incorrect wrt the document describing the behaviour of ac files and
inconsistent with what ac3d itself displays for that files.
This attached change reverts the behaviour to the original one. The
infrastructure to change this is left in place.
The change is based on rev 9045."
"
and a later post the same osg-submissions thread:
"it's been a while since I have made the changes but I think it was due to problems with static builds of OpenThreads on windows. I was using
OpenThreads in a communication/synchronisation library (without
OpenSceneGraph). It seems I forgot to post a small change in the CMakeLists file of OpenThreads. If a user turns DYNAMIC_OPENTHREADS to OFF (static build) OT_LIBRARY_STATIC will be defined in the Config.
Without these changes a windows user will always end up with a "__declspec(dllexport)" or "__declspec(dllimport)" which is a problem for static builds."
And another post from Blasius on this topic:
"I tested with VS2005 and VS2008. For 32 bit everything works as expected. For x64 and VS2008 I could successfully do the cmake-configure and then the compilation but I had occasional crashes of cmTryCompileExec.exe (during the cmake-configure phase) which seems to be a cmake bug. With VS2005 and 64bit cmake does not set _OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED although the interlocked functionality should be there. If I place the source snippet from the CHECK_CXX_SOURCE_RUNS macro to a separate sourcefile I can compile and run the resulting executable successfully. Forcing OPENTHREADS_ATOMIC_USE_WIN32_INTERLOCKED (on VS2005/x64) reveals a bug in "intrin.h" which seems to be fixed in VS2008 but not in VS2005.
In case anyone is interested the lines:
__MACHINEI(unsigned char _interlockedbittestandset(long *a, long b))
__MACHINEI(unsigned char _interlockedbittestandreset(long *a, long b))
__MACHINEX64(unsigned char _interlockedbittestandset64(__int64 *a, __int64 b))
__MACHINEX64(unsigned char _interlockedbittestandreset64(__int64 *a, __int64 b))
should be changed to:
__MACHINEI(unsigned char _interlockedbittestandset(long volatile *a, long b))
__MACHINEI(unsigned char _interlockedbittestandreset(long volatile *a, long b))
__MACHINEX64(unsigned char _interlockedbittestandset64(__int64 volatile *a, __int64 b))
__MACHINEX64(unsigned char _interlockedbittestandreset64(__int64 volatile *a, __int64 b))
The worst thing that can happen is that interlocked funtionality is not detected during cmake-configure and the mutex fallback is used.
Which reminds me another small glitch in the Atomic header so I attached a corrected version.
Why is the OT_LIBRARY_STATIC added to the config file? It is not needed anywhere.
OT_LIBRARY_STATIC is needed if you are doing static-builds on Windows. See my previous post on that.
"
- Matrix transform nodes were stripped out, and the
vertices and normals of each node were
transposed by the modelling matrix. My change preserves
the matrix transform nodes, so that
models can still be articulated by changing the matrices.
- Lights were copied from the COIN scenegraph to the OSG
scenegraph, but they were not associated
with a LightSource node. My change for this creates a
Group and adds a LightSource for each Light.
- If VRML textures have names, the name is now copied to
--
Form Robert Osfild, changed SbString to std::string usage
M Inventor/ConvertFromInventor.h
M Inventor/ConvertFromInventor.cpp
a capping the number of PagedLOD to a sepcified maximum, with pruning of inactive
PagedLOD when the total number of inactive and active PagedLOD goes above the maximum.
To enable the mode set the env var OSG_MAX_PAGEDLOD to a value something like 1000.
support. While testing the pluggin we found a small bug and we are
submitting a patch.
The first attachment is a small program that creates a scene with two
pyramids, transformed by two instances of
osg::PositionAttitudeTransform. One of them is rotated 90 degrees in
the X axis, and the scene is exported both in the native OSG (.osg)
and COLLADA (.dae) formats. In the first case the rotated pyramid is
displayed correctly whereas in the second the pyramid seems not to be
rotated.
In the COLLADA 1.4.1 specification (found at
http://www.khronos.org/collada/) it is specified that
"The <rotate> element contains a list of four floating-point values
[...] followed by an angle in degrees" but the plugin seems to write
the value in radians.
The problem seems to be in the method daeWriter::apply() that seems to
be writing the angle value in radians to the COLLADA file. The patch
can be found in the second attachment and is simply a call to
RadiansToDegrees wrapped around the angle.
"
It assumes that inverse(_inverseMatrix * _offset) = _offset * _matrix
This is only true when _offset=identity, so I think it should be inverse(_offset) * _matrix
This inconsistency can cause problems when switching from UFO to other manipulators, because the UFO:Manipulator::getMatrix function is not necessarily returning a correct inverse of the currently set ModelViewTransform.
It was tempting to change the name of the _offset member to _inverseOffset, or to maintain both variables, but in the end went for the minimal change."
If a 400 level error occurs, a FILE_NOT_FOUND ReadResult is appropriate.
If a 500 level error occurs (such a 503, Service unavailable), the application might want to try to load the file again in a few seconds/minutes. This submission returns ERROR_IN_READING_FILE if a 500 level error occurs so that clients can easily distinguish between the errors.
The actual error code is also added to the "message" of the ReadResult so if a client needs more information, they can just parse the message to retrieve the error code."
The graph is displayed "under" (behind) the normal bar chart you get when you press 's' twice. It doesn't hide the normal stats, you can still read them without any trouble, and that way, it doesn't take any more screen space. It starts from the left, and will scroll left when there is enough data to fill the screen width. The graph lines have the same colors we're used to (except I made the event color a bit bluer, so it's not exactly the same as the update color). A screen shot is attached.
The lines get a bit confused when they're all overlapping at the bottom of the graph, but I think that's the least of our concerns (if they're all at the bottom of the graph - except FPS of course - then great!).
The only thing I'm not very keen about is that to make things simple, I clamp the values to a given maximum. Right now, the maximums I have set are:
* Frame rate: 100 fps (people have 60, 75, 85Hz refresh rates, so there's no one right value, but I think 100 is OK)
* Stats: 0.016 seconds (what you need to get 60Hz minimum)
This could be changed so that the scale of the graph changes according to the maximum value in the last screenful of the graph instead of clamping values. We would then need to display the scale for each value on the side of the graph, because if the scale changes, you need to know what it is at this moment.
I tried to make things easy to change, so for example if you don't like that the graph is in the same space as the normal stats bars, it's easy to move it anywhere else, and make it have other dimensions. The maximums and colors are also easy to change.
The impact on performance should be minimal, since it's one vertex per graph line that's added per frame, and vertices are removed when they scroll off the screen, so you'll never have more than say 1280 * (3 + ncameras) vertices on the screen at one time. No polygons, I used line strips. The scrolling is done with a MatrixTransform."
Quicktime supports only files with 3/4-channels rgba-files and not 1/2-channels rgb-files.
This submission is from Tatsuhiro Nishioka, here's his original quote:
When FlightGear crashes, the error message
"GraphicsImportGetNaturalBounds failed" shows up. By adding printf
debug, I found the error was -8969: codecBadDataErr when loading a
gray-scaled (2 channels) rgba files even though the file can be loaded
with Gimp and osgViewer properly.
So I made an investigation on this problem and found an interesting
thing. This error occurs only when non-rgb files are loaded before rgb
files. The reason is that rgba files can be handled by both
osgdb_rgb.so and osgdb_qt.so, but the error happens only when
osgdb_qt.so try to load a gray-scaled rgba file.
When a program is about to load an rgba file, osgdb_rgb.so is loaded
and it handles the rgba file properly. In contrast, when a gray-scaled
rgb file is being loaded after a non-rgb file (say png) is already
loaded by osgdb_qt.so, osgdb_qt.so tries to load the file instead of
osgdb_rgb, which causes the error above.
Anyway, the bad thing is that QuickTime cannot handle gray-scaled rgb
files properly. The solution for this is not to let osgdb_qt handle
rgb files since osgdb_rgb can handle these properly.
"
This code will add two extra statistics options:
-Camera scene statistics, stats for the scene after culling (updated at 10 Hz)
-View scene statistics, stats for the complete scene (updated at 5 Hz)
Each camera and each view will expand the statistics to the right.
I also added the requests and objects to compile of the databasepager to the databasepager statistics.""
Attached is a change that is able to provide shared textures for the clamp and
the repeat case.
So this appears to be the best fix I guess ...
Also it additionaly shares the TexEnv StateAttribute in a whole ac3d model."
..\..\..\..\src\osgDB\Registry.cpp(910) : warning C4806: '==' : unsafe operation: no value of type 'bool' promoted to type 'osgDB::Registry::LoadStatus' can equal the given constant
A quick review of the code revealed a piece of code that was clearly wrong, possibly due to a copy-and-paste error.
"
The fix was to check whether glGetString( GL_VERSION ) returned a null pointer (Ref. svn diff below). The altered src/osg/GLExtensions.cpp is zipped and attached to this email."
"Soft shadow mapping is basically the same as hard shadow mapping beside that
it uses a different fragment shader.
So for me it makes sense that osgShadow::SoftShadowMap is derived from
osgShadow::ShadowMap, this makes it easier to maintain the two classes.
Additional SoftShadowMap also provides the same Debug methods as ShadowMap."
I think I may have discovered a bug in osgShadow/ShadowMap.cpp that results in incomplete shadows being generated.
The problem seems to caused by an incorrect interpretation of the spot light cutoff angle. The valid ranges for spot cutoff are 0-90 and 180, i.e half the 'field of view' for the spotlight. Whereas the shadow map code seems to assume the the spot cutoff is equal to the field of view. This results in the shadows generated by the spotlight getting clipped at half the spot cutoff angle.
I have fixed this in my copy of ShadowMap.cpp:
===============================
//Original code from OSG 2.6:
if(selectLight->getSpotCutoff() < 180.0f) // spotlight, then we don't need the bounding box
{
osg::Vec3 position(lightpos.x(), lightpos.y(), lightpos.z());
float spotAngle = selectLight->getSpotCutoff();
_camera->setProjectionMatrixAsPerspective(spotAngle, 1.0, 0.1, 1000.0);
_camera->setViewMatrixAsLookAt(position,position+lightDir,osg::Vec3(0.0f,1.0f,0.0f));
}
===============================
// My modifications:
float fov = selectLight->getSpotCutoff() * 2;
if(fov < 180.0f) // spotlight, then we don't need the bounding box
{
osg::Vec3 position(lightpos.x(), lightpos.y(), lightpos.z());
_camera->setProjectionMatrixAsPerspective(fov, 1.0, 0.1, 1000.0);
_camera->setViewMatrixAsLookAt(position,position+lightDir,osg::Vec3(0.0f,1.0f,0.0f));
}
This change seems correct for spot cutoff in the range 0, 90, but since OpenGL doesn't claim to support cutoffs >90 && <180, I'm not sure how shadow map should deal with those cases, but ignoring spot cut off greater than 90 here seems reasonable to me.
"
> Using QOSGWidget - QWidget + osgViewer creating the graphics context.
>
> Windows Error #2000: [Screen #0] GraphicsWindowWin32::setWindow() - Unable
> to create OpenGL rendering context. Reason: The pixel format is invalid.
>
>
>
> And then the following fate error pops up:
>
>
>
> The instruction at "0x014c7ef1" referenced memory at "0x000000a4", The
> memory could not be "read".
>
> Click on Ok to terminate the program
>
> Click on CANCEL to debug the program
>
>
- adds display of options when using osgconv --formats.
- adds useGroupPerFeature option to have each feature in a separate group. Usage: OSG_OPTIMIZER=OFF osgconv -e ogr -O addGroupPerFeature <infile> <outfile>
"
osg::ColorMask* leftColorMask = _renderStageLeft->getColorMask();
if (!leftColorMask)
{
leftColorMask = new osg::ColorMask();
_renderStageLeft->setColorMask(leftColorMask);
^^^^ here it said right, I think this should be Left.
}
// ensure that right eye color planes are active.
osg::ColorMask* rightColorMask = _renderStageRight->getColorMask();
^^^^ similar here, I think this should be right
if (!rightColorMask)
{
rightColorMask = new osg::ColorMask();
_renderStageRight->setColorMask(rightColorMask);
}
and i further removed an unnecessary setColorMask."
mode. Nevertheless, the code doesn't acknowledge that, so I had problems with
debug versions of the library not being able to open their plugins whereas
the release versions worked fine.
I have made the same changes in Registry.cpp that are available for the rest
of platforms appending that "d" to their plugins. I have also updated the
CMakeLists.txt file to get "_DEBUG" defined at compilation time. I have
copied the already existent conditional block because of cmake's bizarre
operator precedence. Since Cygwin defines both CYGWIN and WIN32, the
following would suffice:
IF(CYGWIN OR UNIX AND NOT WIN32 AND NOT APPLE)
Sadly, it actually doesn't work, so I wrote a new conditional block just for
Cygwin. I could join the two blocks when the parentheses support is added in
newer versions of cmake."
polygon offset complicate. so i looked for a solution to remove this offset.
i changed the shader, also the filtering (default: on) use now a correct 3x3 filter:
1 0 1
0 2 0
1 0 1
div: 6
of course a better one would be
1 2 1
2 4 2
1 2 1
div: 16
but this isn't as performant as the simple filter above is. because we need only 5 texture lookups instead of 9, and the result is still good, if you wish we can add a enum to change the pcf filter type once, if there is a need.
testet on NVidia Quatro 570M and on ATI Radeon X1600
"
unfort. i couldn't test it on any ATI system. may there will be still another problem there. if there are still some artefacts. we should try out better fZOffSet value
"
if(
(!win || win->getVisibilityMode() == Window::VM_PARTIAL) &&
!win->isPointerXYWithinVisible(x, y)
) continue;
But it probably should be
if (!win || (win->getVisibilityMode() == Window::VM_PARTIAL) && !win->isPointerXYWithinVisible(x, y)))
continue;
The effect of the bug is to segfault if a non-osgWidgets::Window node hasn't been excluded from picking via NodeMask."
set.
The optimization is based on the observation that matrix matrix multiplication
with a dense matrix 4x4 is 4^3 Operations whereas multiplication with a
transform, or scale matrix is only 4^2 operations. Which is a gain of a
*FACTOR*4* for these special cases.
The change implements these special cases, provides a unit test for these
implementation and converts uses of the expensiver dense matrix matrix
routine with the specialized versions.
Depending on the transform nodes in the scenegraph this change gives a
noticable improovement.
For example the osgforest code using the MatrixTransform is about 20% slower
than the same codepath using the PositionAttitudeTransform instead of the
MatrixTransform with this patch applied.
If I remember right, the sse type optimizations did *not* provide a factor 4
improovement. Also these changes are totally independent of any cpu or
instruction set architecture. So I would prefer to have this current kind of
change instead of some hand coded and cpu dependent assembly stuff. If we
need that hand tuned stuff, these can go on top of this changes which must
provide than hand optimized additional variants for the specialized versions
to give a even better result in the end.
An other change included here is a change to rotation matrix from quaterion
code. There is a sqrt call which couold be optimized away. Since we divide in
effect by sqrt(length)*sqrt(length) which is just length ...
"
they are written to disk, either inline or as an external file. Added support for
this in the .ive plugin. Default of WriteHint is NO_PREFERNCE, in which case it's
up to the reader/writer to decide.
The vertical separation not actually displayed as it is set. So some
display the up and down stereo images style will not be correct.
Someone may forget to change the "Horizontal" to "Vertical" after
copying and pasting the code from above HORIZONTAL_SPLIT code segment.
I've attached the file. By replacing the incorrect "Horizontal" to
"Vertical", the bug is gone.
"
occlusion query result is not ready for retrieval when the app tries to
retrieve it. This fix adds an application-level wait loop to ensure the
result is ready for retrieval. This code is not compiled by default; add "-D
FORCE_QUERY_RESULT_AVAILABLE_BEFORE_RETRIEVAL" to get this code.
Full, gory details, to the best of my recollection:
The conditions under which we encountered this issue are as follows: 64-bit
processor, Mac/Linux OS, multiple NVIDIA GPUs, multiple concurrent draw
threads, VRJuggler/SceneView-based viewer, and a scene graph containing
OcclusionQueryNodes. Todd wrote a small test program that produces an almost
instant crash in this environment. We verified the crash does not occur in a
similar environment with a 32-bit processor, but we have not yet tested on
Windows and have not yet tested with osgViewer.
The OpenGL spec states clearly that, if an occlusion query result is not yet
ready, an app can go ahead and attempt to retrieve it, and OpenGL will
simply block until the result is ready. Indeed, this is how
OcclusionQueryNode is written, and this has worked fine on several platforms
and configurations until Todd's test program.
By trial and error and dumb luck, we were able to workaround the crash by
inserting a wait loop that forces the app to only retrieve the query after
OpenGL says it is available. As this should not be required (OpenGL should
do this implicitly, and more efficiently), the wait loop code is not
compiled by default. Developers requiring this work around must explicitly
add "-D FORCE_QUERY_RESULT_AVAILABLE_BEFORE_RETRIEVAL" to the compile
options to include the wait loop."
