Particle Transparency Issue Going from Irr 1.2 -> Irr 1.3

[utNero]

Hello, I'm hoping someone can give my some advice on a problem i'm facing. It has to do with an apparent change in the way materials may be used in our scene.

We had begun using particle systems recently where the billboards are shaded with the EMT_TRANSPARENT_ADD_COLOR material type. From my understanding, the output fragment should be srcColor + destColor. Using an image that has a black background and some non-black detail we were getting the output we expected while using irrlicht 1.2 .

Before updating to Irrlicht 1.3, this is how the scene looked:


However, when we updated our code base to use irrlicht 1.3, we started to get some undesirable results. After updating to Irrlicht 1.3, this is how the scene looks:




Now, I have confirmed that the renderer, COpenGLMaterialRenderer_TRANSPARENT_ADD_COLOR, is being executed when the particles are being shaded. Also, I've compared the diffs between the pre1.3 and post1.3 versions of our codebase and it seems that only irrlicht files were updated. So I'm hoping that some of you have had this problem during the transition between versions and have a decent solution.

Judging from the screenshots, I've come to two possible causes for the problem:

1) The shader was mistakenly altered and now the equation is no longer ( srcColor + dstColor ) or
2) The particles are not being sorted back to front before being drawn.

Number (1) doesn't seem very likely. Number (2) does however, as I have yet to see any sort of sorting code in the particle system render method. Also, notice that the lone particles (ones that do not have another particle in front or behind them from the camera POV) seem to be shaded correctly. This would also hint to me that the particles are not being transparency sorted back to front.

Any help that you could give would be greatly appreciated! If you feel I've left something else, please make note and I'll try to provide more information. Thanks!

[Robert Y.]

I have the feeling that indeed some of the sorting code has been changed for the worse:
http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=20087
My problems with collision could well be because of erroneous Z-sorting. You could try that fix. There are lots of similar source code changes. Maybe one of them causes this problem. Maybe it's also causing the render/octree problems reported in Vista (in fact, I don't think Vista is the problem, but wrong sorting in 1.3 - can't test it however, as I'm sticking to XP for now).

[utNero]

I'm leaning heavily towards it being a sorting problem. I injected some of my own code in the ParticleSystemSceneNode render method that will sort the particles based on z depth relative to camera and the transparency issues were mostly resolved. I say mostly because I think I did the inverse view transform incorrectly so the sorting only worked properly from certain angles.

Anyway, I'm hesitant to keep this solution as it seems that sorting should be done in another area and I wouldn't want it to do twice the work for one result.

In response to your post Robert, there may in fact be a problem with their sorting routine, but I'm not sure if it is related to this one. I think my issue is that there is _no_ sorting going on for the particles, not that the sorting is producing incorrect results.

I'm very new to these boards, do the people that actually wrote the code provide assistance in the issues or is it mainly the rest of the community that provides answers?

[utNero]

So, I was able to get a temporary solution to the problem, although I don't think it is a final one, (it is also only an OpenGL fix) :

In COpenGLMaterialRenderer.h in COpenGLMaterialRenderer_TRANSPARENT_ADD_COLOR::OnSetMaterial:

Code: Select all

Driver->disableTextures(1);
		Driver->setTexture(0, material.Textures[0]);
		//if (material.MaterialType != lastMaterial.MaterialType || resetAllRenderstates)
		{
			glDisable(GL_ALPHA_TEST);
            glDepthMask(0);

			glBlendFunc(GL_ONE, GL_ONE_MINUS_SRC_COLOR);
			glTexEnvi(GL_TEXTURE_ENV, GL_TEXTURE_ENV_MODE, GL_MODULATE);
			glEnable(GL_BLEND);
		}

I added the glDepthMask(0) to disable depth write to remove the sorting problem.

I then added a method COpenGLMaterialRenderer_TRANSPARENT_ADD_COLOR::OnUnsetMaterial()

Code: Select all

void OnUnsetMaterial()
    {
       glDepthMask(1);
    }

Just to be safe. The appearance still looks correct without it, but I dont want the lack of depth write to accidentally leak into the other shaders.

[Robert Y.]

I'm very new to these boards, do the people that actually wrote the code provide assistance in the issues or is it mainly the rest of the community that provides answers?

The great thing of irrlicht imho is this forum, were indeed some developers are very active. Much better than some other engines I tried.

[hybrid]

You should disable the zbuffer via the material. This works without changing the code. And it is slightly faster.

[utNero]

You should disable the zbuffer via the material. This works without changing the code. And it is slightly faster.

Oh, I agree, setting it in the material flags for a scene node is definitely a better idea. I'm not sure why it would be slightly faster, but I can see that it would propogate to any shader i used.

Is this the general solution to the problem or should the particle system be doing this by default?

[hybrid]

No, the particle system won't do it (IMHO) because there are situations in which it is not recommnded to do so.
It's slightly faster because the disabling would be done every time the material is used while the material flags are only updated when changed.