FGFS-4.1/OpenSceneGraph
4
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
10,655 Commits 1 Branch 26 Tags 73 MiB
C++ 89.7%
C 5.1%
CMake 2.3%
HTML 1.6%
Objective-C++ 0.9%
Other 0.2%
b4789863ac
Go to file
Robert Osfield b4789863ac Form Wang Rui, "An initial GLSL shader support of rendering particles. Only the POINT 
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.
"
2010-09-14 15:47:29 +00:00
applications Updated AUTHORS 2010-06-18 15:46:10 +00:00
CMakeModules From Torben Dannhauer, "I extended the attached CMAKE module to search for the collada libraries of my VS2008 3rdParty package if no other library is found. 2010-09-09 10:44:11 +00:00
doc/Doxyfiles Removed osgIntrospection and added osgQt to doxygen files 2010-06-23 14:18:42 +00:00
examples Form Wang Rui, "An initial GLSL shader support of rendering particles. Only the POINT 2010-09-14 15:47:29 +00:00
include Form Wang Rui, "An initial GLSL shader support of rendering particles. Only the POINT 2010-09-14 15:47:29 +00:00
packaging Removed osgIntrospection as it's now available as a seperate osgIntrospection project that can be checked out thus: 2010-06-23 13:28:19 +00:00
PlatformSpecifics/Windows
src Form Wang Rui, "An initial GLSL shader support of rendering particles. Only the POINT 2010-09-14 15:47:29 +00:00
AUTHORS.txt Updated ChangeLog and AUTHORS file for 2.9.8 release 2010-06-18 16:07:55 +00:00
ChangeLog Updated ChangeLog and AUTHORS file for 2.9.8 release 2010-06-18 16:07:55 +00:00
CMakeLists.txt Removed osgIntrospection as it's now available as a seperate osgIntrospection project that can be checked out thus: 2010-06-23 13:28:19 +00:00
configure
CTestConfig.cmake From Jean-Sebastien Guay, updated CTestConfig to point to new cdash.openscenegraph.org site 2009-07-24 12:12:07 +00:00
LICENSE.txt
NEWS.txt
README.txt Updated ChangeLog and README.txt for 2.9.6 dev release 2009-12-10 12:58:05 +00:00
runexamples.bat From Ulrich Hertlein, "attached is a stencil buffer-based constant-width outline f/x with example. I've also modified osgfxbrowser to setup the stencil buffer accordingly." 2009-12-08 17:41:44 +00:00

README.txt 

Welcome to the OpenSceneGraph (OSG).

For up-to-date information on the project, in-depth details on how to 
compile and run libraries and examples, see the documentation on the 
OpenSceneGraph website:

    http://www.openscenegraph.org
  
For the impatient, read the simplified build notes below. For support 
subscribe to our public mailing list:

    http://www.openscenegraph.org/projects/osg/wiki/MailingLists



Robert Osfield.
Project Lead.
10th December 2009.

--

How to build the OpenSceneGraph
===============================

The OpenSceneGraph uses the CMake build system to generate a 
platform-specific build environment.  CMake reads the CMakeLists.txt 
files that you'll find throughout the OpenSceneGraph directories, 
checks for installed dependenciesand then generates the appropriate 
build system.

If you don't already have CMake installed on your system you can grab 
it from http://www.cmake.org, use version 2.4.6 or later.  Details on the 
OpenSceneGraph's CMake build can be found at:

    http://www.openscenegraph.org/projects/osg/wiki/Build/CMake

Under unices (i.e. Linux, IRIX, Solaris, Free-BSD, HP-Ux, AIX, OSX) 
use the cmake or ccmake command-line utils, or use the included tiny 
configure script that'll run cmake for you.  The configure script 
simply runs 'cmake . -DCMAKE_BUILD_TYPE=Release' to ensure that you 
get the best performance from your final libraries/applications.
 
    cd OpenSceneGraph
    ./configure
    make
    sudo make install
  
Alternatively, you can create an out-of-source build directory and run 
cmake or ccmake from there. The advantage to this approach is that the 
temporary files created by CMake won't clutter the OpenSceneGraph 
source directory, and also makes it possible to have multiple 
independent build targets by creating multiple build directories. In a 
directory alongside the OpenSceneGraph use:

    mkdir build
    cd build
    cmake ../OpenSceneGraph -DCMAKE_BUILD_TYPE=Release
    make
    sudo make install

Under Windows use the GUI tool CMakeSetup to build your VisualStudio 
files. The following page on our wiki dedicated to the CMake build 
system should help guide you through the process:

    http://www.openscenegraph.org/projects/osg/wiki/Support/PlatformSpecifics/VisualStudio

Under OSX you can either use the CMake build system above, or use the 
Xcode projects that you will find in the OpenSceneGraph/Xcode 
directory. See release notes on OSX CMake build below.

For further details on compilation, installation and platform-specific 
information read "Getting Started" guide:

    http://www.openscenegraph.org/projects/osg/wiki/Support/GettingStarted
   
   
-- Release notes on OSX build, by Eric Sokolowsky, August 5, 2008

There are several ways to compile OpenSceneGraph under OSX.  The
recommended way is to use CMake 2.6 to generate Xcode projects, then use
Xcode to build the library. The default project will be able to build
Debug or Release libraries, examples, and sample applications. Here are
some key settings to consider when using CMake:

BUILD_OSG_EXAMPLES - By default this is turned off. Turn this setting on
to compile many great example programs.

CMAKE_OSX_ARCHITECTURES - Xcode can create applications, executables,
libraries, and frameworks that can be run on more than one architecture.
Use this setting to indicate the architectures on which to build OSG.
Possibilities include ppc, ppc64, i386, and x86_64. Building OSG using
either of the 64-bit options (ppc64 and x86_64) has its own caveats
below.

OSG_BUILD_APPLICATION_BUNDLES - Normally only executable binaries are
created for the examples and sample applications. Turn this option on if
you want to create real OSX .app bundles. There are caveats to creating
.app bundles, see below.

OSG_WINDOWING_SYSTEM - You have the choice to use Carbon or X11 when
building applications on OSX. Under Leopard and later, X11 applications,
when started, will automatically launch X11 when needed. However,
full-screen X11 applications will still show the menu bar at the top of
the screen. Since many parts of the Carbon user interface are not
64-bit, X11 is the only supported option for OSX applications compiled
for ppc64 or x86_64.

There is an Xcode directory in the base of the OSG software
distribution, but its future is limited, and will be discontinued once
the CMake project generator completely implements its functionality.


APPLICATION BUNDLES (.app bundles)

The example programs when built as application bundles only contain the
executable file. They do not contain the dependent libraries as would a
normal bundle, so they are not generally portable to other machines.
They also do not know where to find plugins. An environmental variable
OSG_LIBRARY_PATH may be set to point to the location where the plugin
.so files are located. OSG_FILE_PATH may be set to point to the location
where data files are located. Setting OSG_FILE_PATH to the
OpenSceneGraph-Data directory is very useful when testing OSG by running
the example programs.

Many of the example programs use command-line arguments. When
double-clicking on an application (or using the equivalent "open"
command on the command line) only those examples and applications that
do not require command-line arguments will successfully run. The
executable file within the .app bundle can be run from the command-line
if command-line arguments are needed.


64-BIT APPLICATION SUPPORT

OpenSceneGraph will not compile successfully when OSG_WINDOWING_SYSTEM is
Carbon and either x86_64 or ppc64 is selected under CMAKE_OSX_ARCHITECTURES,
as Carbon is a 32bit only API. A version of the osgviewer library written in
Cocoa is needed. However, OSG may be compiled under 64-bits if the X11
windowing system is selected. However, Two parts of the OSG default
distribution will not work with 64-bit X11: the osgviewerWX example
program and the osgdb_qt (Quicktime) plugin. These must be removed from
the Xcode project after Cmake generates it in order to compile with
64-bit architectures. The lack of the latter means that images such as
jpeg, tiff, png, and gif will not work, nor will animations dependent on
Quicktime. A new ImageIO-based plugin is being developed to handle the
still images, and a QTKit plugin will need to be developed to handle
animations.