Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove all bump mapping and parallax occlusion related code. #10487

Merged
merged 1 commit into from
Oct 17, 2020
Merged

Remove all bump mapping and parallax occlusion related code. #10487

merged 1 commit into from
Oct 17, 2020

Conversation

lhofhansl
Copy link
Contributor

@lhofhansl lhofhansl commented Oct 12, 2020

See #10479 for discussion.

This PR removes bump mapping, parallax occlusion, and normal mapping code, since it was buggy and not fully implemented.
This simplifies the shader code and hopefully makes it easier to start over.

Note that this also remove the normal texture feature - since it normal textures are no longer used for anything.

@lhofhansl lhofhansl added the Maintenance Tasks to keep the codebase and related parts in order, including architectural improvements label Oct 12, 2020
@paramat
Copy link
Contributor

paramat commented Oct 12, 2020

I can review and test this, although i feel a little underqualified in some areas of the changes =)

@lhofhansl
Copy link
Contributor Author

@HybridDog FYI since you've worked in this area.

builtin/settingtypes.txt Outdated Show resolved Hide resolved
@paramat
Copy link
Contributor

paramat commented Oct 12, 2020

Interesting how the documentation reveals these shaders are actually 'experimental', unfinished and buggy. It is more of a mess than i realised.

Bumpmapping and parallax occlusion are currently experimental features:
Parallax occlusion with relief-mapping mode does not yet work correctly together with Minetest's Fastfaces.

Oddly, relief mapping mode is actually set as the default mode, and fastfaces are everywhere.

@paramat
Copy link
Contributor

paramat commented Oct 12, 2020

I will make this my top priority for review.

@lhofhansl
Copy link
Contributor Author

@paramat Thanks! You already caught two issues - I've been sloppy.

@lhofhansl
Copy link
Contributor Author

lhofhansl commented Oct 13, 2020

@TheTermos does not feel that we should remove the parallax occlusion code.

Sorry, that was @HybridDog .

@TheTermos
Copy link
Contributor

@TheTermos does not feel that we should remove the parallax occlusion code.

Where did that come from?

@lhofhansl
Copy link
Contributor Author

@TheTermos Oops. That was @HybridDog. I truly apologize!

@paramat
Copy link
Contributor

paramat commented Oct 14, 2020

My testing in the issue which shows pixel wrapping reminded me of something i thought i would mention.

The wrapping of pixels from the opposite edge, issue #2815 , was fixed in 655fc60 by adding the tiledef fields 'tileable_vertical', 'tileable_horizontal'.

Perhaps we should leave these tiledef fields present in code, for now at least, as they are likely to be needed by any new implementation of bumpmapping / parallax occlusion. However perhaps we should remove mention of them in lua_api.txt as they will be irrelevant? EDIT: Done.

We might decide to remove these tiledef fields, but i suggest that we consider and do that in a later PR, to not bloat and delay this PR.

@lhofhansl
Copy link
Contributor Author

Thanks @paramat, I don't see that I'm removing any tiledef fields in this PR. Happy to shrink the scope of this, which part are you referring to?

@paramat
Copy link
Contributor

paramat commented Oct 15, 2020

I don't see that I'm removing any tiledef fields in this PR

Sorry to be unclear, i do not mean to imply you are removing those in this PR, you are not. I am just mentioning the related tilespec code and suggesting we leave that in, for now at least.
So the only change to the PR i am suggesting is removing the documentation of 'tileable_vertical/horizontal' from lua_api.txt. EDIT: Done.

@paramat
Copy link
Contributor

paramat commented Oct 15, 2020

In client/shaders/object_shader/opengl_fragment.glsl, do the following need removing?
EDIT: Resolved.

uniform sampler2D normalTexture;
uniform sampler2D textureFlags;
uniform vec3 eyePosition;
varying vec3 vNormal;
bool normalTexturePresent = false;
bool texTileableHorizontal = false;
bool texTileableVertical = false;
bool texSeamless = false;
void get_texture_flags()
{
	vec4 flags = texture2D(textureFlags, vec2(0.0, 0.0));
	if (flags.r > 0.5) {
		normalTexturePresent = true;
	}
	if (flags.g > 0.5) {
		texTileableHorizontal = true;
	}
	if (flags.b > 0.5) {
		texTileableVertical = true;
	}
	if (texTileableHorizontal && texTileableVertical) {
		texSeamless = true;
	}
}
vec4 get_normal_map(vec2 uv)
{
	vec4 bump = texture2D(normalTexture, uv).rgba;
	bump.xyz = normalize(bump.xyz * 2.0 - 1.0);
	return bump;
}

In void main(void):

	vec4 bump;

@paramat
Copy link
Contributor

paramat commented Oct 15, 2020

In client/shaders/nodes_shader/opengl_fragment.glsl, do the following need removing?
EDIT: Resolved.

uniform sampler2D normalTexture;
uniform sampler2D textureFlags;
uniform vec3 eyePosition;

@paramat
Copy link
Contributor

paramat commented Oct 15, 2020

In client/shaders/nodes_shader/opengl_vertex.glsl, does the following need removing?
EDIT: Resolved.

uniform vec3 eyePosition;

@paramat
Copy link
Contributor

paramat commented Oct 15, 2020

I tested. Main menu is fine and everything seems to work ok.
Reviewed code and all looks fine, apart from the extra removals needed from shader files detailed above.
Will retest after those (and lua_api.txt) are attended to and hopefully will then approve.

@lhofhansl
Copy link
Contributor Author

Arrgghh. Thanks @paramat . I'll do a second pass through what can be removed and I'll remove the tilespec doc.

I wasn't sure if I wanted to remove all the uniforms from the shaders. I'll double check these.

@paramat
Copy link
Contributor

paramat commented Oct 15, 2020

I wasn't sure if I wanted to remove all the uniforms from the shaders

Ok i see. Although it will all still be in history to refer too, so not sure if there is advantage to leaving some stuff in creating a confusing mess.

I remember that 'vertex tangent' stuff was added by RBA purely for bumpmapping and parallax occlusion, in this commit 43fcfbf
Although at that point in history vertex tangents were always used, which caused a controversy because performance was greatly reduced. Later, vertex tangents were only used when shaders were enabled and when bumpmapping or parallax occlusion was enabled.

I did a search for 'tangents' in current code and found some extra stuff not in your PR:

case video::EVT_TANGENTS: {

case video::EVT_TANGENTS:

@lhofhansl
Copy link
Contributor Author

I feel the following needs to be left in:

  • case video::EVT_TANGENTS: since this is a valid enum member
  • vNormal, since this is generally useful for the fragment shader to have.
  • eyePosition, as this is also generally good to have

@lhofhansl
Copy link
Contributor Author

The failure on Android appears unrelated.

@paramat
Copy link
Contributor

paramat commented Oct 16, 2020

I feel the following needs to be left in:

That seems fine to me. I think this has a good balance of how much to remove.
Also i think we should not get too perfectionist for this first PR, as long as everything works, more could be cleaned up in a follow up PR.
I will retest, rereview and hopefully approve as soon as possible.

@paramat
Copy link
Contributor

paramat commented Oct 16, 2020

A related warning during compilation:

/src/client/game.cpp: In member function ‘virtual void GameGlobalShaderConstantSetter::onSetConstants(irr::video::IMaterialRendererServices*, bool)’:
/src/client/game.cpp:553:5: warning: unused variable ‘normal_tex’ [-Wunused-variable]
     normal_tex = 1,
     ^~~~~~~~~~
/src/client/game.cpp:554:5: warning: unused variable ‘flags_tex’ [-Wunused-variable]
     flags_tex = 2;
     ^~~~~~~~~

@paramat
Copy link
Contributor

paramat commented Oct 16, 2020

All my previous comments are attended to, rereviewed code, retested, all seems fine.
Once you fix the warnings and retest you can assume my approval and merge.

@lhofhansl
Copy link
Contributor Author

I saw that warning too, but I did not want remove that enum. Hmm... I could.
Also, since the Android failure is persistent and I do not see this with other PRs perhaps it is pertinent?

@paramat
Copy link
Contributor

paramat commented Oct 17, 2020

FAILURE: Build failed with an exception.
Task :native:downloadSqlite FAILED
Download https://www.sqlite.org/2020/sqlite-amalgamation-3320200.zip
What went wrong:
Execution failed for task ':native:downloadSqlite'.
Deprecated Gradle features were used in this build, making it incompatible with Gradle 7.0.
de.undercouch.gradle.tasks.download.org.apache.http.conn.HttpHostConnectException: Connect to www.sqlite.org:443 [www.sqlite.org/2600:3c00:0:0:f03c:91ff:fe96:b959] failed: Network is unreachable (connect failed)

It looks like a connection failure unrelated to these changes, so being persistent and this PR only seems odd. Maybe @rubenwardy could advise?

The compilation warnings are not a problem so consider my approval given, although we might want to get some input on that build failure before merging.

@rubenwardy
Copy link
Member

That's a temporary error due to website downtime, I've restarted the build

@paramat
Copy link
Contributor

paramat commented Oct 17, 2020

Good to know, and thanks.
So i think this should be merged if builds are successful, before conflicts start arising and so i do not have to rerereview. We can always do some additional clean up in a follow up PR.

@paramat
Copy link
Contributor

paramat commented Oct 17, 2020

Can be merged now.

@lhofhansl
Copy link
Contributor Author

Actually lemme look at that enum. If it can be safely removed I'll do that and then merge. Otherwise I'll merge as is.

@lhofhansl
Copy link
Contributor Author

It's not an enum anyway, I just removed he unused variables, which avoids that warning, going to merge soon.

@paramat
Copy link
Contributor

paramat commented Oct 17, 2020

Ok looks fine.

@hecktest hecktest mentioned this pull request Jul 26, 2021
10 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Maintenance Tasks to keep the codebase and related parts in order, including architectural improvements One approval ✅ ◻️ Shaders
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants