SPK 1.05.02 + IrrQuadRenderer

Few days before final release, we started getting these weird problems with particle rendering.

I know, you all love colorful pictures, here are two:



I have game inventory with stuff (image 1 and 2).
When i drag some item and drop it without using (incorrect location), item returns back to inventory, leaving trail of star particles (on picture).
Each item returning to inventory creates own instance of SPK::ParticleSystem filled with SPK::Groups, each group has own SPK::IRR::IRRQuadRenderer so they are like independent.

Here's the problem, on image 2, sometimes, rarely, actually hard to initiate it, but once initiated its quite easy reproduceable error. So, when another item starts flying back to inventory, leaving trail of particles, AT START for a brief fraction of second PREVIOUS TRAIL (framed with purple) appears, stays there for a frame or two (probably until next update?), then instantly continues rendering correct new trail. Again, remember particle systems, groups and renderers are all separate and independent. We tried forcing update before first render - no result.

My guess would be to blame some code hidden deep or called from deep IRRQuadRenderer, which allocates vertex/index buffer and somehow gets old vertex data from previous particle effect. Or inherits that memory in another way. We tried everything, from calling system->update() few times to actually trying to hide first frames, attempted to force every SPK::Group to reallocate its buffers, but since this is uncontrolled data leak, we can't either control or hide this artifact. So I decided to call for help, hoping for at least 1-2 days fast response (perfectly today but i do realize this may take some time for Juff to see)

I have no idea where is the problem, but I think there is a way to know if its IRRQuadRenderer related or IRRRenderer or Irrlicht related.

You can render quads using IrrPointRenderer with type POINT_SPRITE, and with some additionnal configuration (scale, etc...) (I think it should work in 2D, but I'm not sure).

When this problem started to appear ?

Darktib wrote:

You can render quads using IrrPointRenderer with type POINT_SPRITE, and with some additionnal configuration (scale, etc...) (I think it should work in 2D, but I'm not sure).
When this problem started to appear ?

I will try with POINT_SPRITE tomorrow, its 23:22 here, quite late and I'm still at work. I better be going home quick
Problem started very long ago, but since its hard to reproduce, it got away unnoticed for a long time. Might be even before we updated Irrlicht to 1.7.1 and SPARK to 1.05.02, that's few months.

Hi,

I may have an idea about where your issue comes from even if I havent checked it deeply within code. I think it is related with the way Irrlicht handles VBO and how spark interacts with Irrlicht VBO. Actualy I m using a hack to initialize Irrlicht vbo : to prevent from reallocating vbos each time the buffer grows (typicaly at each frame at the beginning of a particle system), I m using the entire capacity at the first frame to allocate the total vbo and renders it (as Irrlicht allocates needed vbos at render time). Anyway there s apparently a problem with vbo memory allocation and reuse of former vbos and I will investigate.

What you can do is deactivates the use of vbo and the problem should be solved (I hope). I dont know why I activate the use of vbo per default as the hack never seemed that good to me (at first vbo were disabled per default). To deactivate vbo usage, just make a call to IRRBuffer::activateVBOHint(false) at SPARK initialization. You wont have any performance hit with small systems.

Hope this is it. If so, I will get into the code and solve the issue, if not, I have no other idea at the moment and will have to investigate.

Hope this helps

Juff wrote:

Hope this is it. If so, I will get into the code and solve the issue, if not, I have no other idea at the moment and will have to investigate.

Hope this helps,

cheers

Awesome, thanks for very fast reaction
Its 0:32AM here in Ukraine, I will be able to check your suggestion next morning in about 9-10 hours.

About the use case demo, I know you wanted one for SPARK. For few more days my hands are tied with NDA before game is released. I will post video of best particle effects used in game and (maybe?) some screenshots, in a few days, after release, then it becomes perfectly legal to publish ingame videos and screenshots. The effects and textures for them are packed into example folder in my particle editor project (SimpleSpark).

Hi guys.
I work with kvakvs on the same project. Today we tried both solutions -
1) deactivating vbo as Juff suggested
and 2) using IrrPointRenderer instead of IrrQuadRenderer.

The first solution did not help and i keep vbo deactivated for future.

In second case i got particles of 1 pixel size, without dirty geometry problems. I tried to set size greater than 1.0f and type of point POINT_SPRITE. I was unable to make it render anything else than single pixels.

Any other suggestions? Your help is appreciated!

Regarding the IRRPointRenderer that renders 1 pixel points, the is due to the way Irrlicht handles POINT_SPRITE. I cannot do anything about that.

For the problem of glitching, if its not vbos, I dont really know what it can be. Your call to activateVBOHint was made at game init before creating any system or SPARK stuff ?
The buffer is unique per group, so if groups are unique buffers are unique as well and that kind of stuff should not happen. The only thing that differs between IRRQuadRenderer and the other IRRRenderer is the drawCall to Irrlicht. Maybe trying to use the same call as the other renderer will solve the issue (instead of drawMeshBuffer using the other I dont have the code here so I cannot take a look).

Anyway i ll check in the code what it can be as soon as I can.

Can you tell me how you create particle systems exactly ? How do you destroy systems ? Are you using multi threading in some way with particles ?
Just to be sure i understood well the issue : the problem is that sometimes when creating a new particle system, the former one appears for one frame when rendering the new system. Is that it ?

Is the former system appearing always the last one created ? In which state is it ?

Are you sure it cannot be from your code ?

Juff wrote:

For the problem of glitching, if its not vbos, I dont really know what it can be. Your call to activateVBOHint was made at game init before creating any system or SPARK stuff ?

Yes, the call was made when creating LibSimpleSpark.CSparkLoader, so that is before creating any SPARK stuff. If I don't miss anything, this is guaranteed before first call to SPARK.

Juff wrote:

Can you tell me how you create particle systems exactly ?

SV (or me later) will quote the code in next message. Generally its done by SimpleSpark library, which source is uploaded to my website.

Code:

_ParticleSystem.reset ( SPK::IRR::IRRSystem::create (scene_manager->getRootSceneNode(), scene_manager) );

Then system is filled with SPK::Groups created with CSparkLoader::PrebuildGroup AND each group is added to vector of shared pointers (to be auto destroyed later).
Since we don't have noticeable memory leaks (had a long fight with them, and eventually I won), so this works correctly.

Juff wrote:

How do you destroy systems ?

Newer update to SimpleSpark (not published yet) returns boost::shared_ptr (wrapper class is configurable) which automatically deletes SPK::System and all SPK::Groups when particle effect wrapper class is destroyed in game. I don't call anything related to SPK::Registerable.

Code:

boost::scoped_ptr <SPK::IRR::IRRSystem> _ParticleSystem;
boost::shared_ptr <LSS::CSparkLoader> _Loader;
std::vector <ISprite::SharedPtr> _Sprites;
std::vector <SPKGroup_SharedPtr> _Groups;

Juff wrote:

Are you using multi threading in some way with particles ?

No. I try to avoid multithreading.

Juff wrote:

Just to be sure i understood well the issue : the problem is that sometimes when creating a new particle system, the former one appears for one frame when rendering the new system. Is that it ?

Exactly.
Previous path is rendered for a very short duration (supposedly 1-2 frames) then new effect continues normally without glitches.

Juff wrote:

Is the former system appearing always the last one created ? In which state is it ?

It shows previous particle effect's state before death (last frame).

Juff wrote:

Are you sure it cannot be from your code ?

The glitch? We were not able to locate the problem in our code, so my answer would be - no we did not find it

sv wrote:

In second case i got particles of 1 pixel size, without dirty geometry problems. I tried to set size greater than 1.0f and type of point POINT_SPRITE. I was unable to make it render anything else than single pixels.

That's weird, because in my editor changing the size - for example, setting it to 80 or more - cause points to be larger than 1 pixel, but it's in 3D... Anyway, which sizes have you tried ?

What is the event which starts this bug ? Have you tried to trace the number of rendered particles - I have seen you are using Visual Studio, maybe you can put à breakpoint when the number of rendered particles is too high.

I think I got it. Actually this is related to vbo implementation but even when not used, the first frame is rendered with the whole capacity of the buffer. I will release a version that fixes the bug in a clean way this week end. At the moment, you can do this quick fix :

In SPK_IRRQuadRenderer.cpp at the very end of the method createBuffers(const Group&) , add this line :

Code:

if (!useVBO) currentBuffer->setVBOInitialized(true);

You ll have to recompile at least the Irrlicht module. That should do the job. I'm pretty sure it is that.

One more thing about the way you delete systems and groups, are you deleting all the registerable the same way (emitters, renderers...). If no, you probably have some leaks. There is a way to delete every registerables within the deleted registerable : instead of calling, for instance :

Code:

delete system

call

Code:

SPK_Destroy(system)

This will delete all registerables withing the system (or any registerable) that are not still referenced in some other registerables. Every registerables must be created with the create method to do that.

If you use the create method, you still have access to registerable via the SPKFactory. You can trace registerables that are still alive with a call to :

Code:

SPKFactory::getInstance().traceAll()

Juff wrote:

In SPK_IRRQuadRenderer.cpp at the very end of the method createBuffers(const Group&) , add this line :

Code:

if (!useVBO) currentBuffer->setVBOInitialized(true);

You ll have to recompile at least the Irrlicht module. That should do the job. I'm pretty sure it is that.

Could not compile "if (!useVBO)", so instead I added just

Code:

currentBuffer->setVBOInitialized(true);

Looks like its working now. Thank you. Packaging and sending the release for review
Rest of stuff I will see on Monday.

Juff wrote:

One more thing about the way you delete systems and groups, are you deleting all the registerable the same way (emitters, renderers...). If no, you probably have some leaks. There is a way to delete every registerables within the deleted registerable : instead of calling, for instance :

Code:

delete system

call

Code:

SPK_Destroy(system)

About leaks.

Recently I spent few days localizing signifficant memory leaks (from 150 MB the game went up to 300 after playing 20-30 scenes for 20-30 minutes. I found the problem, and that's how shared pointers were introduced into my SimpleSpark. This fix eliminated most notable leaks (100-300kb each x lots), while leaving numerous tiny leaks <200 bytes behind. Well, I can afford to ignore them, for now, as that doesn't add up during typical gameplay duration (up to 4 hours).

I'll see how memory is freed in next engine version, which I'll launch in couple months after Mac version of the two games (first one written in HGE, and this one, we're releasing for Windows right now).

Ok, it is up to you.

I have release a maintenant version 1.05.03 that fixes the bug about glitching and improve vbo management.

Thanks for reporting.