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."
