migration from irrlicht 1.4.1 to 1.8.4

[CuteAlien]

TriangleSelectors add the triangles which are used in collision. So when you remove them all you have nothing left to collide against. And you fall down because of gravity. But that you fall down with old version with floor still in there but just cube disabled is indeed a bit strange. As that sounds like it wasn't colliding against floor-triangle even before, but probably against some cube below the floor.

I just coded a quick test with collisions against cubes. But again not noticing any new problem with that.

[kas1e]

..

[kas1e]

Interesting thing, if i just replace in that cube block that:

Code: Select all

 
selector = m_pGame->getSmgr()->createTriangleSelectorFromBoundingBox(node);
 

on that:

Code: Select all

 
selector = m_pGame->getSmgr()->createTriangleSelector(((IMeshSceneNode*)node)->getMesh(), node); 
 

Then bug surely gone.

[CuteAlien]

Edit: Sorry, got it all wrong on first answer. No double transformation going on. Uhm, so back to no clue. But I'll take another look next week. For today I've got to stop (and tomorrow not at my computer).
edit2: but it's something I didn't test yet. Above I tested collisions of a cube-mesh. Not a boundingbox triangle selector (very different thing). Anyway - it makes sense to use that one if your games is having levels with a completely flat floor (less triangles to check). So will definitely test it when I'm back. And I suppose those are maybe used for houses as well (most houses are boxes anyway...).

[CuteAlien]

OK, couldn't start weekend without hunting this down first - newest svn should have a fix.
Before r5350 there was no early-out test which used the boundingbox of CTriangleBBSelector, so all triangles got always tested. I changed that, but didn't notice that CTriangleBBSelector never had set a correct boundingbox. Now does.
Thanks a lot for noticing (and hunting down!) this problem.

[AReichl]

BoundingBox = box;
is used twice.

[kas1e]

@CuteAlien

OK, couldn't start weekend without hunting this down first - newest svn should have a fix.
Before r5350 there was no early-out test which used the boundingbox of CTriangleBBSelector, so all triangles got always tested. I changed that, but didn't notice that CTriangleBBSelector never had set a correct boundingbox. Now does.
Thanks a lot for noticing (and hunting down!) this problem.

Yeah, that fix it ! Thanks.

I have found another little bug, will make a video to show it as it quite hard to explain Its not related to that issue of course.

[CuteAlien]

BoundingBox = box;
is used twice.

Oops, thanks.

I have found another little bug, will make a video to show it as it quite hard to explain :) Its not related to that issue of course.

OK, keep 'em coming!

[kas1e]

@CuteAlien
In meantime also trying to understand what gl driver on amigaos4 and pandora do (or not do) which make those plain 2d images looks not clean, but a bit distored (which we discuss few pages back). Maybe its something like GL_NEAREST vs GL_LINEAR / GL_LINEAR_MIPMAP change somewhere ?

I made 2 screenshots, one withtout bug, and one with it. Can you maybe notice visually, what kind of opengl state can cause such a difference..

No bug (see how letters clean, as well as that tiny sticker-image ):



With bug (see what happens with letters and with sticker-image):



Dunno why it reacts like this, but maybe something was changed in irrlicht at some point, which cause such a difference only on Pandora's and AmigaOS4's GL drivers.

Pandora's developer do some tracing via apitrace of that testcase you made above, and we can see that

1. The GL_ALPHA_TEST is on, but only pixel with alpha==0 are dropped.
2. The Texture is set to be GL_LINEAR/GL_LINEAR_MIPMAP_NEAREST at first, but for each frame it is instead put back to GL_NEAREST/GL_NEAREST
Not much after that.

So, we think at moment, that maybe for win32 and linux picture are clean, just because win32/gl and linux/mesa do some filtering on top even if GL_NEAREST if used. Or some sort of anisotropic filtering automatically applied (or by irrlicht)..
Just images indeed looks like its GL_NEAREST (and that what we got on our setups).

[CuteAlien]

Does your font use any kind of alpha? What is this - a bitmap font?
Bad alpha can look a bit like that in that case. In which case it could also be a problem with texture locking when it reads the characters. We had for a long time stuff broken there, though it should be fixed now. But if you use latest svn versions you can still switch per define between 2 different texture lock implementations in COpenGLCoreTexture.h (the "Alternative method" stuff).

Filters... not sure if there should be a difference between filters unless you have some scaling going on (which you like do not have for fonts).
Do you draw directly to screen or do you draw into a rendertargettexture and then put that on the screen?

I suppose you could force certain filters in the draw2d functions by just setting them once more before it draw stuff (but I don't know which one you are using here ... for fonts it's the COpenGLDriver::draw2DImageBatch without the indices parameter.
So if you suspect it's filters (I don't think so), you could call before the glDrawElements call something like:
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST);

As for alpha functions and blending... stuff I'm still struggling with myself (it's on my todo). And that got changed a lot - so really depends which version you are using right now. Same place as above you could test stuff like glEnable(GL_ALPHA_TEST); (or glDisable).
And glAlphaFunc with some parameters (I have to read up on this myself first).

[kas1e]

Basically its all just about the same issue i have with even your simple test case. There i just show that bug with other images, so to maybe have a clue wtf. But your test case already show issue on pandora and amigaos, but didnt on linux and win32

[CuteAlien]

I'm not sure if it's really the same problem. Are those text with a font or did you just draw them into the image?
AntiAliasing obviously another candidate.

Anyway if it's not font but an image - then you can set those flags in the corresponding draw2DImage function which is used to test if it makes any difference. Shouldn't use alpha then... so glDisable(GL_ALPHA_TEST) in that case.

[kas1e]

Do you mean just like that ?

Code: Select all

 
    while(device->run())
    {
        s32 alpha = 250;
        driver->beginScene(true, true, SColor(255,0,0,0));
        glDisable(GL_ALPHA_TEST);
        driver->draw2DImage(logoTex, pos, rect<s32>(0,0,1024,768), 0, SColor(alpha,250,250,250), true);
        driver->endScene();
    }
 

Or you mean some "irrlicht's" way to do glDisable(GL_ALPHA_TEST); ?

[CuteAlien]

I meant - change it inside Irrlicht in the draw2DImage function after it sets setRenderStates2DMode and before the glDrawElements. Any filter and alpha settings you set there are then ensured to be used no matter what Irrlicht sets otherwise. So you can test directly if they have any effect on the result.

If you do it as in your post the last true parameter in draw2DImage would likely just enable alpha again. (if that's what you are using right now, test how setting it to false changes it - that's a quicker test I guess)

[kas1e]

So tried to add those:

glDisable(GL_ALPHA_TEST) : no changes
glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR); : no changes
glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST); : no changes.

I add those test calls in the first draw2Dimage() in the COpenGLDriver.cpp (there is 3 of them) , after setRenderStates2DMode(), but right before drawing call. Quite strange .. Strange twice that it works on win32 and linux, but didn't on pandora/amigaos4, which mean that there something in drivers, but then , why it works fine with 1.4.1 irrlicht ! And i even not about that font look, but just about even single picture which we test before. I can understand if it never works for amigaos4, but when it was clean for 1.4.1 irrlicht .. wtf..