irrRenderer 1.0

[ent1ty]

Hi, Been checking the shaders, and it was really instructive! There is a lot to learn there! I think it the first solid reference on GLSL shaders (on Irrlicht) I've seen since a very long time.
Will have to check how to update your normal shader to provide a spec map to it and it will be almost perfect for me.

Can the transparent_alpha shader can support partially transparent textures (like glass)?
I saw this in the code:

Code: Select all

if(color.a < 0.5) discard; //a transparent pixel

So it would discard pixel after they reach half transparency?

Partially transparent materials are available in the git repo on bitbucket (see the screenshot a few posts up about soft particles) but I want to improve a couple more things before an official binary release. What you're seeing right now is the transparent reference material, see the API documentation

[devsh]

Not while using it. That is against the standard, even if depth writes have been turned off, and only happens to work on nvidia.

So for things like soft particles you do need it separately.

let me call out bullshit, we have soft particles too! (but we leave the depth buffer unattached!)

so you never need to do a separate Zpass/write to another channel in a GBuffer

[hendu]

So your soft particles are slower, because you have to do a manual discard instead of using the fast Z-buffer hardware. Sure it's possible, but not necessarily smart.

[superpws]

Since I'm compiling it with current SVN Irrlicht, it didn't compile and gave those errors of deprecated functions. (wonder how would shaders work when passing parameters as index?). Anyway, good project. I'll wait for 1.9 support.

[ent1ty]

IIRC those are just warnings. Compiles fine here with trunk (the linux binaries in the zip archive were compiled with it btw)

[devsh]

I grab the depth buffer directly.. convert it to linear depth
then bind it with the color buffer
render particles (have both linear depth in a texture and depth buffer for early Z)

[user-r3]

Ahoy there,

I really like what I'm seeing right there, marvellous job (that I could never accomplish )

Anybody already got experiences on implementing in in a rather large irrlicht project?
May try this in the next couple of days (after making a backup^^), but I wanted to ask whether someony already did so?

Have a great day!

[superpws]

IIRC those are just warnings. Compiles fine here with trunk (the linux binaries in the zip archive were compiled with it btw)

Oh right, I had SDL checks enabled in Visual Studio project configuration which treats such warnings as errors. It compiles fine now. Just asking, what are the differences in your implementation of normal/Parallax mapping and irrlicht's implementation?

[hendu]

I grab the depth buffer directly.. convert it to linear depth
then bind it with the color buffer
render particles (have both linear depth in a texture and depth buffer for early Z)

Oh, I misunderstood you before. So actually we're just arguing whether to use MRT or to blit it.

With MRT you have some overdraw and more efficient write, with a blit no overdraw but it's an additional drawcall.

[ent1ty]

[...] what are the differences in your implementation of normal/Parallax mapping and irrlicht's implementation?

Well, you get infinite light sources (irrlicht normal/parallax has 2), an improved lighting algorithm ("logarithmic attenuation" edit: the axis labels appear to be on the other way around) and in the possibly foreseeable future dynamic shadows.

Anybody already got experiences on implementing in in a rather large irrlicht project?
May try this in the next couple of days (after making a backup^^), but I wanted to ask whether someony already did so?

All you need to do is call MaterialSwapper->swapMaterials() once your whole scene has been set up and you should be good to go.



Guys, any chance you could stop hijacking this thread

[user-r3]

Wow, thanks for the reply, that really is easy

After trying it, my first impression:

-looking good in general
-darker than vanilla rendering?
-easy per pixel lighting
-still no normal mapping for animated meshes? Well at least ppl

I may play around with it a bit more tomorrow/in the next couple of days.

Thanks again.

[ent1ty]

still no normal mapping for animated meshes? Well at least ppl

There is a normal map material for animated meshes, see http://www.fi.muni.cz/~xkrupick/irr/doc ... e22b4d2444

[user-r3]

There is a normal map material for animated meshes, see http://www.fi.muni.cz/~xkrupick/irr/doc ... e22b4d2444

Well... thanks, but in this case I have no idea how to use it...

I load the normalmap in the texturelayer 1 like this:

Code: Select all

node->setMaterialTexture(1, driver->getTexture("gfx/Normal.png"));
node->setMaterialType(Renderer->getMaterials()->NormalAnimated);

However, normalmapping does not work - it looks as flat as always :/
If I use the same normalmap for my level scenenodes (which usually use a different one^^) it works like a charm (without setting normalanimated as the material, this breaks the effect)

Also I've noticed some ...zbuffer-problems? Where I could see parts of meshes glitching through other parts covering them... I hope this is understandable.

Sincerely

[ent1ty]

I'll check on this, but the fact that the tangent is approximated (probably not in a completely mathematically correct fashion) in code should be kept in mind.

Also I've noticed some ...zbuffer-problems? Where I could see parts of meshes glitching through other parts covering them... I hope this is understandable.

Any screens? irrRenderer lets Irrlicht do the z-ordering and drawing from front to back. Could it be your mesh is messed up?

[user-r3]

I'll check on this, but the fact that the tangent is approximated (probably not in a completely mathematically correct fashion) in code should be kept in mind.

Thanks, if you could build a very simple example of irrRenderer, only with a cube or something, as an animated mesh, with a normal texture, maybe this could help either
show that it isn't working
or show how it is done correctly

Any screens? irrRenderer lets Irrlicht do the z-ordering and drawing from front to back. Could it be your mesh is messed up?

In order to not give away to much information about my project (Mr. Paranoid here) I've cropped some screens, so they only show the problem:
-Irrlicht vanilla shows it as it should be rendered (but with some strange normalmapping effects)
-I like your renderer more
-Yes, problems in my scene could be, I also wanted to switch to using a scene file instead of one huge mesh, when finally creating a nice level, or redoing my debug levels.


Thanks alot