problem switching to Irrlicht 1.4.2

[Masterhawk]

hi there,

today I spent my time in porting my Irrlicht1.1 project to version 1.4.2. Let's say, finally it's compiling....BUT...

I got several issues which came up with the new version.

1. Cruel texture problems




As you can see in these two images there is a major texture problem. Some textures are corrupted from far away, if you get nearer they show up correctly.
Other textures aren't shown anyway. And the last group of textures is completely displayed in the right way (like the stones under the water).
The maps are MY3D-files packed in a zip-file which worked correctly with 1.1

2. Keys strokes

The event receiver behave strange, too. When I hit the 'ESC'-key to show up the ingame-menu it's not sure if it'll show up. My other keys (e.g. 'Q' or 'Y') doesn't work at all. The same with the mouse buttons.
I don't have a clue what I did wrong.


The major problem is the texture issue, so if anyone knows a fix please help me

[JP]

For the event receiver i'm guessing you updated the OnEvent parameter to a const reference yeah? Though i suppose it wouldn't have compiled without that...

[Masterhawk]

sure i have

Code: Select all

virtual bool OnEvent(const SEvent& event)
{ ... }

[3DModelerMan]

I had the texture problem to, I fixed it by making my textures smaller, Are any of yours 2048 X 2048?, if so try 1024 X 1024.

[Masterhawk]

no the textures are definitely smaller than 2048 (around 512x512). Did you have the problem with MY3D?
Why does also the renderToTexture produce such weird results? On the water it works like a charm but on the portals it's totally messed up.

[3DModelerMan]

I used .obj model files.

[hybrid]

Hmm, strnage. I still have some models from you for testing in my repository, and had no problems the last time I checked them all. Will have to test them once my Linux machine is working again Do you create a custom scene node?
The RTT fix hasn't been applied to the 1.4 branch, which will make the RTTs not work without setting the texture wrap to no wrapping. At least that might help...
The event receiver problem is not clear, maybe some GUI elements are blocking the event reception.

[Masterhawk]

Hmm, strnage. I still have some models from you for testing in my repository, and had no problems the last time I checked them all. Will have to test them once my Linux machine is working again

Since I changed to 1.4.2 the "multiple texture loadings" didn't occur anymore. The current problem appear on all of my current maps. Perhaps I should create a simple app in order to reproduce the failure at a smaller amount of code.

Do you create a custom scene node?

No. I guess not

The RTT fix hasn't been applied to the 1.4 branch, which will make the RTTs not work without setting the texture wrap to no wrapping. At least that might help...

What does this RTT fix is all about? Will have a look at it. But it seems that this is caused by the same issue the other texture corruption is caused.

The event receiver problem is not clear, maybe some GUI elements are blocking the event reception.

Even when it worked correctly with Irrlicht1.1 i guess this will not take too much time to fix it. But the texture thing is really driving me nuts

[Masterhawk]

I could reproduce the problem with a very rudimentary app. I run the app with current release of irrlicht (1.4.2)

Code: Select all

#include <irrlicht.h>

using namespace irr;
using namespace core;
using namespace std;
using namespace scene;


int main(int argc, char* argv[])
{
	IrrlichtDevice* device = createDevice(video::EDT_OPENGL,dimension2d<s32>(1024,768),32,false,false,false);
	device->setWindowCaption(L"IrrlichtTest [MY3D + Irrlicht 1.4.2]");

	video::IVideoDriver* driver = device->getVideoDriver();
	ISceneManager* smgr = device->getSceneManager();

	device->getFileSystem()->addZipFileArchive("my3dmap.zip");
	ISceneNode* world = smgr->addAnimatedMeshSceneNode(smgr->getMesh("techdemo.my3d"));
	ICameraSceneNode* cam = smgr->addCameraSceneNodeFPS();

	while(device->run())
	{
		driver->beginScene(true, true, video::SColor(0,200,200,200));
		smgr->drawAll();
		driver->endScene();
	}
	return 0;
}

zip file (do not extract for testing): http://www.masterhawk-studios.de/upload/my3dmap.zip

[hybrid]

Ok, moving it to bug forum, but checking the files and code only tomorrow...

[jontan6]

try set anisotrophic true on the problematic materials?

[hybrid]

Ok, good news and bad news
The texture loading works in SVN/trunk, however, textures are once again multiply loaded
I'll dig into both things - porting the my3d loader back into 1.4 (or do you want to wait for 1.5 to use the new loader?) and duplicated texture loading.

[hybrid]

Ok, multiple texture loading is fixed, it's a problem with getAbsoluteFilename and the texture name handling in the texture cache. I'll check for the best possible solution to this problem and commit to SVN/trunk then.
Question remains if you want to have the my3d loader ported to 1.4, or if you want to change to 1.5 right away?!

[Masterhawk]

That's good news

Question remains if you want to have the my3d loader ported to 1.4, or if you want to change to 1.5 right away?!

What does "change to 1.5" mean? Compiling the SVN version then? If that's the case I will try this at first because I guess this means a little less work for you, isn't it? Also I will be up-to-date then

[hybrid]

I'd hope that simply copying the my3d loader over from SVN should cure the problems, but one never knows. And yes, you'd get all the nice new features, including VBOs and joystick support
For now you'll have to use SVN/trunk or the nightly builds, until a beta candidate or the final release are published (sometimes this year...)