" The code below is to show how a heirarchy of objects can be made within a scenegraph.
In other words, how there can be a parent/child relationship between objects such
that when a parent is rotated or translated, the children move is respect to it's
parent movement. A robotic arm is used in this example because this is what I'm
using OSG for."
I have found some errors on the example osgGeometryShaders. It's about the varying in the geometry shader.
take a look at the varying vec4 v_color.
In the vertex shader, v_color is initialized to gl_vertex
then in the geometry shader v_color is initialized to gl_PositionIn[0]
and in the fragment shader v_color is used as the fragment color.
Try to initialized v_color to vec4(1.0, 0.0, 0.0, 1.0) in the vertex shader and comment the line :
" v_color = v;\n" in the geometry shader, and you will see the lines as black !
It's because you have to use keywords in and out.
extract from : http://www.opengl.org/registry/specs/EXT/geometry_shader4.txt :
in - for function parameters passed into a function or for input varying
variables (geometry only)
out - for function parameters passed back out of a function, but not
initialized for use when passed in. Also for output varying variables
(geometry only).
Then for a geometry shader, a varying must be an array :
extract from : http://www.opengl.org/registry/specs/EXT/geometry_shader4.txt :
Since a geometry shader operates on primitives, each input varying variable needs to be
declared as an array. Each element of such an array corresponds to a
vertex of the primitive being processed. If the varying variable is
declared as a scalar or matrix in the vertex shader, it will be a
one-dimensional array in the geometry shader. Each array can optionally
have a size declared. If a size is not specified, it inferred by the
linker and depends on the value of the input primitive type.
Here is a patch based on the svn version of osg that correct that.
"
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 ...
"
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
- 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)"
* 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"
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"
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..."
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.
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."
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."
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."
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).
"
- 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.
(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"
- 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)
"
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... :-)
