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
Material refactor #1432
Material refactor #1432
Conversation
(all three of them)
… new one Somewhat faster
Updated .obj location to have paths, VS fails if two .cpps share the same name.
Does not use a special material yet
…e new shaders Also sigh, remove 2px size check, station bulletin boards disappear way too early, meaning the radius calculation is broken
I think you can now consider this for merge. |
Was premature.
…onflicting object names at the moment.
Updated to master and updated VS2010 project, nothing special |
Thanks. I started reviewing this last night. Got about half way through before I fell asleep - unrelated, I promise! So far there's a couple of little quirks need to think about, but mostly its awesome - tons of horror code removed, lots of nice code added! I'll finish it off tonight. |
Fixed a line drawing depth bug. Drink some coffee to avoid falling asleep! |
Code seems fine. I have a few comments to add, but nothing that would stop it being merged. I'll write them down tonight if I get my computer up and running in time (new disk to install). |
The half-unfinished use of materials and shaders has now gone through some big changes.
All Materials need to be now requested from a Renderer by filling out a MaterialDescriptor structure and then calling CreateMaterial. Renderer then returns a new Material that best matches the descriptor. Users are required to delete the materials themselves, it is not useful to cache these in renderer since they are not shareable.
For renderer internals, this means less if-else during draw, instead each material's Apply() sets up the required state and Unapply() cleans it. Only renderers are supposed to call Apply, I made an exception for GeoSphere because it does not use renderer for rendering yet. LMR also has a "special" solution applied to it.
The old Shader class has been replaced by GL2::Program and is obviously not supposed to be used outside the GL2 renderer. Programs are managed by the renderer and shared between materials.