Animated Backgrounds?

[Michael Lobko-Lobanovsky]

Cool!

[Michael Lobko-Lobanovsky]

Re. Reply #156 on: December 28,

Patrice,

I do not know what you are talking about. It's been years since PPL became OR's default rendering pipeline, and its Blinn-Phong shader (the one that draws some mesh materials that don't use bumpmaps while other meshes do) is the shader that displays your illum 3 reflections, both"ambient" (wallpapered) and local (refl'ed in a specific material). And Use fixed pipeline, which is OR's prehistoric immediate-mode pipeline, stays unchecked at all times unless it comes across a mammoth-aged model that never used a single bumpmap in any of its materials.

PPL reflections are drawn with better quality than FFP ones, and they have smoother surfaces and superior, more uniform lighting. I cannot understand why you keep on clutching onto that deprecated pipeline. Gimme just one single example of a model that would need it to be rendered at least as good as it is rendered in PPL. Alas, you Planar and Chromosaurus both fail that simple comparison.

[Patrice Terrier]

Yes i am speaking of
the one that draws some mesh materials that don't use bumpmaps while other meshes do
using illum 3 or illum 4

Try using only this material with planar.

And add a zTrace into the FFP and PPL.

#multilight
#wallpaper @sanctuary.fs
#alphatocoverage
#playaudio Uncertain-Future.mp3 50 loop

newmtl planar
#rotate 0.15 0 1 0
Ka 1 1 1
Kd 1 1 1
Ks 3.5 2.5 2.5
Ns 512
d 0.9
illum 3
refl smoke.png

Then you will see that it is rendered into the drawUsingFixedFunctionPipeline

if you add this to force PPL

#multilight
#wallpaper @sanctuary.fs
#alphatocoverage
#playaudio Uncertain-Future.mp3 50 loop

newmtl planar
#rotate 0.15 0 1 0
Ka 1 1 1
Kd 1 1 1
Ks 3.5 2.5 2.5
map_bump neutral_bump.png
Ns 512
d 0.9
illum 3
refl smoke.png

Then it is rendered into the drawUsingProgrammablePipeline
loosing the reflection, even changing the other un-orthodoxe settings being used (shown in blue).
So far i am unable to recreate the same effects in PPL than in FFP.

illum 3 and illum 4, are currently not working in PPL mode, that was my point.

Added:
More exactly, it works in PPL mode, ONLY, if using the menu "Render" then "Ambient reflection".
The gP.bSpecular flag seems to be enabled only when the menu is used, while it should be set also from the materail file.
Investigating...

[Michael Lobko-Lobanovsky]

No, you are not correct, my friend!

If halo-less planar.obj is loaded without the bumpmap, it is rendered by FFP on default (menu is checked). But if you uncheck the menu to force PPL, FFP is cancelled, and the figure and cylinder are rendered by PPL's upper part that is called the Blinn-Phong shader. It comes in the drawUsingProgrammablePipeline() under this condition:

........
            // 12-09-2015 ML: !!! can't do "Specular mode" in multishader !!!
            // ML 01-18-2018: diffuse only mapping for billboards for now
            if (!pMaterial->bumpMapID || bSpecular || isBillboard) {

                // Bind the color map texture.  // ML: 11-26-2015
                glActiveTexture(GL_TEXTURE0);
                glEnable(GL_TEXTURE_2D);
........

It utilizes the shader that's called gR.blinnPhongShader:

........
                    goto doneBillboard;
                }

                // Per fragment Blinn-Phong code path.
                glUseProgram(gR.blinnPhongShader); // MLL 02-27-2018: bypass billboard code above

                // Update shader parameters.
                glUniform1f(glGetUniformLocation(gR.blinnPhongShader, "rDoFlat"), rDoFlat); // MLL 03-17-2019:
                glUniform1f(glGetUniformLocation(gR.blinnPhongShader, "rDoWire"), rDoWire); // MLL 07-01-2019:
                glUniform1i(glGetUniformLocation(gR.blinnPhongShader, "diffMap"), 0);
                glUniform1i(glGetUniformLocation(gR.blinnPhongShader, "nLights"), nLights); // ML: 12-11-2015
                glUniform1i(glGetUniformLocation(gR.blinnPhongShader, "nLightFlags"), nLightFlags); // ML 02-01-2018:
                glUniform1i(glGetUniformLocation(gR.blinnPhongShader, "bDoSpherical"), bDoSpherical); // ML: 11-26-2015
........

and it uses the bDoSpherical boolean uniform to switch on automatic spherical coordinate generation in the shader, which is equivalent to the legacy immediate mode

........
                        glTexGeni(GL_S, GL_TEXTURE_GEN_MODE, GL_SPHERE_MAP);
                        glTexGeni(GL_T, GL_TEXTURE_GEN_MODE, GL_SPHERE_MAP);
                        glEnable(GL_TEXTURE_GEN_S);
                        glEnable(GL_TEXTURE_GEN_T);
........

commands.

On the other hand, if you try and add a bumpmap to the planar material, then spherical coord autogeneration becomes impossible, and the material is rendered through gR.normalMapShader in the lower else-branch of PPL material evaluation:

........
            } else {

                // Normal mapping code path.
                glUseProgram(gR.normalMapShader);

                // Bind the emission map texture. // MLL 12-08-2018:
                glActiveTexture(GL_TEXTURE6); bFlagBump = TRUE;
........

So, both FFP and PPL have built-in automatics to sense reflective materials with both global (wallpaper-based) and local (refl-based) "ambient" reflectance. The pipelines can simply be toggled with the Use fixed pipeline menu.

And finally, the Render->Ambient reflection menu is meant for any model with any set of materials to be optionally rendered entirely in the global wallpaper-based fancy "ambient" reflection mode. To me (and I am an average user in this case) it's as useless and pure fancy as any other shader in that section (gooch, cartoon, x-ray, etc.).

Hopefully, now you understand how "ambient reflection" works in OR and how entirely worthless its immediate mode is against the almighty programmable pipeline.

[Patrice Terrier]

On the other hand, if you try and add a bumpmap to the planar material, then spherical coord autogeneration becomes impossible, and the material is rendered through gR.normalMapShader in the lower else-branch of PPL material evaluation

Yes, i forgot that bumpmap and reflection are incompatible, probably because of the nasty neurone decimation i have encountered since falling down from my roof. 

[Michael Lobko-Lobanovsky]

It's not that bad at all, my friend!

Tell you what: bumpmapping and reflection are incompatible only in the normal-map ubershader we're currently using for our most advanced materials including transparencies.

When we switch over to dedicated shaders for reflection/refraction materials like glass and water or mirrors, normal maps are going to become standard means for emulating complex-profile transparent reflective/refractive surfaces:

[Patrice Terrier]

yes, this is what i was looking for

[Patrice Terrier]

Good afternoon gentlemen...

Daisy, Daisy...

BTW, the shader "#wallpaper IntoThelight.fs" blows up OR, when started from a material file 

[Michael Lobko-Lobanovsky]

Hehe...  Do you think such a small computer would be able to control the entire spaceship? I think it used to be the size of a mainframe.

IntoTheLight.fs works as-is by D&D. And it also works if renamed to IntoTheLite.fs and used locally:

#wallpaper @intothelite.fs

But it fails if specified as a global wallpaper regardless of name:

#wallpaper intothelite.fs

or

#wallpaper intothelight.fs

 

[Michael Lobko-Lobanovsky]

There is one glitch with Hal: if you zoom it out far enough, you will notice its logo HAL9000 disappear from time to time at certain distances. The same can be seen when it's zooming in via Animate reset on model load.

Is it possibly z-buffer fighting between the logo and leather mesh surfaces?

[Patrice Terrier]

But it fails if specified as a global wallpaper regardless of name:

Yes, because it is the ame problem we already have

in the case of a wallpaper starting with a i intothelight.fs
it shokes in Mobj_importMaterials on

        case 'i': // illum
            fscanf(pFile, "%d", &nIllum);
            pMaterial->illum = nIllum;
            if (nIllum == 1) {
                pMaterial->specular[0] = 0.0f;
                pMaterial->specular[1] = 0.0f;
                pMaterial->specular[2] = 0.0f;
                pMaterial->specular[3] = 1.0f;
            }
            break;

Here is one solution to protect use agains the NULL pointer causing the havoc.

        case 'i': // illum
            fscanf(pFile, "%d", &nIllum);
            if (nIllum) { // PAT: 01-01-2020 avoid NULL pointer
                pMaterial->illum = nIllum;
                if (nIllum == 1) {
                    pMaterial->specular[0] = 0.0f;
                    pMaterial->specular[1] = 0.0f;
                    pMaterial->specular[2] = 0.0f;
                    pMaterial->specular[3] = 1.0f;
                }
            }
            break;

[Michael Lobko-Lobanovsky]

No, I suggest

........
        case 'i': // illum
            if (strstr(szBuffer, "illum")) {
                fscanf(pFile, "%d", &nIllum);
                pMaterial->illum = nIllum;
                if (nIllum == 1) {
                    pMaterial->specular[0] = 0.0f;
                    pMaterial->specular[1] = 0.0f;
                    pMaterial->specular[2] = 0.0f;
                    pMaterial->specular[3] = 1.0f;
                }
            }
            break;
........

and all the problems with locality or name are gone. Besides, it matches how other cases isolate their parameters.

[Patrice Terrier]

No, try with illumination.fs or just illum.fs
strstr alone is not enough even combined with a length of 5, because there could be no value following "illum".

illum is the only one assigning directly a pointer.

I have attached the new HAL version, indeed it is the hal monolith

[Michael Lobko-Lobanovsky]

No Patrice,

Your inference on pointers is completely wrong here!

&nIllum will always be non-NULL because nIllum is a valid long temp var that we allocate on the stack and pre-assign with a value of 0. If the fscanf() call fails, i.e. it is not a valid illum assignment but an unlucky chance of shader being called illum.fs or similar, then nIllum will still stay 0, which is still a valid illum value! See the reference table in renderers.h near line 455:

........
            //0 Color on and Ambient off
........

So, the only legit way to check if fscanf() worked as it should is to check its return value that will be non-zero if it is a valid illum assignment, and zero if it is just a clash of names and there is no any numeric parameter following the "illum" string:

........
        case 'i': // illum
            if (fscanf(pFile, "%d", &nIllum)) {
                pMaterial->illum = nIllum;
                if (nIllum == 1) {
                    pMaterial->specular[0] = 0.0f;
                    pMaterial->specular[1] = 0.0f;
                    pMaterial->specular[2] = 0.0f;
                    pMaterial->specular[3] = 1.0f;
                }
            }
            break;
........

The new Hal's logo behaves better indeed and disappears only once at its extreme far distance. Thank you!

[Patrice Terrier]

if (fscanf(pFile, "%d", &nIllum)) {

Sold!