Dice and collsion

[CuteAlien]

About the bug mentioned in the .X exporter. Wish I knew more about that - but I never hacked on that loader. If they have some examples it would probably be worth investigating. Maybe someone has motivation and time to do that?

There is one more format with skeleton animation - ms3d from Milkshape, but I guess that's even less common.
And 2 morph-animation formats for Quake (md2 and md3). All other formats are to my knowledge only static.

Maybe irrExt has some more loaders (https://sourceforge.net/p/irrext/code/HEAD/tree/trunk), but sourceforge servers are so slow right now that I can't check.

[Asimov]

Hi CuteAlien,

The .X file should have "NormalmapFilename" like the "TextureFilename" somehow.

It seems that both x exporters that I used, are creating faulty x models, which is annoying.
Just to think about it, yes these models work in Unity, but then Unity has built in shaders, so that is probably why. Also in Unity you have to put the textures and normalmap in material slots.
So I think to get the normalmaps to work properly a shader is needed.

I have had many years experience in making games models and normalmaps and so far irrlicht is the only engine I have had trouble with in regard to this.
However I like irrlicht and so far this is the only thing letting it down.

Code: Select all

What might work (untested): Load the .X mesh. Convert it with IMeshManipulator::createMeshWithTangents() to a mesh that can have normal maps.
Load that texture yourself (maybe convert it with makeNormalMapTexture or maybe not...). Set it as texture with index 1 to the material of your mesh. Change the MaterialType to video::EMT_PARALLAX_MAP_SOLID or maybe one of the other normal-map types (depends on the format used by the texture - see descriptions here: http://irrlicht.sourceforge.net/docu/na ... 0cbc5430f1). Also you might have to set MaterialTypeParam - obj loader does set it to 0.035 ... not sure right now what it's used for. But something about bumpiness as well I guess.

This looks interesting, but seems rather long winded, just to get a model into irrlicht. Also it looks rather over my head a little LOL. I will look into it though.

Btw, the obj loader has a problem with filenames with spaces.

Yeh I found this. It is annoying. I don't put spaces in filenames, but again the obj exporter sticks em in, but even after renaming the files, the normalmap did not show properly.
For some reason the obj is thinking my normalmap is a bumpmap, and they are two completely separate things. A bumpmap only works in one direction and a normalmap works in 3d space.

I am a little down hearted. I have made quite a few games over the years, and I really wanted to get this to work.
After this game I planned to port my Dalek Draughts game written in XNA over to irrlicht, but the normalmap thing bugs me a lot, as a normalmap is the only way to go to make a model look high resolution, when it isn't.

btw the texture maps and uvs are fine on my model as you can see here

[Asimov]

Hi,

This is shown in marmoset toolbag. Marmoset was made to show models as they appear in games in real time. So what you see here isn't a render, but an actual real time shot simulating a game environment. This really proves that my normalmap is fine. Also I can take my model into any engine apart from irrlicht and it will look like this.

I really wish irrlicht used the fbx standard that other engines use. It is so much better than obj or x format and it also handles animations.

Is there any chance of an fbx loader at any time?

I am still going to carry on trying for a bit, as irrlicht is the only engine I know that uses C++ and I like programming in C++, but I will not be able to complete my game unless normalmaps work.
I think I am really going to have to learn shaders, no matter how hard they are.

[rustyk]

@Asimov.

Sorry I meant recalculate your normals. Ok will try and check out your assets..

[CuteAlien]

Yeah, something like bump-map instead of normal-map is what I think is going wrong - the format is used wrong.
But you can try using other material-types after loading the .obj-file. Just set another MaterialType. Irrlicht supports both - normalmaps and bumps. Another suspicion I'm having is that it converts the texture once more although it maybe already has the correct format.

What I can say is that .obj will definitely have no animations.

I think someone started a fbx-loader but I have no idea in which state it is currently. Maybe it's mentioned somewhere on the forum. I don't think anyone in the team is currently working on another loader. So that patch would have to come from someone else.

Maybe there are b3d exporter plugins for 3ds max somewhere?

[rustyk]

Yeah, something like bump-map instead of normal-map is what I think is going wrong - the format is used wrong.

Yes, I agree with CuteAlien. I'm fairly new to irrlicht but this is the one thing that I noted when you would like to apply default normal mapping. You should load a bump map or displacement then it will be converted to normal along with the procedure. At least this is the solution that I learned.

Anyway, I tested your assets and the obj model normals looks good. Maybe this is just the problem. load bump then convert it with the necessary steps.

Sorry about the poor lighting, this is just a quick test but you can see it works

[rustyk]

I have converted your textures to bump map below, quick conversion and it's jpg only but you can try it out..

http://i.imgur.com/ndjonEI.jpg

[Asimov]

Hi Rustyk,

Thank you for the effort you have put in, but if I wanted a bumpmap I could have quite easily created a bumpmap. Compare your image to my marmoset image, and I am sure you can see the difference between a bumpmap and a normalmap.
They have been using normalmaps in games now for about 10 years. Most game engines don't even load ordinary bumpmaps anymore. Unity or Cryengine only use normalmaps nowadays.

Sorry about the poor lighting, this is just a quick test but you can see it works

Actually no I can't see it working. It looks like it is using my normalmap as a bumpmap, so it is not working. You can't see any detail in that image at all. It hasn't change the shape of the object.

Bump maps
These are textures that store an intensity, the relative height of pixels from the viewpoint of the camera. The pixels seem to be moved by the required distance in the direction of the face normals. (The "bump" consists only of a displacement, which takes place along the existing, and unchanged, normal-vector of the face.) You may either use greyscale pictures or the intensity values of a RGB-Texture (including images).

Normal maps
These are images that store a direction, the direction of normals directly in the RGB values of an image. They are much more accurate, as rather than only simulating the pixel being away from the face along a line, they can simulate that pixel being moved at any direction, in an arbitrary way. The drawbacks to normal maps are that unlike bump maps, which can easily be painted by hand, normal maps usually have to be generated in some way, often from higher resolution geometry than the geometry you're applying the map to.

I know you are trying to help, but the solution to my problem is not to change my normalmap to a bumpmap. I have baked down my game room from 70 million polygons to about 3000 polygons. A bumpmap just won't cut that kind of detail.

It seems the shader route is the only way to go with this. Thank you anyway

[rustyk]

No problem, glad to help but I think you're confused. Check out example 11 here. There's example of normal and parallax mapping there:

http://irrlicht.sourceforge.net/docu/example011.html

Have you even try to attempt and use the makeNormalMapTexture function?

excerpt from that tutorial:

Code: Select all

 
  video::ITexture* normalMap =
            driver->getTexture("../../media/rockwall_height.bmp");
 
        if (normalMap)
            driver->makeNormalMapTexture(normalMap, 9.0f);
The Normal Map and the displacement map/height map in the alpha channel video::ITexture* normalMap = driver->getTexture("../../media/rockwall_NRM.tga");
 
But just setting color and normal map is not everything. The material we want to use needs some additional informations per vertex like tangents and binormals. Because we are too lazy to calculate that information now, we let Irrlicht do this for us. That's why we call IMeshManipulator::createMeshWithTangents(). It creates a mesh copy with tangents and binormals from another mesh. After we've done that, we simply create a standard mesh scene node with this mesh copy, set color and normal map and adjust some other material settings. Note that we set EMF_FOG_ENABLE to true to enable fog in the room.
 
        scene::IMesh* tangentMesh = smgr->getMeshManipulator()->
                createMeshWithTangents(roomMesh->getMesh(0));
 
        room = smgr->addMeshSceneNode(tangentMesh);
        room->setMaterialTexture(0,
                driver->getTexture("../../media/rockwall.jpg"));
        room->setMaterialTexture(1, normalMap);
 

As I have said, it was a quick build, the bump map was not done properly so just to give you an idea.

Ok anyway, your on your own. hope you find your own solution.

[CuteAlien]

OK, I did a quick experiment and I think I got close:
Still some uv-texture problem and some missing details in the normalmap (especially at the top part).
The way I did that was kicking out the makeNormalMapTexture line in the obj file loader for a test. So it's as I guessed all the time - the texture is not in the format Irrlicht expects here. Unfortunately I don't know the format definitions, nor did I write the loader - so not sure why this line is in there.

If you are using Irrlicht svn trunk you can work around it with a little hack. Load the involved texture once before you load the model. Just do a IVideoDriver::getTexture call to put it into the cache. Then the loader will no longer do that conversion.

If you don't want to switch to svn trunk then you have to supply your own obj loader. Basically copy the code in COBJMeshFileLoader.cpp and .h and rename the file and the class (call it for examle MyObjMeshFileLoader). Then add those new files to your project. Kick out the line with "makeNormalMapTexture". Then add your own obj loader with ISceneManager::addExternalMeshLoader.

I suspect the obj-file loader in Irrlicht might need some rewrite. But I don't know which change without having more info. This might be a general problem with obj files, but I doubt it as the way the conversion was done seemed to have worked for others. And the parameter is called map_bump - so given that name it makes sense that Irrlicht expects a bump-map texture here and not a normal-map texture. So maybe it's one of those vendor specific things and we have to find out if the file was exported by 3ds max and then handle it different. Or it's one of the other parameters which tells this isn't a bump-map but a normal map. Or we need a custom parameter to pass through somehow so the user can decide it. Unfortunately pretty hard to figure out that kind of stuff with proprietary tools like 3ds max where we can't just look at the source-code. And also not having 3ds max I also can't just do a bunch of tests like I could with Blender. Tricky...

edit: Maybe you can help. Is it possible for you somehow to switch between bumpmapping and normalmapping in 3ds max? In that case you might export the same model twice - once with bump. and once with normalmap. And then we can compare the .mtl file to see if it writes some different information in there.

edit2: Sourceforge servers work a little better again today, so I could take a look at irrExt. There is a fbx loader, but it doesn't support many features yet (no animations for example). But if anyone wants to continue working on that it might be a good starting point: https://sourceforge.net/p/irrext/code/H ... oader/fbx/

[mongoose7]

The OBJ file loader is correct. It loads bump maps as bump maps. I don't think you can change definitions willy-nilly. Perhaps the OBJ format needs a new item for normal maps, but it still needs to support bump maps as such.

[Asimov]

Hi CuteAlien,

Will start by saying thanks for looking into this, it is much appreciated.

If you don't want to switch to svn trunk then you have to supply your own obj loader.

I am a novice with irrlicht and I am not sure what an svn trunk is, let alone use one.
As for writing a loader, there is more chance of an avalanche in the Jungle, at my level of programming heh heh.

There is no way to switch to a bumpmap in max. You see bumpmaps and normalmaps use the same slot.
When you load in a bumpmap it loads in on one level in the bumpmap slot. When you load in a normalmap you go down another level in the bumpmap slot
and select normalmap like the following picture shows.


However this is what I have tried. I loaded in any old bumpmap for test purposes. I didn't have a bumpmap to hand for this model, so I loaded in any old bumpmap I had lying about so that you could see the structure. The bumpmap is of a 2pence piece, but that is of no consequence.
Here is the link
http://www.asimoventerprises.co.uk/test/bumptest.zip

I have done two x models, with different exporters, and one obj just using a bumpmap.

It is strange that I can load the model into marmoset, and other engines, and I don't get that strange uv seam, but in irrlicht it does. However you have got it the closest so far, to how it is supposed to look.

[CuteAlien]

Irrlicht is an opensource engine. svn is the source-control system we are currently using (maybe you heard about git which is another source control system which is more often used by now. Every programmer should use some source-control system as it makes life so much easier). And trunk is the name of the folder with the latest Irrlicht version (most projects call it like that - don't know who started this kind of naming). To get them download the tortoise svn client (http://tortoisesvn.net/). Then you can check-out from svn servers by right-clicking folders in the windows-explorer and selecting check-out. It will ask for a server-address which is svn://svn.code.sf.net/p/irrlicht/code/trunk
Once you got the latest sources go into the source/Irrlicht folder and use one of the project files to rebuild Irrlicht and then you have the most current development version on your system.

And if you don't want that, you still don't have to write a loader from scratch, just do what I described in my post above. Copy the existing loader (COBJMeshFileLoader.cpp/.h), rename it and delete that single line with makeNormalMapTexture in it (just use any text-editor to search for that word). Then you have your own meshloader already which you can add to your project and tell Irrlicht to use with ISceneManager::addExternalMeshLoader. I can even post those files if you want, but you'll have to wait until I find time for it then (and I've already planned out this weekend for other stuff, so will be a little longer).

I'm not really familiar with normal-map implementations, but I think there are different ways to implement it. So it's no big surprise that data might work with one engine but not another. The uv-seams are more confusing. I don't think uv's themself are wrong - that is rather unlikely (they are just numbers - there's not much interpretation going on to my knowledge). So I rather would suspect it's maybe something like texture-border handling or so (like repeating when it should clip or similar - Irrlicht supports all kind of options, but maybe in this case expects that another one should be used). But again only something I could figure out by doing a bunch of tests - which is rather hard to do without access to the tool which creates those models.

I'll take a look at your new x model's later on (or next week). That's probably the way to go anyway if you need animations.

[Asimov]

Hi CuteAlien,

Anyway thanks for your time. This project I am doing on my own, but I am also in a team making a large open source world in Unity. Just built an island 2km by 2km. Started off with 100 million polygons and I baked down the model to 3000 polygons with normalmaps.

I am rusty at programming, but my 3D skills are excellent. However I can't show the island, because I would get shot LOL.

I think I am going to carry on with the stuff I can do and try to learn the stuff I can't as I go along.
I am surprised there hasn't been more posts on this forum about normalmaps I have seen a few irrlicht games which use them successfully, but I bet they are using shaders.
I have been searching the forum for days as well, and little comes of it heh heh.

I am going to try and see if there are any other exporters out there. So far I have used 3 different ones. I have two exporters for x, and one for obj, which is built into max.

[CuteAlien]

I think the Irrlicht normal-maps are also using Shaders.