Irrlicht Engine

Hi All,

Recently I've been acting as consultant to a private company in process of selecting a 3d rendering engine for a major commercial product.

From my own past experience, I see that Irrlicht can mostly satisfy all their requirements, with one major exception, something I personally have never managed to get working smoothely: normal-maps!

All of you out there, I just need to know one thing: is there a smooth pipeline from 3dsMax to Irrlicht? Is there any format, which can be used to apply normal-maps in 3dsMax->Export->Load in Irrlicht and it would work?

What I DONT want to do is:

1. Convert my mesh to tangent-mesh manually. Is there a loader in Irrlich capable of loading tangent/bi-normal information directly from file formats that can encode this info at export, such as Collada?

2. Setup a material-type (such as EMT_NORMAL_MAP) "after" loading the mesh. Since the information is *already* in the file the loader should be intelligent enough to load the normalmap and setup appropriate material type.

Does anyone know of such a loader or other way to achieve such functionality in Irrlich?

I'd hugely appreciate some urgent help/hints.

/regards

I'm not sure how far the support in Collada is implemented, but .3ds and .obj can both properly load normal mapped meshes and keep those settings correctly.

hybrid wrote:I'm not sure how far the support in Collada is implemented, but .3ds and .obj can both properly load normal mapped meshes and keep those settings correctly.

Hello hybrid, are you really sure about this? I remember having this same discussion a while ago and no matter how I tried it didn't work.

Moreover, as far as I know .3ds format does not contain tangent/bi-normal information and thus you are forced to manually convert your mesh to tangetmesh. That simply doesn't work for me cause we'd be loading huge number of models never knowing which ones have normal-mapping applied, so the loader will have to read this info from inside the mesh file and convert the corresponding mesh to tangentmesh.

EDIT: moreover, the 8.3 naming convention limit for .3ds is incredibly annoying and impracticle for their 3dsMax artists, so for all practical purposes, .3ds is out.

xirtamatrix wrote: What I DONT want to do is:

1. Convert my mesh to tangent-mesh manually. Is there a loader in Irrlich capable of loading tangent/bi-normal information directly from file formats that can encode this info at export, such as Collada?

2. Setup a material-type (such as EMT_NORMAL_MAP) "after" loading the mesh. Since the information is *already* in the file the loader should be intelligent enough to load the normalmap and setup appropriate material type.

1. This take exactly one line of code. Why aren't you willing to do this?
2. This also takes exactly one line of code. Also, if you/your clients use any custom shaders at all (which I assume they will), you'll be manually setting the material type anyways.

slavik262 wrote:

1. This take exactly one line of code. Why aren't you willing to do this?

What are you suggesting? That when loading a huge number of meshes I blindly convert each and every mesh to tangentmesh regardles whether any normalmapping was applied to it or not?

slavik262 wrote:

1. This also takes exactly one line of code. Also, if you/your clients use any custom shaders at all (which I assume they will), you'll be manually setting the material type anyways.

Why do you assume that? It is far more important for them to have a fast and efficient content-creation pipeline, which means artists create meshes and apply materials with 3dsMax, export them into a desired format, and pass them over to the development department for testing in the engine.

When projects want to use custom shaders, they usually create a middle-ware World-Editor kind of application which loads the standard meshes exported by art department, applys custom material settings and exports out into some custom format with some tags about what material should be applied to which mesh/polygons. The code can then check for those tags and manually set the materials.

So, what I'm pointing out here is a simple thing to understand, that normal-mapping is a very very common thing and many major exporters of file-formats already encode normal-mapping information, such as the OpenCollada exporter for 3dsMax AND it also encodes tangent/binormal information. So Irrlicht's Collada loader could therefore very simply read that information from the file, change the mesh to tangentmesh and set the material type to EMT_NORMAL_MAP without any need on the part of application to do it manually.

Hope this explains.

xirtamatrix wrote:So Irrlicht's Collada loader could therefore very simply read that information from the file, [...]

Knock yourself out, and don't forget to submit a patch.

xirtamatrix wrote:

slavik262 wrote:

1. This take exactly one line of code. Why aren't you willing to do this?

What are you suggesting? That when loading a huge number of meshes I blindly convert each and every mesh to tangentmesh regardles whether any normalmapping was applied to it or not?

No, I was merely pointing out that it's incredibly simple.

xirtamatrix wrote:

slavik262 wrote:

1. This also takes exactly one line of code. Also, if you/your clients use any custom shaders at all (which I assume they will), you'll be manually setting the material type anyways.

Why do you assume that? It is far more important for them to have a fast and efficient content-creation pipeline, which means artists create meshes and apply materials with 3dsMax, export them into a desired format, and pass them over to the development department for testing in the engine.

When projects want to use custom shaders, they usually create a middle-ware World-Editor kind of application which loads the standard meshes exported by art department, applys custom material settings and exports out into some custom format with some tags about what material should be applied to which mesh/polygons. The code can then check for those tags and manually set the materials.
Hope this explains.

Shaders go beyond simply setting custom material settings. Regardless of any material settings you set in some editor, those are just the parameters. You still do have to write and load the actual shader program into Irrlicht.

It sounds like you'll want to tweak the mesh loader(s) you want to use.

Ok, I thought you only want to avoid the manual call to convert2Tangents. Because this is automatically made by the loader for you, with the proper material settings being made. Though, both formats don't store tangent information.
Collada seems to have a way to store it. It's not implemented in the loader, though. a fix might be not too troublesome, but needs some changes in the basic mesh structures of the loader.

hybrid wrote: Collada seems to have a way to store it. It's not implemented in the loader, though. a fix might be not too troublesome, but needs some changes in the basic mesh structures of the loader.

I'm not good with loaders myself but if its do-able I strongly reccommend implementing this. What this provides for serious projects is a streamlined content-creation pipeline from 3dsMax to Irrlicht without needing a middle-man World Editor application. ( since normal-mapping is now such a widely-used feature)

The other way around this is of course to build/provide a very good World Editor app. I have tested IrrEdit/CopperCube but unfortunately at moment it leaves much to be desired and not comparable to WorldEditors bundled with engines like Torque, C4, Unity etc. not to mention the high-end engines like Unreal, GameBryo, CryEngine etc.

I could in theory offer my client use of Irrlicht after having built a decent WorldEditor but that means longer dvelopment time and at moment they seem to be leaning more towards Torque. Well, pity.

/regards

Ты ведешь себя так, как будто тебе кто-то тут должен....
Ирка - бесплатный движок+ открытый код...
Возьми, да допиши, что тебе не хватает.....

Sorry ))
P.s. Strange, that you did not mention OGRE

If a company is going to use Irrlicht for a major commercial product (as opposed to just a regular commercial product...), then they are not very smart. Irrlicht still has a lot of bugs (see here for one example-- http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=40162)

I'm not demanding that Irrlicht is made perfect immediately, but that's the thing. It's free. If you are going to be making a multi-million dollar game (a "major commercial product"), you should be spending a ton of money into making or buying a flawless engine instead of standing on the street corner and asking for handouts.

Bear_130278 wrote:Ты ведешь себя так, как будто тебе кто-то тут должен....
Ирка - бесплатный движок+ открытый код...
Возьми, да допиши, что тебе не хватает.....

Sorry ))
P.s. Strange, that you did not mention OGRE

Sorry, dont speak Russian. We evaluated 21 engines, Ogre included, but no it did not make it to the finals.

Out of curiosity, what features does irrlicht have that those 21 engines don't?

agamemnus wrote:If a company is going to use Irrlicht for a major commercial product (as opposed to just a regular commercial product...), then they are not very smart. Irrlicht still has a lot of bugs (see here for one example-- http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=40162)

I'm not demanding that Irrlicht is made perfect immediately, but that's the thing. It's free. If you are going to be making a multi-million dollar game (a "major commercial product"), you should be spending a ton of money into making or buying a flawless engine instead of standing on the street corner and asking for handouts.

No need to be sarcastic! I wrote "major" because the product is already existing with over a few million users, but built many years ago on a custom now out-dated engine. Our target now is to totally replace the old engine with something new and powerful.

Moreover, while Irrlicht would probably not be used for that project, I totally dont agree with your opinion. Tons of commericial apps/games have been developed on open-source engines, including Irrlicht. I myself have another project being developed on Irrlicht and have not found any irrecoverable bugs so far. OFcourse, you have to tweak the engine to suit the requirements of your particular app/game.

Its true though that developing on open-source requires much more time and deeper knowledge.

Adler1337 wrote:Out of curiosity, what features does irrlicht have that those 21 engines don't?

That question should really be "what features does an engine with half million price tag has which Irrlicht dont and how many development hours would be require to add those features"

cheers!