I also fixed a possible bug in osgDB::XmlParser that doesn't handle control characters (like " to ") when reading node attributes, because the writeWrappedString() and readWrappedString() now depend heavily on control characters. An additional improvement is that osgx now supports comments."
/Users/uli/Projects/osg/OpenSceneGraph/src/osgPlugins/3ds/WriterNodeVisitor.cpp: In
function ?std::string getFileName(const std::string&)?:
/Users/uli/Projects/osg/OpenSceneGraph/src/osgPlugins/3ds/WriterNodeVisitor.cpp:88:
warning: comparison is always false due to limited range of data type
/Users/uli/Projects/osg/OpenSceneGraph/src/osgPlugins/3ds/WriterNodeVisitor.cpp: In
function ?bool is83(const std::string&)?:
/Users/uli/Projects/osg/OpenSceneGraph/src/osgPlugins/3ds/WriterNodeVisitor.cpp:102:
warning: comparison is always false due to limited range of data type
/Users/uli/Projects/osg/OpenSceneGraph/src/osgPlugins/3ds/WriterNodeVisitor.cpp: In
function ?bool is3DSpath(const std::string&, bool)?:
/Users/uli/Projects/osg/OpenSceneGraph/src/osgPlugins/3ds/WriterNodeVisitor.cpp:118:
warning: comparison is always false due to limited range of data type
/Users/uli/Projects/osg/OpenSceneGraph/src/osgPlugins/3ds/WriterNodeVisitor.cpp:121:
warning: comparison is always true due to limited range of data type
The code was using 'unsigned int' in places where it should've used 'size_t' for correct
comparison with 'std::string::npos' (which is size_t).
"
osg/Camera. The ::glName issue masked the fact that the "(..)" isn't handled
well in doxygen and leads to "(." in the generated files.
I'm also submitting a minor documentation fix to osgGA/DriveManipulator to get
it out of my patch queue ;)"
performance option, I added a flag to control whether the depth writing
pass is performed.
Since text is alpha-blended when rendering, it is placed in the
transparent bin and rendered back to front. Writing to the depth buffer
should therefore be unnecessary. Indeed, rendering something behind text
(or any blended object) after that object is drawn will give incorrect
results whether the depth buffer is written or not. I therefore think it
is safe to keep this option off by default. Users can turn it on for any
special needs they have.
I did not fix the existing backdrop implementations to work with the new
code since this new method of rendering intrinsically handles backdrops
correctly. Its results are more accurate than all of the existing
backdrop implementations. Its only downside is that it requires two
passes if depth buffer updates are desired, whereas DEPTH_RANGE and
POLYGON_OFFSET achieve their (less accurate) results in one pass. The
NO_DEPTH_BUFFER method also only uses one pass, but it disables depth
tests and not depth writes so will have serious problems if anything is
drawn in front of the text before OR after the text is drawn.
Given the better all-around behavior of the new method, I believe the
other backdrop implementations can be safely removed. Code that adjusts
the backdrop implementation will of course be broken if the member
functions are removed. For this reason I left them in, but set the new
rendering method as the default backdrop implementation. At the very
least I think the old backdrop implementations should be deprecated and
removed at a later date.
"
Note from Robert Osfield, testing this submission with osgtext I found that the
text would not render correctly when different text labels were overlapping
in deth and screen space. I change _enableDepthWrites to default to true and
found the that which artifacts still occurred around the alpha blended edges
the artifacts where better than issue with occlusion of nearer pixels that was
happening with _enableDepthWrites set to false.I therefore set the
_enableDepthWrites to true as I feel it's the lesser of the two artefacts.
The following code snippet will reproduce this issue:
Code:
osg::Vec2 vec(0.f, 0.f);
osg::Array* sharedArray = new osg::Vec2Array(1, & vec);
// create 2 geometries sharing same array
osg::Geometry* geom0 = new osg::Geometry;
osg::Geometry* geom1 = new osg::Geometry;
geom0->setVertexArray(sharedArray);
geom1->setVertexArray(sharedArray);
osg::ref_ptr<osg::Geode> geode = new osg::Geode;
geode->addDrawable(geom0);
geode->addDrawable(geom1);
std::stringstream buffer;
// write node
osg::ref_ptr<osgDB::Options> options = new osgDB::Options("Ascii");
osgDB::ReaderWriter* rw = osgDB::Registry::instance()->getReaderWriterForExtension("osgt");
osgDB::ReaderWriter::WriteResult wr = rw->writeNode(*geode, buffer, options.get());
// print result; array will be written twice with full content, though with same ID
std::cout << buffer.str() << std::endl;
// trying to read back node will print warnings about unmatched properties
osgDB::ReaderWriter::ReadResult rr = rw->readNode(buffer, options.get());
To fix this i made a change in OutputStream::writeArray().
I think the same issue applies to OutputStream::writeObject(). So i made the same change there.
"
I move declaration of classes TestResult, QueryGeometry from cpp to header file and made a void createSupportNodes() a virtual method.
Now is possible to inherit from class OcclusionQueryNode."
1. When an outline object was occluded by another object, the backfacing wireframe was exposed. To fix that, I removed the disabling of GL_DEPTH_TEST.
2. In some cases, the outline color was the same color as the geometry being drawn instead of the specified color. I'm not sure I have completely fixed this issue, but I did make some changes to match up to how we do a scribe effect."
Goals:
- to handle INCR_WRAP values nicely if not supported by OpenGL (old hardware)
- to support two side stenciling of OpenGL 2.0. Current implementation does not work on ATI as it uses Nvidia extension.
Ready for commit:
- Stencil and Stencil.cpp - please, review them
Ready with "hack":
- StencilTwoSided.cpp: please, see the line 113 in apply():
glEnable(GL_STENCIL_TEST_TWO_SIDE);
This line used to be in getModeUsage() as
usage.usesMode(GL_STENCIL_TEST_TWO_SIDE);
but it produces OpenGL errors on ATI as it is unknown value there (it is Nvidia extension).
Problems with my "glEnable" solution:
- it enables two side stenciling forever, and it will disturb any other single-side stenciling in the scene graph.
"
All size() methods are now renamed to volume(). At present only the CompositePlacer will use it for randomly choose a place according to the volumes of all children.
"
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.
"
