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.
"
Texture.cpp:applyTexImage2D_subload:
<code>
unsigned char* data = = (unsigned char*)image->data();
if (needImageRescale) {
// allocates rescale buffer
data = new unsigned char[newTotalSize];
// calls gluScaleImage into the data buffer
}
const unsigned char* dataPtr = image->data();
// subloads 'dataPtr'
// deletes 'data'
</code>
In effect, the scaled data would never be used.
I've also replaced bits of duplicate code in Texture1D/2D/2DArray/3D/Cubemap/Rectangle
that checks if the texture image can/should be unref'd with common functionality in
Texture.cpp.
"
osgWidget::Input:
[Functional changes]
- Previously, the field would be filled with spaces up to its max length, and typing would just replace the spaces. Also, there was a _textLength variable that kept track of the real length of text in the field, since the osgText::Text's length just reflected the length of spaces+text entered. This was not great, as you could still select the spaces with the mouse and it just feels hacky. So I changed it to only contain the text entered, no spaces, and _textLength was removed since it's now redundant (the osgText::Text's length is used instead).
- Fixed the selection size which (visually only) showed one more character selected than what was really selected.
- Fixed selection by dragging the mouse, it would sometimes not select the last character of the string.
- Cursor will now accurately reflect whether insert mode is activated (block cursor) or we're in normal mode (line cursor) like in most editors.
- Implemented Ctrl-X (cut)
- Added a new clear() method that allows the field to be emptied correctly. Useful for a command line interface, for example (hint, hint).
- Mouse and keyboard event handler methods would always return false, which meant selecting with the mouse would also rotate the trackball, and typing an 's' would turn on stats.
[Code cleanup]
- Renamed the (local) _selectionMin and _selectionMax variables which are used in a lot of places, as the underscores would lead to think they were members. Either I called them selection{Min|Max} or delete{Min|Max} where it made more sense.
- Fixed some indenting which was at 3 spaces (inconsistently), I'm sure I didn't catch all the lines where this was the case though.
- Put spaces between variable, operator and value where missing, especially in for()s. Again I only did this where I made changes, there are probably others left.
The result is that delete, backspace, Ctrl-X, Ctrl-C, Ctrl-V, and typing behaviour should now be consistent with text editor conventions, whether insert mode is enabled or not. I hope. :-)
Note, there's a nasty const_cast in there. Why isn't osgText::Font::getGlyph() declared const?
Also, as a note, the current implementation of cut, copy and paste (in addition to being Windows only, yuck) gets and puts the data into an std::string, thus if the osgText::String in the field contains unicode characters I think it won't work correctly. Perhaps someone could implement a proper clipboard class that would be cross-platform and support osgText::String (more precisely other languages like Chinese) correctly? Cut, copy and paste are not critical to what I'm doing so I won't invest the time to do that, but I just thought I'd mention it.
"
crash with some files.
Actually, itr was incremented into the loop and after the test with
nlist.end().
Then, the unreferencing of itr when nlist is equals to nlist.end() caused
the crash."
The current version crashes when encountering global materials, as also reported in the forum by the author of the plugin.
The problem in mesh.cpp (app. ln 247) is, that references to global materials that are given in curly brackets {} are not supported by the reader. However, curly brackets seem to be common, according to Bourke. Unfortunately, I found no specification. However, also the DirectX model viewer that comes with the DirectX-SDK (August 2009) expects curly brackets and refuses models without them.
My fix checks 2 more cases ("{ aMaterial }" -> 3 tokens and "{aMaterial}" -> 1 token), and extracts the material name for the lookup. I don't know if this is the most elegant solution, but the tokenizer seems to split based on white spaces.
You can reproduce the bug with the attached model (box.x), which loads fine in other tools, such as 3DSmax, DeepExploration or the DirectX model viewer. When I remove the curly brackets at the reference of "myGlobalMaterial", it loads in osgviewer, but is not standard conform.
"
submission email from Nathan: "I discovered a problem with POINT_ROT_EYE billboards in IntersectionVisitor: because we pass in just the model matrix to Billboard::computeBillboardMatrix, the billboard gets the wrong up vector. It really needs to take the view matrix into account to get the correct up vector.
This version of IntersectionVisitor.cpp is made against today's SVN. It corrects the problem by computing the billboard matrix using the complete modelview, and then multiplies by the inverse of the view matrix before pushing onto IntersectionVisitor's model stack. The only code I changed is in apply(Billboard&)."
notes from Robert, refactored the matrix multiplication code and the use of RefMatrix to make Nathan's changes more efficient.
The fbx plugin won't compile using gcc 4.3.2. I made the following
minor changes:
1. WriterNodeVisitor.cpp needed limits.h added to the headers.
2. gcc does not allow structures to be defined inside of functions, so
I moved the definition of PolygonRef out of the function to a global
scope (right above the function readMesh).
I also removed a bunch of embedded carriage returns
- missing copy attribute _referenceFrame in ClipNode in copy constructor
- checked iterators against the end in osgText
- close codec context in ffmpeg plugin to avoid memory leak
"
"enable thread locking in libavcodec
This is required for a multithreaded application using ffmpeg from
another thread."
"Prevent the audio from videos from hanging on exit if they are paused.
The video decoder already has similar logic."
"Add a way to retrieve the creation time for MPEG-4 files."
"fmpeg, improve wait for close logic
Both audio and video destructors have been succesfully using the logic,
if(isRunning())
{
m_exit = true;
join();
}
since it was introduced,
but the close routines are using,
m_exit = true;
if(isRunning() && waitForThreadToExit)
{
while(isRunning()) { OpenThreads::Thread::YieldCurrentThread(); }
}
which not only is it doing an unnecessary busy wait, but it doesn't
guaranteed that the other thread has terminated, just that it has
progressed far enough that OpenThreads has set the thread status as
not running. Like the destructor set the m_exit after checking
isRunning() to avoid the race condition of not getting to join()
because the thread was running, but isRunning() returns false.
Now that FFmpeg*close is fixed, call it from the destructor as well
to have that code in only one location."
osgViewer behaves smarter, when the computer will reboot or shutdown. In
older versions the reboot/shutdown got cancelled by GraphicsWindowCocoa,
now it behaves more system conform.
"
seems that the number of current active texture is wrong. It's because
of the line in Texture::TextureObjectSet::flushDeletedTextureObjects
_parent->getNumberActiveTextureObjects() += numDeleted;"
no PixelBufferObject 00000000, 00000000 pbo=00000000
It's kind of annoying since there is nothing actually wrong. The message is generated from TextureRectangle::applyTexImage_subload when it fails to create a pbo, even if the Image object is not even requesting to use a pbo. This message is not generated by all the other code in TextureRectangle.cpp & Texture.cpp that also attempts to create pbo's. I've modified TextureRectangle.cpp to remove this message, so it is at least consistent with the other code."
uncovered what looks like a type in the "src\osgPlugins\dae\
daeRMaterials.cpp" file. Line 1094 reads:
^^^
parameters.filter_min = getFilterMode(sampler->getMagfilter()->
getValue(), false);
whereas it should read
^^^
parameters.filter_mag = getFilterMode(sampler->getMagfilter()->
getValue(), false);
"
Out application has the ability to switch to different types of terrains on the fly. This problem only exists in this type of situation.
The TXPArchive is held by the ReadWriterTXP class. When the TXPNode, which is the top level node, is released from memory, the archive associated to that TXPNode is also released. The issue is that the reference count on the TXPArchive never gets to zero.
The reason why the reference count never gets to zero is because the TXPParse, which is owned by the TXPArchive, stores a ref_ptr to the TXPArchive. You can then see why this becomes a problem. The TXPParser's ref_ptr cannot be unreferenced since the TXPArchive has not released the TXPParser.
Since the TXPParser is fully contained within the TXPArchive, I don't see the reason to have the TXPParser have a ref_ptr to the TXPArchive. I've made this change locally and have had no problems and our memory leak has been fixed.
"
