Why do most Irrlicht3D Projekts look bad?

[Cardinal4]

The comparison agi_shi made was to highlight a probable problem with Irrlicht's smoothing or normals [or something ], and possibly improve it. Though that went downhill fast.

[hybrid]

I promise to look at the 3ds groups sometimes. But there's definitely no render problem in Irrlicht if the normals are properly set. And that's what we always said. Of course this is also the reason why the 3ds->ogre mesh is correctly working in Irrlicht - Ogre does 3ds smoothing and exports it, Irrlicht can read the normals from .mesh files and displays them correctly.
Edit: I know why the .obj file renders badly: the normals in the file are per-face, so that's definitely a point for Irrlicht and not for Ogre. The file contains the normals, i.e. the render engine is not meant to change them unless explicitly asked for...
So let's just take this thread as a reminder to avoid engine comparisons without good reason or without enough knowledge about how such a benchmark could be done. And please avoid to post 'Why Irrlicht is better' threads in other engine's forums

[agi_shi]

Guys, you said "the same scene should look EXACTLY the same in all engines". That's all I did. Don't see what you're arguing about.

One more thing - the exporter shouldn't be smoothing anything. It creates raw vertex data via the 3DS and then uses the MeshSerialiser to save it (as a mesh). There shouldn't be any "smoothing".

Also - is Irrlicht 1.3.1 supposed to have a .mesh loader? I tried to use that instead of the 3DS/x/OBJ, but it told me it's an unrecognized format =/

[xDan]

Irrlicht definitely has a better name!

[hybrid]

Irrlicht 1.3.1 can only load .mesh version 1.30 while the next release will also load version 1.40. You just have to change the version number in the file to make it load in 1.3.1 as well.
The exporter is not smoothing the .obj normals, but the .mesh normals are smoothed. So one of the two meshes is wrong. But since you tried to get smooth shading across the object I assumed that the normals should be smoothed. However, since the .obj contains face normals and not vertex normals, the object should not be smoothed in any engine. That's why I was telling you.
and of course the scene will look exactly the same if you take the same parameters for both engines. In case Ogre does normal smoothing by default you have to either disable it there, or enable it in Irrlicht. Otherwise you get different results.

[agi_shi]

and of course the scene will look exactly the same if you take the same parameters for both engines. In case Ogre does normal smoothing by default you have to either disable it there, or enable it in Irrlicht. Otherwise you get different results.

Yeah, except were were talking about a default scene. I thought Irrlicht was the "extremely novice-friendly and 1-liner, no need to configure anything"-type, not Ogre?

[hybrid]

Yeah, that's why it displays the object corectly, while Ogre enables smoothing.

[agi_shi]

Yeah, that's why it displays the object corectly, while Ogre enables smoothing.

Ogre displays it correctly, too, and smooths it as well. Smooth looks a lot better than flat, Ogre wins.

[Saturn]

Yeah, that's why it displays the object corectly, while Ogre enables smoothing.

Ogre displays it correctly, too, and smooths it as well. Smooth looks a lot better than flat, Ogre wins.

Oh man. Yeah, if it makes you happy, you win. So I guess this means you can stop now making a jerk of yourself.

[vermeer]

Ogre displays it correctly, too, and smooths it as well. Smooth looks a lot better than flat, Ogre wins.

It's clear, you analized a cube...

Seems like your normals are more fucked then mine

No.

(still, I apreciate the richness of your vocabulary)

The obj I passed you has vertex normals. There might be some problems in how it is reading them, or what you did to them, but dont tell an artist if he's not exporting smoothing normals... Yeah, you have there inverted normals. This and applying smoothing is ABC for any coder I've worked with...in any engine. I would have laughed strongly if had been mailed back with this..."issues"...a customer is a very different thing, though..if he/she says his/her Pc is flying, I first say they're true, and then patiently demonstrate the opposite...

An obj, one of the so many advantages over *.3ds (you'll end up learning that among so many other things) is an ascii file. read it, as vn 0.70434638 0.70434673 -8.8271531e-2 means that it has vertex normals...

Is so freaking common to see that engine inverted normals, or did the exporter, or the package, and some half a second in fixing in code or tool, that for any average noob is dumb easy...

of THOSE exports, in fact, it's a direct .3ds -> .mesh conversion.

keep using *.3ds files...till you see the light... :p

It creates raw vertex data via the 3DS and then uses the MeshSerialiser to save it (as a mesh). There shouldn't be any "smoothing".

So wrong again I don't even know why I do have this patience...young ppl some years ago were different... The fact is there MUST be smoothing..Why? simple and essential. In games, the artist need to control very accurately how those few plygons are going to shade and be lit. Where smoothing creases are placed, and how it's used on artists work advantage, often make the difference between an at least decent artist and a crappy one. bad choice of those creases with sure will ruin any artwork. Is one of the keys of real time 3d graphics.

A pitty that *.3ds files put it so darn poor to the artist...as Uvs need to be done so that uv seams do match the smoothing creases,(or hide the uv limits in unseen areas, also a bad thing) doing a work thousand times harder, and limited, where all could be solved knowing there exists something called obj, collada, cal3d, b3d, md5, and a very large etc.

[BlindSide]

Hey I am sure someone here could personally run a fair trial and prove you wrong. But we're all too stupid to use OGRE

[Nodtveidt]

Please kids, don't feed the Ogres. Or the Trolls.

[deesine]

I think you guys have strayed a tad off topic.

On topic though, the fact that the examples/projects might not look so pretty could have something to do with the programmer-centric community I'm probably one of very few artists-per-se that are active here.

[agi_shi]

Hey I am sure someone here could personally run a fair trial and prove you wrong. But we're all too stupid to use OGRE

I DON'T GET WHAT THE gently caress WASN'T FAIR. Guys, we said the SAME SCENE. THAT'S WHAT I DID. Export for Irrlicht, export the same thing for Ogre. Load it in Ogre, load it in Irrlicht. Take screenshot, report. You guys just can't admit that it looks better in Ogre by default so you're getting off track about normals, "correctness", etc. My goodness!

I mean... seriously. It looks better in Ogre by default. Accept it. Big funking deal - I exported equally for both engines.

EDIT: Heh, very funny forum...

[Nodtveidt]

Coders aren't visual artists, our art is our code.