I have what appears to be a regression.
I have a somewhat complex project but I just switched to 1.6 from 1.5 this morning. I may regret that decision though because now gravity doesn't work. The ninja model which I'm using for testing just floats above my height-map generated terrain. Also before I would fall if I ran off the edge but now I just continue to float. The only code I changed for compatibility with 1.6 was my dimensions because I had to change from s32 to u32 to get it to build. And I added a "hasFinished" call to my custom scene node animator to try to shake something loose after it didn't work.
So, I'm thinking either (A) I was using a bug to make it work and didn't know it or (B) there is some sort of API change or bug that prevents it from working now. Or of course (C) I did something stupid and broke it myself although that seems unlikely this time.
If you need to see the code you can get it from my source forge svn.
https://phoenixkit.svn.sourceforge.net/ ... kit/Enigma
The issue is in the client project and the triangle selection and such is done in the InGameScreen class.
I'm kind of hoping this is a simple fix and someone posts a one line silver bullet. A guy can dream.
Irrlicht 1.6 Gravity broken?
Irrlicht 1.6 Gravity broken?
I'm not random you just don't get the &.
Hm, gravity in the Irrlicht demo still works, so it is at least not completely broken. Your createCollisionResponseAnimator call also looks fine to me. Can't really say where the problem is - maybe you can reproduce it with a smaller code example?
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
sample
if you build the following code against 1.5 Sydney falls into nothing. If you build against 1.6 she stays in her spot. you have to switch the parts labeled 1.5 and 1.6 which is just changing s32 to u32 because of that change in 1.6. The rest of the code is the same.
*Sample Edited*
Code: Select all
#include <irrlicht.h>
#ifdef _MSC_VER
#pragma comment(lib, "Irrlicht.lib")
#endif
using namespace irr;
using namespace core;
using namespace scene;
using namespace video;
using namespace io;
using namespace gui;
int main(int argc, char** argv)
{
/**/
//irrlicht 1.5
IrrlichtDevice *device =
createDevice(EDT_OPENGL, dimension2d<s32>(640, 480), 16,
false, false, false, 0);
/**/
/*
//irrlicht 1.6
IrrlichtDevice *device =
createDevice(EDT_OPENGL, dimension2d<u32>(640, 480), 16,
false, false, false, 0);
*/
device->setWindowCaption(L"Irrlicht Engine Collision Response Test.");
IVideoDriver* driver = device->getVideoDriver();
ISceneManager* smgr = device->getSceneManager();
IGUIEnvironment* guienv = device->getGUIEnvironment();
IAnimatedMesh* mesh = smgr->getMesh("../../media/sydney.md2");
IAnimatedMeshSceneNode* node = smgr->addAnimatedMeshSceneNode( mesh );
if (node)
{
node->setMaterialFlag(EMF_LIGHTING, false);
node->setFrameLoop(0, 310);
node->setMaterialTexture( 0, driver->getTexture("../../media/sydney.bmp") );
}
ICameraSceneNode* camera = smgr->addCameraSceneNode(0, vector3df(0,30,-40), vector3df(0,5,0));
IMetaTriangleSelector* meta = smgr->createMetaTriangleSelector();
scene::ISceneNodeAnimator* animator = smgr->createCollisionResponseAnimator(
meta,
node,
node->getBoundingBox().getExtent(),
core::vector3df(0,-3,0));
node->addAnimator(animator);
while(device->run())
{
driver->beginScene(true, true, SColor(0,200,200,200));
smgr->drawAll();
guienv->drawAll();
driver->endScene();
}
animator->drop();
device->drop();
return 0;
}
Last edited by disks86 on Wed Nov 04, 2009 8:01 pm, edited 1 time in total.
I'm not random you just don't get the &.
Thanks for the test. Strange results. The reason seem to be that the boundingbox is not valid at that point. Forcing the node to render once first will update it's bounding box and afterwards it works. So you can use that maybe as workaround.
Which leads to several questions - it should use the meshboundingbox and I don't know yet why that is not valid. Then also - why does the boundingbox matter at all for gravity.
Also I did see that you add the animator for another node than the one you created it with. I think you shouldn't do that (it will be set to the node on first rendering anyway, but I don't know the reason for that at the moment). There was some change in that stuff and it was maybe even between 1.5 and 1.5.1, so there could be another thing.
Which leads to several questions - it should use the meshboundingbox and I don't know yet why that is not valid. Then also - why does the boundingbox matter at all for gravity.
Also I did see that you add the animator for another node than the one you created it with. I think you shouldn't do that (it will be set to the node on first rendering anyway, but I don't know the reason for that at the moment). There was some change in that stuff and it was maybe even between 1.5 and 1.5.1, so there could be another thing.
IRC: #irrlicht on irc.libera.chat
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
Code snippet repository: https://github.com/mzeilfelder/irr-playground-micha
Free racer made with Irrlicht: http://www.irrgheist.com/hcraftsource.htm
good call
Hmm good call. I can confirm that the issue existed in 1.5.1. I went from 1.5 to 1.6 so that is why I reported it as a 1.6 regression. I can also confirm that forcing a render after creating a node causes the correct behavior in 1.5.1 and 1.6.
All of my tests where using MSVC8 but I wouldn't imagine it would be different for GCC. Thank you for your helpful replies CuteAlien that render trick should fix my code.
per changes.txt "TODO: set Gravity to Physically frame independent values" so maybe when that happens it will shake something loose. everyone having this issue can use that little trick for now though.
All of my tests where using MSVC8 but I wouldn't imagine it would be different for GCC. Thank you for your helpful replies CuteAlien that render trick should fix my code.
per changes.txt "TODO: set Gravity to Physically frame independent values" so maybe when that happens it will shake something loose. everyone having this issue can use that little trick for now though.
I'm not random you just don't get the &.