irrRenderer 1.0

[ent1ty]

You were right, the normal map material for animated meshes wasn't working, like, at all. All fixed in the git repo now:


(excuse the poorly crafted normal map )

The glitches you're seeing on your mesh are due to non-infinite accuracy of the depth buffer I think, it uses some kinda quadratic/exponential scale, so as you get closer, the accuracy increases and as you get further, it decreases, producing more visible errors. What you can do about this is either increase the camera near plane value, decrease the far plane value; or fix your mesh (back-face culling and/or move the vertices further apart, best if you make the walls "real" 3d walls, not just planes). Anyone correct me on this if I'm wrong.

[user-r3]

Great commit, now it works

And looks awesome... well if I had nice normalmaps it would look awesome, but the effect is great

Thanks, I wish I had the skills to contribute to this project (in case you need help) as this is just epic imho

[user-r3]

Hello again,

after using your renderer for some time I've come up with some stuff, in case you think of further developing it. (And if you need help (as in: more people working on it) - write a tutorial for me (and possibly others) to fully understand your library and also understand your shaders )

- Should rendering to texture work? If yes I probably have to find out what to change
- Should shininess and other material settings have an influence on the output? If yes - they don't, if not, do you plan on adding this?
- Is antialiasing supported yet?

Thanks for any reply in advance
Sincerely

[ent1ty]

- Should rendering to texture work? If yes I probably have to find out what to change

Rather than creating and setting the render target texture yourself, you have to let irrRenderer do the work: http://www.fi.muni.cz/~xkrupick/irr/doc ... 977af08cf3 . Though I have to admit, I haven't tested this very much I think there should be a better way of handling this (on my end).

- Should shininess and other material settings have an influence on the output? If yes - they don't, if not, do you plan on adding this?

Indeed, shininess has no effect right now. All the material parameters you can change are described here: http://www.fi.muni.cz/~xkrupick/irr/doc ... rials.html . For example, Param1 affects the detail map repeat for the DetailMap material.

- Is antialiasing supported yet?

As with all deferred rendering pipelines, antialiasing has to be applied as a post-processing effect (FXAA etc.). As you can see, I dropped the post-processing from irrRenderer... so either use somebody else's post-processing, write your own, or wait an undisclosed amount of time for my post processing (seems to be the least advisable choice here / EDIT: ok i'm working on the post processing now, no promises though ).

[ent1ty]

Ok here is what i got: https://bitbucket.org/entity/irrpp

It's not very good right now, it does, however, come with a working FXAA effect:




More stuff, like bloom (that will require some more functionality on the C++ side), should follow in a bit

[clarks]

Do you need some help on this?

[ent1ty]

Well, if you could provide some interesting effects in the form of GLSL fragment shaders for me to include them in the 'preset' effects that ship with irrPP, just pm me or ping me in #irrlicht

I'm gonna get bloom working and then look into HDR and tone mapping and how all that would work together with irrRenderer

[devsh]

For non RLE blur (not compute shader)
https://www.buildaworld.net/forum/devel ... ssian-blur

in terms of HDR, we @ Build A World beyond repair cause we didnt use a proper movie quality algorithms for histogramming and tonemapping... I'd really recommend doing your proper research on the tonemapping and histogram pass in HDR (as in how you measure the colors in a scene and how to map from f16 or f32 RGB to 0-255 plus Bloom) because you can really gently caress up your white balance

[devsh]

two best approaches in the same paper
http://www.cg.tuwien.ac.at/research/pub ... HDR%20.pdf

personally a fan of adaptive logarithmic since it produces the most natural scenes (which might be contrary to your art direction)
http://www.mpi-inf.mpg.de/resources/tmo ... logmap.pdf

[ent1ty]

For non RLE blur (not compute shader)
https://www.buildaworld.net/forum/devel ... ssian-blur

Thanks, I did not know about the textureOffset function, really useful here... here is the result:





Obviously, it's a little strong... have I missed something in my implementation? I think I should at least make the kernel size larger. (you can find source here)


Thanks for those links, I've checked them out and they seem to provide a lot of information

[devsh]

You need a lot larger kernel, you need to downscale the image as well

then also you need to perform tonemapping BEFORE the blur and only blur the bright parts of the image

[ent1ty]

Ah, downscaling the render really was a good idea:




This is how the bloom effect is set up in code:

Code: Select all

    irr::video::CPostProcessingEffectChain* bloom = pp->createEffectChain();
    bloom->setKeepOriginalRender(true);
    // only let bright areas of the image through
    bloom->createEffect(video::EPE_BLOOM_PREPASS)->setQuality(video::EPQ_QUARTER);
    // blur them vertically
    bloom->createEffect(video::EPE_BLUR_V)->setQuality(video::EPQ_QUARTER);
    // blur horizontally
    bloom->createEffect(video::EPE_BLUR_H)->setQuality(video::EPQ_QUARTER);
    // add the blur onto the original render
    bloom->createEffect(video::EPE_ADD2)->addTextureToShader(bloom->getOriginalRender());

Ok... I feel like I need to stop hijacking my own thread now I'll make some online API docu and then post in a new thread...

[devsh]

You need to HISTOGRAM/Measure Luma in the whole scene (preferably avg and max)

then you need to apply the tonemapping operator on the brightness of the color (like x/(1+x) )
I use the following

Code: Select all

 
float luma = dot(color,vec3(0.229,0.597,0.114));
/**
reinhard reccommends to use: x*(1+x/w^2)/(1+x)
where x is the luma
and w is the value of x that will map to 1.0 {any x>w will map to more than 1.0}
**/
color *= pow(luma*(1+x/w^2)/(1+luma),1.0/2.2)/luma; //tonemapping and gamma correction in one
 

I choose w from the information about average luma of the scene (the brighter the scene the higher the w)
you can even get w froma 2D lookup texture (floating point obviously) based on avg luma and max luma as texture coords


then any color below 1.0 I turn to black on the blur RTT and make the glow that way, if you dont cut out the LDR colors then you blur the whole scene and make it look fuzzy and therefore loosing detail

[devsh]

Your normal mapping/deferred lighting can be quite poop because you store normals as 3x 8bit values (quantization error) and they dont occupy the whole [(0,0,0)-(255,255,255)] range available (all your possible normal ever will reside inside less than 2% of all the range)

read the Crytek presentation on deferred rendering in crysis from SIGGRAPH 2010 where they explain how they managed to use up 98% of the possible precision in the normal GBuffer

[prodcake]

I've been having some issues implementing this.

I had a look at the documentation and the example that you have on there comes up with an error with

Code: Select all

renderer->getMaterialSwapper()->swap();

saying that CMaterialSwapper doesn't have a member called swap.

I'm assuming the example there .. is out of date? I've been scouring the docs to figure out how to get past this. and i'm really short of ideas.
I'd love to use this renderer as I've got a little village i want to be lit up with lanterns etc etc.

any ideas?