ObjReader FBO & PP

[Patrice Terrier]

Is that what you want?

[Michael Lobko-Lobanovsky]

!!! PERFECT !!!

Thanks a bunch!

[Michael Lobko-Lobanovsky]

Good morning and have a nice day, my friend!

[Patrice Terrier]

I am sorry, but honestly that effect is not one i would like to use, except perhaps to create an image reflection on a sphere. 

[Michael Lobko-Lobanovsky]

Patrice,

We will discuss which post-processors exactly you'd like to see in the public build, and those that won't make it in there will be #ifdef MLL_DEV'ed out in our shaders.h sources.

[Michael Lobko-Lobanovsky]

I'm currently experimenting with real 3D DOF+bokeh post processing. Apart from the scene quad color texture, it requires concurrent creation of a scene depth texture and, consequently, one more MSAA renderbuffer blit into a non-AA FBO.

I can't yet make out correct positioning of my focal point in 3D space (see the picture below). But what I can already tell you is that the shader is going to be heavy despite renderbuffer blitting being blazing superfast as compared to ordinary slow glReadPixels(). The FPS rate drops 4 times lower than when rendered directly into an AA-unaware FBO.

This makes real time animation of complex models through genuine 3D, rather than fake 2D, post-processors highly problematic unless we abandon MSAA in favor of non-AA FBOs with much faster programmatic CSAA and/or FXAA shader solutions used in all modern professional 3D engines for similar reasons.

[Michael Lobko-Lobanovsky]

I'm stuck with depth-based PP. MSAA and related necessity to blit its render buffers into a non-AA FBO prior to being able to utilize the resultant scene textures are a severe bottleneck that puts a heavy load on the rendering pipe line and causes a dramatic drop in the OR FPS rate.

I think I should drop this activity for the time being and rather see what else I can do with simpler 2D effects -- including FXAA and CSAA shaders that may prove to be the key to much faster anti-aliasing without loss of quality in the viewport quad image.

[Michael Lobko-Lobanovsky]

My recent depth-based FBO experimentation has seriously broken my successful pipeline solution that I built when debugging FBO for W10/ATi compatibility. I'm not yet able to revert it to what it used to be; I'm lacking the necessary intermediate saves I should have done in the experimentation process.

I'm sad to admit it but it looks like the older I become, the more monkey work I'm forced to do...

[Patrice Terrier]

the older I become, the more monkey work I'm forced to do

That is the same for the old lemur here

However keeping our neurones at work is a good medecine to delay the deadline...

[Michael Lobko-Lobanovsky]

I'll be damned but I found the bug that was keeping me stuck for so long!

It was a seemingly very logical but actually very unfortunate glDisable(GL_TEXTURE_2D) in one of the draw lists that carried its bad side effect over into the next render frame!!!

Now I can finally resume my FBO WIP...

[Patrice Terrier]

I am glad you found it, that is a very good news!

[Michael Lobko-Lobanovsky]

[UPD]

1. FBO (default) doesn't render wireframe or point cloud. But since we can disable it (for backward compatibility) and still render them directly into gP.hGL, I'm just disabling Wireframe/Point cloud while FBO is on.

2. I've restored wallpaper renders in Wireframe/Point cloud modes "to please you"(c).

[Michael Lobko-Lobanovsky]

Another idea: what about moving both Wireframe and Point cloud over to the Renderer menu?

FYI I'm currently implementing PP shading options (vignette, bokeh, etc.) at the bottom of Renderer menu under a divider beneath the "fancy modes" group. Wireframe and Point cloud could go there too under their own divider...

[Michael Lobko-Lobanovsky]

Patrice,

1. GDImage.cpp, ZI_MakeMultipleTexture(...), line 8842:

// MLL: _MIPMAP_LINEAR cannot be used for _MAG_FILTER as per OpenGL Specs !!!
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR_MIPMAP_LINEAR GL_LINEAR);

OR's Mobj_makeMultipleTextures(...) does not have this bug.

2. I've suddenly realized that neither GDImage nor ObjReader use anisotropic texture correction. (see the floor below for what its effect looks like)

My suggestion is to use aniso = 8 because:

• It is almost as good as the best setting but according to comments on the net, 16 adds transparently yet some extra MSAA to MSAA's current best setting (defaults to 16 in ObjReader) and is therefore extremely heavy on the GPU.
• Apart from MSAA, we are also going to optionally use CSAA (nVidia only) and FXAA selectable from the menu. We do not want two different AA algos to be intermixed concurrently in one render. (aniso = 8 works in both CSAA and FXAA as is)

Do you agree with me here?

[Patrice Terrier]

I shall fix GDImage to use GL_LINEAR, thanks!

My suggestion is to use aniso = 8 because:

To say the truth i couldn't see any difference, just use the one that looks better to you.