which could fix the dragger size in screen, so that no matter how we
zoom in/out the camera, the dragger will never be scaled.
This is what 3D graphics software like 3dsmax and maya behave, which
helps users select and manipulate draggers more easily.
You may turn on the feature with the new --fixedDraggerSize argument:
# osgmanipulator.exe --fixedDraggerSize --dragger TranslateAxisDragger
cessna.osg
"
The DatabasePager now passes the Terrain pointer into the ReaderWriter's via osgDB::Options object,
rather than pushing a NodePath containing the Terrain onto NodeVisitor. This
change means that the DatabasePager nolonger needs to observer the whole NodePath and
will be lighter and quicker for it.
The change also means that ReadFileCallback can now run custom NodeVisitor's on the scene graph without
having to worry about TerrainTile's constructing scene graphs prior to the Terrain being assigned.
Also changed is the NodeVisitor::DatabaseRequestHandler which now requires a NodePath to the node that you wish
to add to rather than just the pointer to the node you wish to add to. This is more robust when handling scenes
with multiple parental paths, whereas previously errors could have occurred due to the default of picking the first
available parental path. This change means that subclasses of DatabasePager will need to be updated to use this new
function entry point.
in this file,
function,
osg::Geometry* getShape(const std::string& name)
(line 51)
tries to use null pointer when model is not provided.
I added simple comment in attached file."
used to avoid dual update traversals of the scene, which is not
allowed in my application (but I forgot the reason ;-) Now the blank
problem will disappear.
Inactive mode is also available, using the --inactive mode and
--camera-eye and --camera-hpr to set camera position:
./osgposter --output-poster --poster output.bmp --tilesize 800 600
--finalsize 8000 6000 cow.osg --inactive --camera-eye 0 0 20
"
I uses a queue of Camera objects to do offscreen rendering with the Camera::attach() function. The entire picture is split into many tiles and it will take a few seconds while attaching and detaching cameras with tiles. You may select to output every tile as an image file, or combine them together to create a large poster, for example, a 12800 x 9600 image.
Start the program like this:
./osgposter --output-poster --poster output.bmp --tilesize 800 600 --finalsize 8000 6000 cow.osg
Adjust the scene camera to a suitable position and press 'p' or 'P' on the keyboard. Wait until sub-cameras dispatching is finished. And the poster file will be created while closing window. A 8000 x 6000 output.bmp will be created to show a fine-printed cow. :)
The command below may also help:
./osgposter --help
"
changes from the DirectInput devices and add events to the event
queue. I've tested with the keyboard and joystick supports. Because of
only having a very old 6-button gamepad, I can't do more experiments.
Hope this will bring more ideas to those who face similar problems,
especially simulation game designers. :)
I didn't map all DirectInput key values to GUIEventAdapter key
symbols. Users may add more in the buildKeyMap() function freely. The
mouse handling operations are also ignored, but will be easily
improved in the same way of creating keyboard and joystick devices.
Please add a line:
FIND_PACKAGE(DirectInput)
in the CMakeLists of root directory. And in the examples/CMakeLists.txt:
IF(DIRECTINPUT_FOUND)
ADD_SUBDIRECTORY(osgdirectinput)
ENDIF(DIRECTINPUT_FOUND)
DirectX SDK 2009 is used here, but an older version like DX8 should
also work in my opinion.
"
- CMakeLists.txt
-- don't look for GL when compiling for iOS (device or simulator), look for OGLES instead
-- use architecture i386 for simulator
-- removed iphoneos-version-min for simulator
- examples/osgviewerIPhone/CMakeLists.txt
-- added build dependencies for osgdb_osg, osgdb_freetype, osgdb_imageio
-- added framework QuartzCore link dependency
- src/osgDB/CMakeLists.txt
-- don't link against Carbon on iOS (device or simulator)
- src/osgPlugins/freetype/CMakeLists.txt
-- don't link against OpenGL on iOS device or simulator
- src/osgViewer/CMakeLists.txt
-- link against OpenGLES on iOS (device or simulator)
- src/osgPlugins/imageio/CMakeLists.txt
-- compile ReaderWriterImageIO_IOS.cpp as Objective-C++
"
hpux. I have skipped irix this time as irix is too dead to keep osg building
there.
As usual, solaris does not like member templates in stl containers.
Some headers missing and link problems due to missing libraries."
A few things remain to do:
* The binding between a uniform block in a shader program and a buffer indexed target number is fixed, like a vertex attribute binding. This is too restrictive because that binding can be changed without relinking the program. This mapping should be done by name in the same way that uniform values are handled i.e., like a pseudo state attribute;
* There's no direct way yet to query for the offset of uniforms in uniform block, so only the std140 layout is really usable. A helper class that implemented the std140 rules would be quite helpful for setting up uniform blocks without having to link a program first;
* There's no direct support for querying parameters such as the maximum block length, minimum offset alignment, etc. Having that information available outside of the draw thread would make certain instancing techniques easier to implement."
attached you'll find the second part of the IOS-submission. It contains
* GraphicsWindowIOS, which supports external and "retina" displays,
multisample-buffers (for IOS > 4.0) and multi-touch-events
* an ios-specific implementation of the imageio-plugin
* an iphone-viewer example
* cMake support for creating a xcode-project
* an updated ReadMe-file describing the necessary steps to get a
working xcode-project-file from CMake
Please credit Thomas Hogarth and Stephan Huber for these changes.
This brings the ios-support in line with the git-fork on github. It
needs some more testing and some more love, the cmake-process is still a
little complicated.
You'll need a special version of the freetype lib compiled for IOS,
there's one bundled in the OpenFrameworks-distribution, which can be used."
Notes, from Robert Osfield, modified CMakeLists.txt files so that the IOS specific paths are within IF(APPLE) blocks.
serialization libraries. My submission mainly includes:
1. Add two new macros USE_DOTOSGWRAPPER_LIBRARY and
USE_SERIALIZER_WRAPPER_LIBRARY. Applications using static OSG must
include corresponding static-link libraries and use these two macros
to predefine native format wrappers. Please see osgstaticviewer and
present3D in the attachment for details.
2. Add a LibraryWrapper.cpp file in each
osgWrappers/deprecated-dotosg/... and osgWrappers/serializers/...
subfolder, which calls all USE_...WRAPPERS macros inside. The
LibraryWrapper file is automatically generated by the
wrapper_includer.cpp (with some slight fixes), which is also attached
for your reference. The deprecated-dotosg/osgAnimation is not included
because it doesn't us REGISTER_DOTOSGWRAPPER to define its wrappers.
3. Modify the ReaderWriterOSG.cpp to prevent calling loadWrappers()
when static build.
4. An uncorrelated fix to Serializer and ObjectWrapper.cpp, which
ensures version variables of serialziers are initialized, and
serializers out-of-version are not written to model files.
"
Also I've done the osguserstats example. I've kept the "toy example" that was in the modified osgviewer.cpp I had sent you, because they show different uses of custom stats lines (a value displayed directly, a value without bars and a value with bars and graph). I also added a function and a thread that will sleep for a given number of milliseconds and record this time in the stats. I think it clearly shows how to record the time some processing takes and add that to the stats graph, whether the processing takes place on the same thread as the viewer or on another thread.
BTW, feel free to modify the colors I've given to each user stats line... I'm not very artistic. :-)
I've also added more doc comments to the addUserStats() method in ViewerEventHandlers, so hopefully the arguments are clear and the way to get the results you want is also clear. Maybe I went overboard, but the function makes some assumptions that may not be obvious and has many arguments, so I preferred to be explicit."
In osg::isGLExtensionOrVersionSupported in src/osg/GLExtensions.cpp when
using indirect X11 rendering,
glGetIntegerv( GL_NUM_EXTENSIONS, &numExt );
is leaving numExt uninitilized causing the following glGetStringi to
return NULL when the extension number isn't present. Passing NULL to
std::string() then crashes. This is with the following nVidia driver.
OpenGL version string: 3.3.0 NVIDIA 256.35
I went ahead and initialized some of the other variables before
glGetInitegerv in other files as well. I don't know for sure
which ones can fail, so I don't know which are strictly required.
"
changed extensions from .c to .cpp and got compiling as C files as part of the osg core library.
Updated and cleaned up the rest of the OSG to use the new internal GLU.
type is supported at present. The attached osgparticleshader.cpp will
show how it works. It can also be placed in the examples folder. But I
just wonder how this example co-exists with another two (osgparticle
and osgparticleeffect)?
Member variables in Particle, including _alive, _current_size and
_current_alpha, are now merged into one Vec3 variable. Then we can
make use of the set...Pointer() methods to treat them as vertex
attribtues in GLSL. User interfaces are not changed.
Additional methods of ParticleSystem are introduced, including
setDefaultAttributesUsingShaders(), setSortMode() and
setVisibilityDistance(). You can see how they work in
osgparticleshader.cpp.
Additional user-defined particle type is introduced. Set the particle
type to USER and attach a drawable to the template. Be careful because
of possible huge memory consumption. It is highly suggested to use
display lists here.
The ParticleSystemUpdater can accepts ParticleSystem objects as child
drawables now. I myself think it is a little simpler in structure,
than creating a new geode for each particle system. Of course, the
latter is still compatible, and can be used to transform entire
particles in the world.
New particle operators: bounce, sink, damping, orbit and explosion.
The bounce and sink opeartors both use a concept of domains, and can
simulate a very basic collision of particles and objects.
New composite placer. It contains a set of placers and emit particles
from them randomly. The added virtual method size() of each placer
will help determine the probability of generating.
New virtual method operateParticles() for the Operator class. It
actually calls operate() for each particle, but can be overrode to use
speedup techniques like SSE, or even shaders in the future.
Partly fix a floating error of 'delta time' in emitter, program and
updaters. Previously they keep the _t0 variable seperately and compute
different copies of dt by themseleves, which makes some operators,
especially the BounceOperator, work incorrectly (because the dt in
operators and updaters are slightly different). Now a getDeltaTime()
method is maintained in ParticleSystem, and will return the unique dt
value (passing by reference) for use. This makes thing better, but
still very few unexpected behavours at present...
All dotosg and serialzier wrappers for functionalities above are provided.
...
According to some simple tests, the new shader support is slightly
efficient than ordinary glBegin()/end(). That means, I haven't got a
big improvement at present. I think the bottlenack here seems to be
the cull traversal time. Because operators go through the particle
list again and again (for example, the fountain in the shader example
requires 4 operators working all the time).
A really ideal solution here is to implement the particle operators in
shaders, too, and copy the results back to particle attributes. The
concept of GPGPU is good for implementing this. But in my opinion, the
Camera class seems to be too heavy for realizing such functionality in
a particle system. Myabe a light-weight ComputeDrawable class is
enough for receiving data as textures and outputting the results to
the FBO render buffer. What do you think then?
The floating error of emitters
(http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/2009-May/028435.html)
is not solved this time. But what I think is worth testing is that we
could directly compute the node path from the emitter to the particle
system rather than multiplying the worldToLocal and LocalToWorld
matrices. I'll try this idea later.
"
short oit. This rendering technique is also known as depth peeling.
Attached is the example that makes depth peeling work with the fixed function
pipeline. Ok, this is 'old fashioned' but required for our use case that
still has to work on older UNIX OpenGL implementations as well as together
with a whole existing application making use of the fixed function pipeline.
I can imagine to add support for shaders when we have that shader composition
framework where we can add a second depth test in a generic way.
This does *not* implement the dual depth peeling described in a paper from the
ETH Zurich.
This example could serve as a test case for the feature that you can on the
fly remove pre render cameras that you made work a few time ago.
It is also a test case for the new TraversalOrderBin that is used to composite
the depth layers in the correct blend order.
This example also stresses your new texture object cache since you can change
some parameters for the oit implementation at runtime.
You can just load any model with osgoit and see how it works.
Use the usual help key to see what you can change.
There is already an osgdepthpeeling example that I could not really make sense
of up to now. So I just made something new without touching what I do not
understand."
creation of main shader to ShaderComposer and
collection of ShaderComponent to osg::State.
Also added very basic shader set up in osgshadecomposition example.
