Skip to content

Minor shader fixes #2901

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

Merged
merged 1 commit into from
Jun 9, 2020
Merged

Minor shader fixes #2901

merged 1 commit into from
Jun 9, 2020

Conversation

Capostrophic
Copy link
Collaborator

  • simpleWater bool is not set to false by default anymore. Uniforms are initialized to zero by default which corresponds to false, so this shouldn't be necessary, and GL4ES doesn't support initializers for uniforms right now and currently has to manually do the same thing done here.
  • Most objects in the game only have a diffuse map and don't have specularity, but while handling the diffuse map is obviously necessary, the per-fragment specularity calculations in the shaders used for all objects should be avoided whenever possible. Per suggestion of akortunov, getSpecular call isn't done for objects that have a black specular color in their material as well as terrain. This seems to result in a ~10% higher framerate on a GeForce GTX 1050 when shaders are used (of course it depends on whether shadows and water shader are used), while on older video cards it may not lead to discernible benefit but certainly shouldn't lead to a discernible loss either. Should probably resolve 5428, as there isn't much that can be done otherwise; I thought about making specular lighting per-vertex when the entire lighting is per-vertex, but given that there are at least four situations that should be taken care of — per-vertex material specularity, per-vertex specular map specularity (shouldn't be a thing), per-pixel material specularity, per-pixel specular map specularity — it has proven to complicate shaders much more than what I'm comfortable with. Maybe later.

Don't initialize uniform bool to false explicitly
Attempt not to calculate specular lighting if the material specular color is black
@akortunov
Copy link
Collaborator

Also this PR improves situation with bug #4952.
The getSpecular() is a one of three causes of terrible particle systems performance when shaders are used (other two are texture lookups when shadows are enabled and per-pixel lighting).

@psi29a psi29a requested a review from AnyOldName3 June 9, 2020 14:00
@AnyOldName3
Copy link
Member

Yeah, I guess the only situation where this would make things worse is on older GPUs without jump instructions, and the only extra thing would be a single multiplication by zero which the optimiser would probably remove as when it happened, the thing would already be being multiplied by zero. LGTM.

@AnyOldName3 AnyOldName3 merged commit 720700e into OpenMW:master Jun 9, 2020
@Capostrophic Capostrophic deleted the shaders branch June 9, 2020 16:19
@icecream95
Copy link
Contributor

Doing viewNormal calculation inside the if statement when !normalMap && !parallax && !PER_PIXEL_LIGHTING could further improve things.

With GPU frequency at 100MHz:

Before 8 fps
This PR 8.7 fps
Calculate viewNormal inside if (!matSpec) 9.4 fps
No getSpecular 11.6 fps

(Most of the rest of the difference here is because all the extra uniforms force UBOs to be used instead of register uniforms)

@akortunov
Copy link
Collaborator

akortunov commented Jun 15, 2020

Doing viewNormal calculation inside the if statement when !normalMap && !parallax && !PER_PIXEL_LIGHTING could further improve things.

Sorry, I do not understand what you want. The viewNormal is actually used in normal, specular and parallax maps, also in PPL. Feel free to create a pull request to explain your intentions.

@Sisah2
Copy link

Sisah2 commented Jun 15, 2020

He probably mean that
viewNormal = gl_NormalMatrix * normalize(passNormal);
Is always called, but its needed only if per_pixel_lighting is enabled, if there is normal/parallax/specular map or
if (matSpec != vec3(0.0))

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants