Normal mapping?
BlitzMax Forums/MiniB3D Module/Normal mapping?
| ||
| Hey, apologies, because this has probably been asked before, but searching didn't turn up any usable solutions for me. I'm somewhat unfamiliar with OpenGL and I'm trying to implement normal mapping into a game using MiniB3D. I've taken a look at the code for the extended edition and wasn't sure if there was anything there that could be salvaged. Is there any simple (read: not involving a lot of independent OpenGL knowledge) method to implement normal mapping into MiniB3D? |
| ||
| Curious that this was never addressed, or responded to. Perhaps there was a different thread this convo moved to? |
| ||
| No, there's no simple way to add normal mapping to MiniB3D. It would involve the use of shaders, which MiniB3D doesn't support. |
| ||
| This brings up my thought re:minib3d, which is to add to the core miniB3D a render callback function (abstract) that allows users to extend. If the callback exists, it bypasses the fixed-function pipeline and runs the callback code. This would allow for easy implementation of external shaders and such, so minib3d could be expanded without modding the core. |
| ||
| I'm busy with other projects right now, but if it were me, I'd extend the TBrush class to have a Shader field that points to an instance of a, say, TShader class (this field holding a 'Null' value when you want the surface to be rendered through fixed-function). This way you don't have to modify a lot of stuff or even step away from the Blitz3D way of things - it's just a juiced-up Brush class and a modified Update() function in TMesh. It would require an intermediary knowledge of OpenGL (more than I have, anyway), or at least a lot of reference material (such as Klepto2's extended version and code samples distributed around the code archives and the OpenGL forum) |
| ||
| Interesting. Would TBush be the best approach, what about shaders that want to manipulate the vertex data, for example, bone influence? Could we still use TBrush for that? |
| ||
| EDIT: Scratch what was here. Adam's idea sounds much better than what I've said. Include a field in TMesh that points to the function used to render the mesh. When a mesh is created, this field points to the fixed-function render code. If the user requires, he can make it point to a different block of code of his own, perhaps implementing shaders and what not. Makes things much easier not only for shaders but for things such as framebuffers in the case of HDR and blooming, and like he said, no need to change (in large quantity) the current framework. A definite change would be the RenderCamera() function of TGlobal.BMX to render each mesh through this render-function pointer instead of the Update() method. Last edited 2011 |
| ||
| I laid out a shader framework for my engine. It works but the functionality is limited as I've been devoting time to more important features. https://github.com/kfprimm/maxb3d https://github.com/kfprimm/maxb3d/blob/master/core.mod/shader.bmx https://github.com/kfprimm/maxb3d/blob/master/glsl.mod/glsl.bmx Feel free to borrow ideas/code from it. |
| ||
| Thanks for this! |
   |