[fixed]Additive blending not reset

[Auria]

Hi,

( first of all, I hesitated a bit on whether to post this in the bugs section or not. I finally decided to be humble and ask if I'm doing something wrong first )

we are having an issue in SuperTuxKart that appears to be linked to irrlicht not resetting the "EMT_TRANSPARENT_ADD_COLOR" flag when 3D rendering is done and we switch to 2D rendering; even though our 2D material does not have that flag set, the GUI is rendered what seems to be additively

This happens first with the in-game "paused" dialog. If the dialog is shown while "slip stream" effect if used (which uses EMT_TRANSPARENT_ADD_COLOR) the dialog shows up white and empty ( see screenshot at https://sourceforge.net/tracker/?func=d ... tid=981038 ), while usually it has a black background and buttons on it (see screenshot of normal dialog at http://2.bp.blogspot.com/_im4Yv1xoVXw/S ... h/STK1.jpg )
As soon as we stop using EMT_TRANSPARENT_ADD_COLOR, the bug goes away.

A similar problem occurs in our "feature unlocked" screen. See screenshot : http://3.bp.blogspot.com/_im4Yv1xoVXw/S ... h/STK1.jpg
Notice the button at the bottom; normally the button's shadow would be shaded with transparency and there would be black text on it. That seems coherent with additive blending being used, however this is more puzzling as to my knowledge no additive blending is used in the 3D scene there.

Any clue? Are we doing something wrong, or should it work?

[Lonesome Ducky]

Have you tried using the Material2D? It's used in one of the examples if I remember correctly, and you could set it not to use additive blending

[hybrid]

Did you check with the D3D driver? Or is it an OpenGL only problem?

[Auria]

Ducky: We have a 2D material set, and it has additive blending off

Hybrid: I am on OS X atm so I am unable to test DirectX

[Auria]

Here is a patch against the model viewer sample that allows you to reproduce the issue :

Code: Select all

Index: examples/09.Meshviewer/main.cpp
===================================================================
--- examples/09.Meshviewer/main.cpp	(revision 3284)
+++ examples/09.Meshviewer/main.cpp	(working copy)
@@ -241,11 +241,17 @@
 		animModel->setAnimationSpeed(30);
 		Model = animModel;
 	}
-	Model->setMaterialFlag(video::EMF_LIGHTING, UseLight);
-	Model->setMaterialFlag(video::EMF_NORMALIZE_NORMALS, UseLight);
+	//Model->setMaterialFlag(video::EMF_LIGHTING, UseLight);
+	//Model->setMaterialFlag(video::EMF_NORMALIZE_NORMALS, UseLight);
 //	Model->setMaterialFlag(video::EMF_BACK_FACE_CULLING, false);
-	Model->setDebugDataVisible(scene::EDS_OFF);
+	//Model->setDebugDataVisible(scene::EDS_OFF);
+    
+    Model->getMaterial(0).MaterialType = video::EMT_TRANSPARENT_ADD_COLOR;
+    Model->getMaterial(0).ColorMaterial = video::ECM_DIFFUSE_AND_AMBIENT;
+    Model->getMaterial(0).setFlag(video::EMF_BACK_FACE_CULLING, false);
+    Model->getMaterial(0).setFlag(video::EMF_COLOR_MATERIAL, true);
 
+    
 	// we need to uncheck the menu entries. would be cool to fake a menu event, but
 	// that's not so simple. so we do it brute force
 	gui::IGUIContextMenu* menu = (gui::IGUIContextMenu*)Device->getGUIEnvironment()->getRootGUIElement()->getElementFromId(GUI_ID_TOGGLE_DEBUG_INFO, true);
@@ -901,8 +907,22 @@
 	img->setAlignment(EGUIA_UPPERLEFT, EGUIA_UPPERLEFT,
 			EGUIA_LOWERRIGHT, EGUIA_LOWERRIGHT);
 
-	// draw everything
-
+    
+    // setup 2D material as we want it
+    video::SMaterial& material2D = driver->getMaterial2D();
+    material2D.setFlag(video::EMF_ANTI_ALIASING, true);
+    for (unsigned int n=0; n<video::MATERIAL_MAX_TEXTURES; n++)
+    {
+        material2D.TextureLayer[n].BilinearFilter = true;
+        //material2D.TextureLayer[n].TextureWrap = ETC_CLAMP_TO_EDGE;
+        material2D.TextureLayer[n].TextureWrapU = video::ETC_CLAMP_TO_EDGE;
+        material2D.TextureLayer[n].TextureWrapV = video::ETC_CLAMP_TO_EDGE;
+        
+        material2D.TextureLayer[n].LODBias = 8;
+    }
+    material2D.AntiAliasing=video::EAAM_FULL_BASIC;
+    
+    // draw everything
 	while(Device->run() && driver)
 	{
 		if (Device->isWindowActive())
@@ -910,7 +930,10 @@
 			driver->beginScene(true, true, video::SColor(150,50,50,50));
 
 			smgr->drawAll();
+            
+            driver->enableMaterial2D();
 			env->drawAll();
+            driver->enableMaterial2D(false);
 
 			driver->endScene();

[Auria]

[bump]
I'd appreciate if someone could test and see if it's reproduced under DirectX, or at least some hint at whether it looks to be a bug in our code or a bug in irrlicht

[hybrid]

I currently have problems with my development machines. But I'll try once I figured those problems.

[Auria]

Here's a patch that corrects the issue :

Code: Select all

Index: Irrlicht/COpenGLDriver.cpp
===================================================================
--- Irrlicht/COpenGLDriver.cpp	(revision 3284)
+++ Irrlicht/COpenGLDriver.cpp	(working copy)
@@ -2837,20 +2837,26 @@
 		OverrideMaterial2D.ZWriteEnable=false;
 		setBasicRenderStates(OverrideMaterial2D, LastMaterial, false);
 		LastMaterial = OverrideMaterial2D;
+        
+        // TODO: read the alpha mode from the override material and don't hardcode it
+        glEnable(GL_BLEND);
+        glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);
 	}
+    else
+    {
+        if (alphaChannel || alpha)
+        {
+            glEnable(GL_BLEND);
+            glEnable(GL_ALPHA_TEST);
+            glAlphaFunc(GL_GREATER, 0.f);
+        }
+        else
+        {
+            glDisable(GL_BLEND);
+            glDisable(GL_ALPHA_TEST);
+        }
+    }
 
-	if (alphaChannel || alpha)
-	{
-		glEnable(GL_BLEND);
-		glEnable(GL_ALPHA_TEST);
-		glAlphaFunc(GL_GREATER, 0.f);
-	}
-	else
-	{
-		glDisable(GL_BLEND);
-		glDisable(GL_ALPHA_TEST);
-	}
-
 	if (texture)
 	{
 		if (!OverrideMaterial2DEnabled)

some blending modes are hardcoded for 2D and don't take the 2D material into account. Furthermore the blending function is not set, so the previous one remains.

Note that this patch is incomplete : it simply hardcodes what we needed for Supertuxkart, for testing purposes. For inclusion you will of course want to complete it so that it actually reads the desired material mode from the 2D material.

[Auria]

Sorry to be annoying, but I'm bumping this again. Since I was able to find a problem in the source code of irrlicht, I think this deserves a bug ticket to be created

[hybrid]

Well, this should be fixed in SVN already. Actually it's only the in the 1.7 branch for now, but will be merged down to trunk in the next days. Revision 3377 should be the one to check. I even added a test case for this.
For bug tickets: You can add them on your own, just follow this link to the bug tracker http://sourceforge.net/tracker/?group_i ... tid=540676
Didn't you do so already in the past?
I'm sorry that it took so long at that I even didn't post in here after the fix, but it was a quite busy time lately.

[Auria]

Hi hybrid,

thanks for the answer! I didn't know this was fixed in 1.7 branch, I'm very pleased to hear this

Regarding tickets on sourceforge, last time I looked I was under the impression that only project members had the right to submit tickets. But maybe I just got confused ^^
EDIT: checked again, I guess I must have been confused Indeed I can submit tickets

[hiker]

Hi hybrid,

do you have a rough idea when the next release (that fixes this bug) comes out - be it a 1.7*, or something newer? We are currently trying to get all bugs fixed in SuperTuxKart to get a RC out, and we have to know if we should use a work around for this bug, or can just wait for the next irrlicht version.

Cheers,
Joerg

[hybrid]

This bug will be in the 1.7.2 release, which will come out approx. in October. I'll look into some GUI bugs in the next days, and after that we'll push it out. The bug fix releases don't have a beta phase, so it won't take too long to get it onto the servers.
For your final version you should probably wait for Irrlicht 1.8, as the bug fix releases are usually not taken into the major Linux distributions.