Why do most Irrlicht3D Projekts look bad?

DarkWood_Neo · Post by **DarkWood_Neo** » Sat Aug 04, 2007 9:38 pm

[Deutscher "Orginaltext" weiter unten]

Why do most Irrlicht3D Projekts look bad?

For a few years I'm studying several Irrlicht Projects. I'm fascinated by it's easy implementation and usage, which although doesn't restrict the programmer. So I started different projects using the fast developing engine.
In times without own projects I follow the evolving engine and since today I vistit the “Project Announcement” Forum frequently and regularly, to keep an eye on promising works.
Recently I see many Projects with extremely bad graphics. At first, I put it down as typical for programmers, who focus more on their code than on their graphics. But if one takes a look at other engines (e.g. Ogre3D) one can see that they don't deal with such problems.
Following I am neither going to analyse the inability to make good graphics of some programmers nor I'm willing to show technical weakness of Irrlicht3D. I rather want to state my these about the cause of these bad screenshots.
Maybe good projects aren't announced in the forum but if one analyzes several game project in the (german) game-dev scene one cannot find any projects with good graphics that uses the Irrlicht Engine.
Irrlicht Engine offeres easy to use functions to implement simple applications. It is easy to write code to load models, textures, and to create materials to everyone who is roughly familiar with C++. That is which makes Irrlicht so special, but to developers who are interested in the API it is deterrent. Hence an image of the engine develops which doesn't make the grade.
That makes me sad, since the Irrlicht3D engine is a powerful API. With this text, I want to encourage developers to take care of their screenshots and to contribute to these wonderful Open-Source Engine.

----------------- German original text -------------------

Warum sehen die meißten Irrlicht Projekte schlecht aus?

Seit einigen Jahren verfolge ich nun schon die Irrlicht-Szene. Selbst begeistert von ihrer einfachen Implementierung, die dennoch meinen Ideen keine Grenzen setzt, begann ich zahlreiche Projekte, die immer wieder auf die sich rapide entwickelnde Engine zurückgriffen.
In Zeiten ohne eigene Projekte verfolgte ich die Entwicklung der Engine und bis heute schau ich regelmäßig neugierig in das “Project Announcement” Forum, um vielversprechende Arbeiten im Auge zu behalten.
Mittlerweile fallen mir immer wieder Screenshots ins Auge, die unglaublich schlechte Grafiken zeigen. Zunächst stempelte ich dieses Problem als typische Programmiererkrankheit ab: Viele Projekte verfügen über keine Grafiker. Doch wenn ich andere Engines betrachte (z.B. Ogre3D) sehe ich, dass es eben auch anders gehen kann.
Was ich im folgenden analysieren möchte, ist nicht die Unfähigkeit vieler Programmierer gute Grafiken zu erstellen (warum auch?), sondern warum gerade die Irrlicht Engine über so wenige (keine?) Vorzeigewerke verfügt.
Vielleicht werden die richtig guten Projekte auch nicht im Forum bekannt gegeben. Oder der Engine fehlen die technischen Vorraussetzungen. Beide Möglichkeiten schließe ich aus, da ich zum einen auch in der sonstigen (deutschen) Szene keine Spiele vorfinde, die mit der Irrlicht Engine arbeiten und dennoch gute Grafik vorweisen und des Weiteren da ich aus eigener Erfahrung keine Beschränkungen der Engine erkennen kann, über die andere nicht auch verfügen.
Meine These ist vielmehr, dass es gerade die Einfachheit der API ist. Eine Anwendung zu implementieren ist relativ schnell erledigt. Modells, Texturen usw. sind schnell geladen und so kann jeder, der halbwegs mit C++ umgehen kann, eine Anwendung schreiben. Genau das ist ja das schöne an der Engine. Doch Interessenten, die eigentlich die Engine nutzen möchten, werden von der schlechten Grafik förmlich abgeschreckt. So entwickelt sich langsam ein Image, dass der Qualität der Engine nicht gerecht wird. Das ist schade und so möchte ich dazu anregen, mehr auf die ästhetische Qualität der Screenshots zu achten, um die großartige Qualität der Engine unter Beweiß zu stellen, über die sie zweifelslos verfügt.

bitplane · Post by **bitplane** » Sat Aug 04, 2007 10:09 pm

I think we're mostly just programmers having fun. The majority of people aren't working on serious projects, they're not artists, and they don't have the kind of huge goals that attract good artists to their projects.

Making good artwork takes a long time and a lot of practice, so my game projects are always going to have unimpressive artwork. That's okay though because I like the home-made look, and only goals are to have fun making it, and for it to be fun to play.

That's my excuse anyway

GameDude · Post by **GameDude** » Sat Aug 04, 2007 10:57 pm

Like bitplane said most people here are just hobbyists who make small creations in their spare time, there are however some people are using the Irrlicht for commerical products, there is CakeWalk that I know of and a few others.

agi_shi · Post by **agi_shi** » Sun Aug 05, 2007 1:47 pm

It's all about shaders bay, all about shaders...

Seriously, add in some pretty lighting and ANYTHING looks good

omaremad · Post by **omaremad** » Sun Aug 05, 2007 1:59 pm

Yes the lack of shaders but also the lack of good art, art + a properly tesselated fixed function scene,nice fixed function postprocessing, with the right lighting, fog, material properties and texgen matrix effects can be very beautiful.

The trend of slapping on shaders on everything has led to the plastic look common in most of todays games.

Zeuss · Post by **Zeuss** » Sun Aug 05, 2007 2:07 pm

I think I have to agree with DarkWood_Neo on this point.

I think a lot of models do like Worse in Irrlicht then it does in other engines.

This has brought back something I was planning on. Was a comparing set of engines, same model, same single point light. Same camera locations and targets.

Although, I think some of it is more to do with model format, having bad smoothing groups and things rather than a problem with Irrlicht itself.

The terrain and BSPs look just as good as other engines. I think it may be peoples mesh format, like .3ds and .obj I have noticed seem to have really sucky smoothing groups, and make models look really faceted.

Luke · Post by **Luke** » Sun Aug 05, 2007 2:20 pm

yeah I'd say it's the smoothing groups in the model format,

a mesh with a simple point light should look exactly the same in all engines.

vermeer · Post by **vermeer** » Sun Aug 05, 2007 9:59 pm

I dunno if there's some loss in the way texture displays, but could be an impression of mine...Always had that doubt...

irrlicht supports well smoothing normals at least from 0.7, surely from much before.When I was doing tests and help for oct andmim format, was my main cry for murphy for having mim instead of oct, as oct didnt support smoothing normals , while mim and obj did, and quite well. vertex normals, at least, and is easy to convert to vertex normals . (artist "talks" ,I know technically internal stuff is another beast.)

FSrad did an outstanding work on producing small and eficient lightmaps partitioning, the main issue was it didnt support smoothing normals, so anyway, all 'd look weird after lightmapping...and solving that in fsrad code wasnt trivial.

yep, is a matter of format. Seems b3d tho, supports well smoothing normals, I mean , it does support in any engine: looks like here also.

One issue I thought was format related in b3d, was actual limit in B3d engine, not format: dx7 related code didnt support certain sort of interpolation...wether here the engine can over come that or if, which I think I remember, simply forces a keyframe per frame, the IPO curves (interpolation bewteen frames, key thing in natural walk cycles) will be traslated from blender...

hybrid · Post by **hybrid** » Sun Aug 05, 2007 10:29 pm

3ds is the only format that does not support smoothed normals in Irrlicht, although the format does. md2 does not have smoothed normals in the format, so no way for Irrlicht.

vermeer · Post by **vermeer** » Sun Aug 05, 2007 11:28 pm

-indeed, 3ds does them, but wrongly in certain common situation: when there's a vertice with 2 UVs, it breaks smoothing there, as generates to vertices...at least that happens when saving as 3ds in any 3d tool..- Ie: a cilinder in the starting/ending vertical.

BlindSide · Post by **BlindSide** » Mon Aug 06, 2007 6:16 am

hybrid wrote:3ds is the only format that does not support smoothed normals in Irrlicht, although the format does. md2 does not have smoothed normals in the format, so no way for Irrlicht.

Isn't it possible to generate these at runtime? Not a fully accurate version but something similar to Blender's "Ctrl-N". Does this have any relevance to the recalculateNormals material flag?

hybrid · Post by **hybrid** » Mon Aug 06, 2007 8:18 am

You mean NormalizeNormals? This is just for a renormalization step before taking the normal into account. Quite useful after scaling a mesh, because normals are scaled as well. Enabling the flag renormalizes on the GPU instead of doing it on the CPU.
There is also a method for recalculating normals, but the results are not as expected: You have everything smoothed, even at former sharp edges. It's even worse for 3ds because we do not split the mesh buffers, yet. So even more edges are lost.

Dorth · Post by **Dorth** » Mon Aug 06, 2007 5:33 pm

btw, WHY are the normals scaled too? Couldn't we not pass those in the matrice? I'd imagine they'd be stored in a way that makes it easy to differentiate them from the rest, no?

hybrid · Post by **hybrid** » Mon Aug 06, 2007 9:05 pm

No, vertices are transformed using the transformation matrix. This is, e.g., necessary for a proper rotation. And this also holds for the normal. Unfortunately, rotation and scale are applied at the same time, hence no chance to avoid it. there are some situations where you can simplify the normalisation, but no general way.

dawasw · Post by **dawasw** » Mon Aug 06, 2007 9:36 pm

Maybe it is also in cause of haste. A lot people program stuff and don't care about graphical concepts etc.