Irrlicht Engine

Posted: **Sat Oct 26, 2019 7:18 am**

Hi all

I have some game which i want to port done over irrlicht 1.4.1. So i of course want to make it works on 1.8.4 because of many reassons (bugfixes and stuff).

Now, i doing all easy things and stuck with some remainin ones.

For example that piece of code:

Code: Select all

 
//! Sets the projection matrix of the camera. The core::matrix4 class has some methods
//! to build a projection matrix. e.g: core::matrix4::buildProjectionMatrixPerspectiveFovLH
//! \param projection: The new projection matrix of the camera. 
void CCameraSceneNode::setProjectionMatrix(const core::matrix4& projection)
{
    ViewArea.Matrices [ video::ETS_PROJECTION ] = projection;
    ViewArea.setTransformState ( video::ETS_PROJECTION );
}

Error on me on 1.8.4 with words :

For first line: error: ‘irr::core::matrix4 irr::scene::SViewFrustum::Matrices [2]’ is private within this context
For second line: error: ‘struct irr::scene::SViewFrustum’ has no member named ‘setTransformState’; did you mean ‘getTransform’?

"ViewArea" are "SViewFrustum ViewArea;"

From irrlicht's SViewFrustum.h i can see that this part start to be private now indeed.

So while compiler is right, how to deal with that and make code works on 1.8.4 as it works on 1.4.1 before ?

And another issue, in all over the place i have that call:

Code: Select all

 
getSmgr()->getSceneCollisionManager()->getCollisionPoint(line, getLevel()->getMetaSelector(),intersection,tri);

But in newer version of function was added one more parametr, "hitNode". Currently i just doing it like this:

Code: Select all

 
#ifdef __irrlicht_1_8_4__
scene::ISceneNode* hitNode;
getSmgr()->getSceneCollisionManager()->getCollisionPoint(line, getLevel()->getMetaSelector(),intersection,tri,hitNode);
#else
getSmgr()->getSceneCollisionManager()->getCollisionPoint(line, getLevel()->getMetaSelector(),intersection,tri);
#endif

And while it compiles , i not sure if it will works with that empty hitNode.

Thanks !

Posted: **Sat Oct 26, 2019 9:26 am**

hitNode is no problem, input is ignored, output is the node which got hit - which you can use or ignore.

For the camera - you should indeed use getTransform that returns a reference. Don't know what the setTransformState did back then. But you can compare to the CCameraSceneNode.cpp implementation.
So it's now:

Code: Select all

 
ViewArea.getTransform ( video::ETS_PROJECTION ) = projection;

Posted: **Sat Oct 26, 2019 11:29 am**

Thanks !

So the both strings replace by that one.. Then how to deal with that ? Expectually those returns, which before retunr that private Matrices thing ..

Code: Select all

 
const core::matrix4& CCameraSceneNode::getProjectionMatrix() const
{
    return ViewArea.Matrices [ video::ETS_PROJECTION ];
}
 
//! Gets the current view matrix of the camera
//! \return Returns the current view matrix of the camera.
const core::matrix4& CCameraSceneNode::getViewMatrix() const
{
    return ViewArea.Matrices [ video::ETS_VIEW ];
 
 
void CCameraSceneNode::recalculateProjectionMatrix()
{
    ViewArea.Matrices [ video::ETS_PROJECTION ].buildProjectionMatrixPerspectiveFovLH(Fovy, Aspect, ZNear, ZFar);
    ViewArea.setTransformState ( video::ETS_PROJECTION );
}
 
void CCameraSceneNode::render()
{   
    video::IVideoDriver* driver = SceneManager->getVideoDriver();
    if ( driver)
    {
        driver->setTransform(video::ETS_PROJECTION, ViewArea.Matrices [ video::ETS_PROJECTION ] );
        driver->setTransform(video::ETS_VIEW, ViewArea.Matrices [ video::ETS_VIEW ] );
    }
}
 
 
//! returns the axis aligned bounding box of this node
const core::aabbox3d<f32>& CCameraSceneNode::getBoundingBox() const
{
    return ViewArea.getBoundingBox();
 
 
void CCameraSceneNode::recalculateViewArea()
{
    ViewArea.cameraPosition = getAbsolutePosition();
    ViewArea.setFrom ( ViewArea.Matrices [ SViewFrustum::ETS_VIEW_PROJECTION_3 ] );

Posted: **Sat Oct 26, 2019 4:58 pm**

Can't you check CCameraSceneNode.cpp? It should do all the new stuff.

Posted: **Sat Oct 26, 2019 6:13 pm**

Hm, seems that file its just straight copy of mention by you CCameraSceneNode.cpp , funny

Thanks!

Posted: **Sun Oct 27, 2019 11:08 am**

Maybe you had some bugfix in there before Irrlicht had it :-)

Posted: **Mon Nov 04, 2019 10:50 am**

@CuteAlien

Maybe you had some bugfix in there before Irrlicht had it

Compared files from irrlicht 1.4.1 and one placed in game : and the 100% exactly the same. Dunno what was the reassons behind it..

Anyway, when i build it for 1.8.4, i have some interesting issues appears:

1). Shift+ move keys stop working for "sprint".
2). The "bots" all have mirrored movement, textures, animation. I.e. walking on you rotated, faces wath in other side , etc
3). Some textures just not on the place where they should be

Have any idea what can be cause of that ? When i compile code for 1.8.4 , i have thorugh that kind of warning:

Code: Select all

 
CAIZombie.cpp:832:59: warning: 'void irr::core::CMatrix4<T>::transformBox(irr::core::aabbox3d<float>&) const [with T = float]' is deprecated [-Wdeprecated-declarations]
     m_pNode->getAbsoluteTransformation().transformBox(tbox);
                                                           ^
In file included from include_1.8.4/SMaterial.h:9:0,
                 from include_1.8.4/IMeshBuffer.h:9,
                 from include_1.8.4/IDynamicMeshBuffer.h:8,
                 from include_1.8.4/CDynamicMeshBuffer.h:8,
                 from include_1.8.4/irrlicht.h:34,
                 from CAIZombie.h:12,
                 from CAIZombie.cpp:1:
include_1.8.4/matrix4.h:1205:31: note: declared here
  _IRR_DEPRECATED_ inline void CMatrix4<T>::transformBox(core::aabbox3d<f32>& box) const
                               ^~~~~~~~~~~

Maybe that can be cause at least of the mirrored bot's movements ?

And the same kind of warning i have when build "level.cpp" (which have textures puts on wrong places):

Code: Select all

 
CLevel.cpp:374:109: warning: 'irr::scene::ITriangleSelector* irr::scene::ISceneManager::createOctTreeTriangleSelector(irr::scene::IMesh*, irr::scene::ISceneNode*, irr::s32)' is deprecated [-Wdeprecated-declarations]
                     selector = m_pGame->getSmgr()->createOctTreeTriangleSelector(mesh->getMesh(0), node, 128);
                                                                                                             ^
In file included from include_1.8.4/irrlicht.h:135:0,
                 from CLevel.h:13,
                 from CLevel.cpp:1:
include_1.8.4/ISceneManager.h:1343:39: note: declared here
   _IRR_DEPRECATED_ ITriangleSelector* createOctTreeTriangleSelector(IMesh* mesh,
                                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~

So maybe that one also related ?

Sure they deprecated, but are the should make it all looks wrong ?:)

Posted: **Mon Nov 04, 2019 5:52 pm**

Deprecacted shouldn't change behavior. But something with rotations got fixed (and thereby broke some old code, that one couldn't be fixed otherwise as it involved constructors if I remember correct).
To find out if you are affected by that one - go int quaternion.h and set IRR_TEST_BROKEN_QUATERNION_USE to 1
If you now get compile-errors in your application (not compiling Irrlicht, just your own app), then you have to fix some stuff:
For every line with a compile-errors you have to change the corresponding lines like that:
- When you pass the matrix to the quaternion constructor then replace the matrix by the transposed matrix.
- For uses of quaternion::getMatrix() you have to use quaternion::getMatrix_transposed instead.

Posted: **Mon Nov 04, 2019 10:22 pm**

Thanks for idea, tested, but nope, no errors

All compiles the same. It should be errors, no warnings or anything, i.e. code can't compiles right ? My one compiles after i set it to 1 , sadly

So seems something else ..

Posted: **Tue Nov 05, 2019 10:46 am**

Yeah, would be errors. Hard for me to help as I don't know what you are doing in your code. Can you for example reproduce this by loading animated models in the meshviewer example and things are mirrored there as well? In that case you could send me one of the models and I'll take a look.

Posted: **Sat Nov 09, 2019 12:22 pm**

Hard for me to help as I don't know what you are doing in your code. Can you for example reproduce this by loading animated models in the meshviewer example and things are mirrored there as well? In that case you could send me one of the models and I'll take a look.

In 09.Meshviewer all loads just fine. Its my changes in the code from 1.4.1 to 1.8.4 which cause that strange "reverted" bots looks and strange issues with textures being not on the place where the are with 1.4.1. Also, some textures just didn't draws until i didn't come closer to them, then they appears. But if i go far away, i can see other textures, but not some of them which disappeared completely and only start to be visibly if i come closer to them again.

See below plz the changes i do. Firstly those ones which i sure should't cause that kind of harm:

For first, in many place i had to do something like that

Code: Select all

 
    #ifdef __irrlicht_1_8_4__
    scene::ISceneNode* hitNode;
    return m_pGame->getSmgr()->getSceneCollisionManager()->getCollisionPoint(line, m_pMetaSelector, intersection, tri,hitNode);
    #else
    return m_pGame->getSmgr()->getSceneCollisionManager()->getCollisionPoint(line, m_pMetaSelector, intersection, tri);
    #endif

Also, that:

Code: Select all

 
        #ifdef __irrlicht_1_8_4__
        stringw kc (m_nKillCombo);
        #else
        stringw kc = m_nKillCombo;
        #endif

Also a bit of changes to particlesystem:

Code: Select all

 
    #ifndef __irrlicht_1_8_4__
    ps->setParticleSize(dimension2d<f32>(7.0f, 7.0f));
    #endif
 
    IParticleEmitter* em = ps->createBoxEmitter(
        aabbox3d<f32>(-1,-1,-1,1,1,1),
        vector3df(0.0f,0.0f,0.0f),
        100,100,
        SColor(0,255,255,255), SColor(0,255,255,255),
        400,400);
        
    #ifdef __irrlicht_1_8_4__
    em->setMinStartSize(dimension2d<f32>(7.0f, 7.0f));
    em->setMaxStartSize(dimension2d<f32>(7.0f, 7.0f));
    #endif
    
    ps->setEmitter(em);
    em->drop();

But those ones probabaly are all fine. The last "big" changes, are CameraSceneNode.cpp, which i assume exactly which cause all those issues. I just send you a link on .cpp file in PM, as it not public, plz , if you can, check briefly if there is anything which can cause those issues. There lots of ifdef __irrlicht_1_8_4__ , so that is the parts i put in.

I am sure something still missing there ..

Personally i don't like that part:

Code: Select all

 
    #ifdef __irrlicht_1_8_4__
    ViewArea.cameraPosition = getAbsolutePosition();
 
    core::matrix4 m(core::matrix4::EM4CONST_NOTHING);
    m.setbyproduct_nocheck(ViewArea.getTransform(video::ETS_PROJECTION),ViewArea.getTransform(video::ETS_VIEW));
    ViewArea.setFrom(m);
 
    #else
 
    ViewArea.cameraPosition = getAbsolutePosition();
    ViewArea.setFrom ( ViewArea.Matrices [ SViewFrustum::ETS_VIEW_PROJECTION_3 ] );
    #endif

Because when i play with commenting out it, it seems that its all very related .. And the fact that there is no ETS_VIEW_PROJECTION_3 anymore in 1.8.4, but just ETS_PROJECTION, that probabaly can make those issues ?

In the include/SViewFrustum.h of irrlicht 1.4.1, it was like this:

Code: Select all

 
enum E_TRANSFORMATION_STATE_3
        {
            ETS_VIEW_PROJECTION_3 = video::ETS_PROJECTION + 1,
            ETS_VIEW_MODEL_INVERSE_3,
            ETS_CURRENT_3,
            ETS_COUNT_3
        };

Now, with 1.8.4 it all changes to :

Code: Select all

 
    private:
        //! Hold a copy of important transform matrices
        enum E_TRANSFORMATION_STATE_FRUSTUM
        {
            ETS_VIEW = 0,
            ETS_PROJECTION = 1,
            ETS_COUNT_FRUSTUM
        };

And start to be private, etc.. So i not sure if that part is correct at all.

Posted: **Sat Nov 09, 2019 12:56 pm**

Collision and particles shouldn't affect animation and texture-uv's. If you doubt them just disable those for testing and check if it fixes anything.

This approach is generally a good way to debug - disable as much as you can until either only the bug is left or it starts working (this technique is generally called divide & conquer debugging).

I suppose all your camera changes are based on how cameras in Irrlicht 1.4 and 1.8 look like, so obviously nothing wrong I can find there. And on first view the defaults seem to try to keep old behavior intact. Anyway the trouble doesn't sound like camera as you didn't report problems with that.

My main suspect was a bug in model loader, but if it still works the same in meshviewer example then that's also not it.

You need to find the minimal code to reproduce the changes which can be run on 1.4 and 1.8. Then we can locate the real bug.

Posted: **Sat Nov 09, 2019 1:00 pm**

I update/edit previous post , check plz latest part about SViewFrustum::ETS_VIEW_PROJECTION_3 and stuff. I think is that one which can cause issues as well ? I think it can be just 2 bugs for example. One for rotated bots, and another one with those disappeared textures when i come/out close/far of them , which probabaly can be that SViewFrustum::ETS_VIEW_PROJECTION_3 changes ?

Posted: **Sat Nov 09, 2019 1:22 pm**

Sorry, I also have no idea what those ETS_VIEW_PROJECTION_3 stuff was about. That was before my time. But if your old camera looks like old Irrlicht camera and new camera looks like new Irrlicht camera it should be fine. If camera projection was wrong then your whole scene would be wrong, not just some of the bots.

Disappering textures make no sense yet to me. It could be broken mipmapping maybe as textures switch to mipmaps at certain distances so if the info in the mipmaps is bad it would look broken based on distance. But don't know if there had been any changes there between 1.4 and 1.8 (I was also just a user of Irrlicht at that time).

Btw, Irrlicht svn trunk fixed a few 1.8 bugs - no idea if any of them have to to anything with your troubles. But might be worth for you to give svn trunk version a shot.

Sorry, I really can't help much without having code to debug which I can run and where I can see what's going on. Everything else is guessing around.

Posted: **Sat Nov 09, 2019 1:33 pm**

I probably will try to go that way : trying to compile code with all irrlicht versions since 1.4.1 , one by one, to see how and when things changes , and will also test svn one too, yep.

What i noticed now, is that be it 1.4.1, or 1.8.1 , if i build irrlicht with SDL renderer instead of win32 , then , in the game "shift+arrow keys" didn't works. Probably just SDL code didn't handle it at all, while win32 code did ?

Irrlicht Engine

migration from irrlicht 1.4.1 to 1.8.4

migration from irrlicht 1.4.1 to 1.8.4

Re: migration from irrlicht 1.4.1 to 1.8.4

Re: migration from irrlicht 1.4.1 to 1.8.4

Re: migration from irrlicht 1.4.1 to 1.8.4

Re: migration from irrlicht 1.4.1 to 1.8.4

Re: migration from irrlicht 1.4.1 to 1.8.4

Re: migration from irrlicht 1.4.1 to 1.8.4

Re: migration from irrlicht 1.4.1 to 1.8.4

Re: migration from irrlicht 1.4.1 to 1.8.4

Re: migration from irrlicht 1.4.1 to 1.8.4

Re: migration from irrlicht 1.4.1 to 1.8.4

Re: migration from irrlicht 1.4.1 to 1.8.4

Re: migration from irrlicht 1.4.1 to 1.8.4

Re: migration from irrlicht 1.4.1 to 1.8.4

Re: migration from irrlicht 1.4.1 to 1.8.4