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

Moving matrix multiplication to the CPU. Adding glMatrix dependency. #315

Open
wants to merge 12 commits into
base: develop
Choose a base branch
from

Conversation

solomon-gumball
Copy link
Contributor

Enables:

Accurate normal mapping
Better performance for high vertex geometries

@michaelobriena
Copy link
Member

@redwoodfavorite Can you add containers for this so that I can see the benchmarks?

Also, I doubt that people are actually using our shader for anything else but can you rewrite some of your commits that remove functions to have the "breaks:" tag? Since we will be auto generating the changelog this is important.

@michaelobriena
Copy link
Member

Should the benchmarks prove a performance improvment, these look good.

@michaelobriena
Copy link
Member

@redwoodfavorite can you post benchmarks for these changes?

@solomon-gumball
Copy link
Contributor Author

Addresses this issue: #250 (comment)

@solomon-gumball
Copy link
Contributor Author

I made a demo with some high vertex spheres on a grid.

Here's the before:
https://api-te.famo.us/codemanager/v1/containers/720b7aaf-87fc-432a-90af-6885a3519af5/share

Here's the after:
https://api-te.famo.us/codemanager/v1/containers/45ccb928-ce3c-45b9-ba86-0f95bb3cf73b/share

Honestly, they are nearly identical in performance which somewhat suprises me.

This change's benefits though are that it enables more accurate normal maps #250 (comment) and great simplifies debugging as well as code complexity of the vertex shader.

@solomon-gumball
Copy link
Contributor Author

Hold on, I've got some changes to the fragment shader normal mapping I'd like to make before we merge this.

@ghost
Copy link

ghost commented Jun 25, 2015

even if the performance difference is minimal, +1 for moving logic to js for ease of understanding / debugging.

@jd-carroll
Copy link
Contributor

Please forgive my ignorance here, but...
How is this moving to the CPU?
Presumably it was all done on the GPU previously, and I thought this was a selling point?

@solomon-gumball
Copy link
Contributor Author

@jd-carroll Good question.

This is change is only moving the multiplication of the model matrix and the view matrix, and the generation of the normal matrix to the CPU. These are calculated in Javascript and passed to the GPU as uniforms. With this method you have to calculate these matrices once per draw call, instead of per vertex, though the containers indicate the performance is about the same. The real advantage of this method however is that it lets you debug these matrices on the CPU, which is 100x easier.

Also, this is a much more standard way of doing things. @FarhadG will probably tell you that it's difficult to find examples of normal matrix assembly in the vertex shader.

@solomon-gumball
Copy link
Contributor Author

Should be ready to go now. @FarhadG @adnan-wahab would you guys mind looking at this and running any test demos you guys have?

buffers.push(
{ name: 'a_pos', data: vertices },
{ name: 'a_texCoord', data: textureCoords, size: 2 },
{ name: 'a_normals', data: normals },
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

gonna have to be a_normal after @FarhadG's big ol change

@michaelobriena
Copy link
Member

@redwoodfavorite Can you look at the build breaking and rebase is need be?

@alexanderGugel
Copy link
Member

I like this (not sure about the glMatrix dependency though).

@michaelobriena What's the priority of this? Do you want me to work on bringing this in?

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