Today I think I've finally managed to complete the refactoring of the deferred renderer system.
All the remaining shaders (used internally by the renderer) have been automatized.
I also refactored a few function here and there which had problems... everything went unexpectedly straightforward, and everything should be fine now.
The main difference after this huge refactoring is that shaders can be created from the game, instead of using the fixed ones provided by me in the deferred rendering class. And they also automatically recognize the data to send to the shaders thanks to glsl program introspection.
Maybe I'll take a little pause now, however the next thing I'm gonna do will be to create a "transparent" object.
Now, transparency is impossible in deferred rendering, but I can create a special shader for this object who sample the skybox and use it to simulate transparency and refraction. Of course it won't reflect other objects, for that I'll need to render again the scene from the point of view of that object, and then sample it...which is something feasible, but a lot expensive and not supported automatically by the engine.
martedì 5 gennaio 2016
lunedì 4 gennaio 2016
Day 114: Killing bugs
Today I noticed that I was sending uniforms to the shader through their pointers. Which is quite a bad practice for two reasons:
1) If the data is the same but somehow it got 2 different pointers to it, the uniforms are not batched
2) I cannot pass lvalue to the function (set_uniform(3) is undefined behaviour because the reference to the number 3 will be immediatly lost)
So i decided to copy those values instead, and this lead to 3 different bugs, each of which seemed completely unrelated to the thing I changed.
After quite a lot of work I fixed them all, and one of them was actually a bug of the new batch that I would have probably discovered sooner or later.
Then I wanted to remove some atrributes from the light classes, to make them more versatile, but I noticed that they actually use all those info, colors included, to generate stuff like bounding box radiuses and so on...so i guess i'll leave it like that.
However it is absolutely possible to add extra uniforms in the game scene, and they will be automatically sent.
1) If the data is the same but somehow it got 2 different pointers to it, the uniforms are not batched
2) I cannot pass lvalue to the function (set_uniform(3) is undefined behaviour because the reference to the number 3 will be immediatly lost)
So i decided to copy those values instead, and this lead to 3 different bugs, each of which seemed completely unrelated to the thing I changed.
After quite a lot of work I fixed them all, and one of them was actually a bug of the new batch that I would have probably discovered sooner or later.
Then I wanted to remove some atrributes from the light classes, to make them more versatile, but I noticed that they actually use all those info, colors included, to generate stuff like bounding box radiuses and so on...so i guess i'll leave it like that.
However it is absolutely possible to add extra uniforms in the game scene, and they will be automatically sent.
domenica 3 gennaio 2016
Day 113: Independent lights
Today I moved all three lights shaders to the game, so the user can create its own.
The data are then sent automatically to the shader in the deferred renderer class.
This took an enormous amout of time, due to endless copy and paste and syntactic adjustments, but it was not a very hard job.
Now all the info about a light are stored in the light class as before. You can for example set a specular color, and it will be automatically sent in the deferred class. But this is not what I want, because it is exacly as before.
The idea is to remove this "static" data from the lights, so that the user will only use the ones in his custom shader. Only a few of them, which are absolutely important for the existence of the light itself, will be left there, like the position for instance.
Tomorrow I'll do that, and it should be trivial, since the big part of the refactoring was done today.
After that I will adapt the last shaders to work with the simple renderer (like the skybox or the blit program).
The sprite and font batch should probably be refactored as well to handle multiple shaders, and the font itself is so badly written that it cannot even support stuff like the rotation....but honestly I don't really care about 2D, it was just a fast improvement to the engine finalized to the shell creation, so I'll probably ignore them.
The data are then sent automatically to the shader in the deferred renderer class.
This took an enormous amout of time, due to endless copy and paste and syntactic adjustments, but it was not a very hard job.
Now all the info about a light are stored in the light class as before. You can for example set a specular color, and it will be automatically sent in the deferred class. But this is not what I want, because it is exacly as before.
The idea is to remove this "static" data from the lights, so that the user will only use the ones in his custom shader. Only a few of them, which are absolutely important for the existence of the light itself, will be left there, like the position for instance.
Tomorrow I'll do that, and it should be trivial, since the big part of the refactoring was done today.
After that I will adapt the last shaders to work with the simple renderer (like the skybox or the blit program).
The sprite and font batch should probably be refactored as well to handle multiple shaders, and the font itself is so badly written that it cannot even support stuff like the rotation....but honestly I don't really care about 2D, it was just a fast improvement to the engine finalized to the shell creation, so I'll probably ignore them.
sabato 2 gennaio 2016
Day 112: Wasted time...almost
Today I tried a huge refactoring to use the batch with the lights.
After hours of work I suddenly realized that it is absolutely useless, because while each light could eventually be batched with other ones, each one of them requires a different shadow texture. For this obvious reason, which somehow i failed to see before, a batch is absolutely useless, because each model requires a single draw call.
After hours of work I suddenly realized that it is absolutely useless, because while each light could eventually be batched with other ones, each one of them requires a different shadow texture. For this obvious reason, which somehow i failed to see before, a batch is absolutely useless, because each model requires a single draw call.
So in the end I will use the SimpleDrawer class to render each light, but I'll probably modify that to handle a variety of different shaders.
The actual, useful job I did today is limited to the refactoring of a few functions (which i copied and pasted instead of "templatize" them), and the fact that now the light shader is hold by each light instead of the deferred renderer, which is the first step in order to automatize this process as well.
Iscriviti a:
Post (Atom)