Why do most Irrlicht3D Projekts look bad?

[rooly]

i'll say whats not fair, we dont' CARE how it looks. we like our engine with its easy defaults and its huge base of extensibility. And you just trot along trolling about everything ogre and piss people off. What's the name of this topic? "Why do most Irrlicht3d Projekts Look Bad?" The answer is simple to that: most of us are programmers, writing for fun and in a hurry. We make games for shits and giggles, and the visual aspect doesn't MATTER. You seem to instantly think that this auto-smoothing is instantly better...on what you call a cube. I can't name the last person i heard say a curved cube was better than a...regular cube. Off topic tho. The simple matter of fact is you need to stop trolling our forums to prove that ogre is better. If we believed it, we would be using ogre, now wouldn't we.

So, agi_shi, take a hint and go away.

[vermeer]

If someone else have thought I have been too sarcastic , I apologize to that someone else... (I think I've been even patient...)

agi_shi : All your proof is based on just a default of not being of your preference. Making a game (and I have made and ended a lot, not with irrlicht as in-house are usually company made engines, or whatever) has a zillion more other issues than if by default the engine gives some sort of autosmooth or not. Seems you yet didn't understand (while I took my time to explain ) that this 'default' is simply something irrelevant, as good art, is only made if the artist control the normals, is a default to be overridden, so that default autosmooth given by the engine isnt by far what needs to remain, but instead, the smoothings carefully made by the artist or team of artists. Other thing would be crazy, unless your modeler guy took the care and time of building everything aimimg to a autosmooth angle threshold,(he'd also have that autosmooth value in viewport) which is very possible and I have also done, so that that auto default value, would work in any raw mesh. But is largely less flexible and in the end is less quality and slowing a lot the procedure.And many buddies don't know how to do this.

What i don't understand is one point. You don't listen... You have already said to your self which is the best engine, you don't really care on any other engine (so, you're loosing many good options) You've made up your mind way before making any test. And get disappointed just by a default, not making analysis of way more important aspects of a game engine...

well, whatever.

[Saturn]

What is this "autosmooth"-thingy everyone is talking about? Isn't is just that per default Ogre sets renderstate to use gouraud shading, while Irrlicht defaults to flat? (does it?) Ogre definitely doesn't do anything beyond that. Vertices with position, normal, uvs and whatever are put into a buffer, buffer is rendered, no on-the-fly normal modification.

[hybrid]

Well, the .obj file has per face normals stored. This is although the file could handle per vertex normals, but these are simply not used - all three normals indices refer to the same normal, i.e. face normals.
However, the Ogre render showed smoothed per vertex normals. Since agi_shi said both screens use the same object the only chance would be that Ogre uses auto-smoothing (averaging) of the normals per vertex. If it doesn't than it's obviously he was cheating.

[Dorth]

Aya... If any thread had degenerated like this on one of my forums, it'd be long closed. Why keep it up? I'd say not a single person reading this thread doesn't already have an opinion on whether or not Irrlicht is capable of graphics as good as Ogre or even better and how easy those aspects could be put in place. agi_shi is by all definition a troll, may it be stirring trouble, foul language, insults, hijacking of threads, etc. Just ban his ip/account and be done with that. My company chose Irrlicht over Ogre because of price, stability, ease of use, size, and development speed. That was our choice to make. You can now make your own for your engine of choice, all of you. And let this thread DIE so we can start talking about either ongoing development, projects, bugs, features, etc.

[Saturn]

Since agi_shi said both screens use the same object the only chance would be that Ogre uses auto-smoothing (averaging) of the normals per vertex. If it doesn't than it's obviously he was cheating.

I am very familiar with Ogre source and I am sure Ogre does no such thing. Whatever the difference, Ogre does not manipulate/average normals in any way other than by changing render states. (flat shading, gouraud shading, shaders)
This is kinda interesting, "cheating" in this context is so pointless, I don't believe agi_shi, as annoying as this thread got, did anything in this regard. But inadvertent mistake is an option.

[omaremad]

Ok lets look at a nice analogy. People do crimes, they go to jail. People learn whats good and whats bad and make free willed descisions.

Now with our engines here people study both engines by looking at the websites, then they choose the engine that is suitable for the desired effect. right now im coding for an embedded system i dont need to port irrlicht or ogre, they are not suited to the task; they are not my religion .

We dont need people to educate us all the time. If we are too stupid, ignorant, lazy to do proper reading on both engines and chose the wrong one for our needs we should suffer the consequences of our actions...( ie: go to jail)

We dont need a nagger to tell us our sins, that only wastes time on both sides.

btw blender has z as the up axis, maybe some exporter doesnt swap the y and z normal components right?

Looks depend on the default material settings for each engine and once again the desired effect. phong with loads of spec highlights sure looks cool, but it doesnt suit peoples faces / clothing. What im saying is that people dont make good looking games uisng default settings, good looking games are good because people:

1- understand what makes things look good (knowldge in phyics, architecture, art, photography, lighting and camera direction).

2- spend effort into what they are making.

3- understand that no default scheme can make everything look good, every implementation has strengths and weaknesses

Smoothing is a very wide area. I hate it when people can think a computer alogrithm that makes sooooo many assumptions (and so little inputs) can understand your model and produce normals like a real object when your input geometery is so far from approximating that object. (this is where high -> low poly bakes come in) which guess what... has nothing to do with ogre or irrlicht.

Tbh if you dont input artistic talent your game will look bad no matter what (even if you go for abstract styles like cubes and wire frames) wrong application of lighting and mismatching colours will still make bad graphics even if you use something like unreal 3 ( look at the art quality spectrumn found in games using ue3).

[omaremad]

opps looks like vermeer already said what i wanted to say...

[BlindSide]

Whoa dude your coding for an embedded system? Tell me more!

[hybrid]

But inadvertent mistake is an option.

If one makes such an error even after the third time he is told about then it's merely ignorance (and if this comes with an intention I'd call it cheating).

[vermeer]

opps looks like vermeer already said what i wanted to say...

No worries, is great that smeone else had this knowledge also

With a default shader, no way...You are modelling a human feace....you'll want slight creases here and there...An axe....You'll in Wings or Maya your hard edge (or in blender, break in there...) so to get the "sharp" look...Modelling an space ship....I bet you'll want to control where a sharp edge appears, and when not, instead of trusting an autosmooth...Well, as I said , is such a basic art thingie.

Is not bad this thread has get so long if a point wwas cleared...(actually, 2, points...the other is soooo clear , I wont mention, lol )

Btw, nice point that of the Z axe prob could affect normals...am not a coder and couldnt guess that...I know since allways, usual softwares like wings (the obj I uploaded was made with wings) tend to have Y up, as vertical axe, while in Blender, is Z. Many weighted animated models have probs with this.But usuallys is a fdeature added to exporter and prob gone.

[noone88]

the question is: DOES ogre use autosmoothing? If not, then both scenes should look equal. Right?

[Saturn]

the question is: DOES ogre use autosmoothing?

No, it doesn't.

[alexionne]

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!

Just a simple question: Do you know how to achieve both "bad-looking-Irrlicht" and "good-looking-Ogre" screenshots in both engines? Hint: Do you know what are technical differences between smoothed and non-smoothed objects?

Both of your screenshots can be made in both Irrlicht and Ogre, and if you know to read documentation, and if you understand what "smoothing of normals" is, it is matter of minutes to have all 4 screenshots.

If you can't do that, than:

A. You need to learn more about 3D.
B. You are lazy to learn.
C. You don't want to do it.
D. You are stubborn.

1,000,000$ question is: A, B, C or D?

[white tiger]

I totally agree with Saturn.

Recently I wrote a phong cg shader for Ogre (per pixel point light). In the Ogre SDK there are many models in the mesh format, and the related materials already written

with ninja.mesh (wich has not smoothed normals, I suppose) my shader looks bad. The lighting switch from totally bright to totally dark. With ogrehead.mesh (wich has smoothed normals) it works perferctly.

So Ogre doesn't calculate smoothed normals in real time. Simply the 3ds max Ogre exporter export smoothed normals. The ninja.mesh was probabily exported with another program

And i suppose no real time 3d engine calculate normals, preferring to load 'em from the 3d model

Of course the difference is visible with fixed pipeline lighting, but less visible since it's per vertex lighting