This week was spent on finalizing the unwrap of the vehicle model as well as texture map baking. Admittedly, I did not do the best job I could, but I will try not to make the same mistakes next time. After all, it was a while since I last tried to fit everything on the same texture sheet instead of working with a bunch of tileable textures.
Originally, I tried to render everything from a high poly mesh, however because of the small size of some of the details I wanted to create, even after baking normals at the 8192p resolution they were too pixelated. So I had to combine height map based normals with baked down details. Even so, quite a lot of detail had to be tweaked by hand in Photoshop in order to achieve the smooth result I wanted.
A very unpleasant issue I encountered was the fact that normal maps were influenced by the smoothing groups. Example - a bit of texture that looks perfect on one surface looks like it has a green or red channel flipped when it's reused on another. Getting rid of a smoothing group in most cases is not an option. Solution I had to resort to was mirroring the UVs of problematic areas. Not the most elegant decision, but since all we have to do is optimize the scene for real-time viewport rendering, that should do.
I'm currently in the middle of diffuse map creation. Right now it's just plain colours with an overlay of ambient occlusion, convexity and concavity. All these maps were rendered using Knald. The reason for using this software is the same as why I based some of my normal maps on images - baking produces maps that are too pixelated. There is still a lot of work to do nevertheless.
Those shaders we were supplied with are pretty fun. One might even like them if they enjoy not having certain functions that people are normally used to when creating 3d models. For optimization, there is no all-in-one shader. Which is perfectly fine - why waste precious calculation cycles on something that is not even in use? This, however, causes some issues when what you need to achieve some weird stuff, like emissive material with transparency. Which, interestingly enough, I needed to do for the "wing" bits of my spaceship. Still, it's fine. In the actual studio I would have an option of pestering the programmer to make another shader. I don't understand, however, is why there is no option to make material two-sided. I mean, Codemasters make a lot of games about cars, they have to make two-sided glass.
Also, these materials can only be affected by one light source at the time. Which is lovely from performance point of view, but makes me very angry.
In any case, after talking to James about those issues, he agreed to let us use Xoliul shader for those specific bits of the model. This solved my problem with emissive semi-transparent material, but created a new one - apparently Xoliul does not handle transparency gradients, and can only create a clipping mask. Well, too bad for me. I just said "screw all this", and made a different design of that forcefield glow. Now it's a lovely hexagon grid. What's important, it's two-sided and emissive.
Note to self: take more progress screenshots.
Originally, I tried to render everything from a high poly mesh, however because of the small size of some of the details I wanted to create, even after baking normals at the 8192p resolution they were too pixelated. So I had to combine height map based normals with baked down details. Even so, quite a lot of detail had to be tweaked by hand in Photoshop in order to achieve the smooth result I wanted.
A very unpleasant issue I encountered was the fact that normal maps were influenced by the smoothing groups. Example - a bit of texture that looks perfect on one surface looks like it has a green or red channel flipped when it's reused on another. Getting rid of a smoothing group in most cases is not an option. Solution I had to resort to was mirroring the UVs of problematic areas. Not the most elegant decision, but since all we have to do is optimize the scene for real-time viewport rendering, that should do.
I'm currently in the middle of diffuse map creation. Right now it's just plain colours with an overlay of ambient occlusion, convexity and concavity. All these maps were rendered using Knald. The reason for using this software is the same as why I based some of my normal maps on images - baking produces maps that are too pixelated. There is still a lot of work to do nevertheless.
Those shaders we were supplied with are pretty fun. One might even like them if they enjoy not having certain functions that people are normally used to when creating 3d models. For optimization, there is no all-in-one shader. Which is perfectly fine - why waste precious calculation cycles on something that is not even in use? This, however, causes some issues when what you need to achieve some weird stuff, like emissive material with transparency. Which, interestingly enough, I needed to do for the "wing" bits of my spaceship. Still, it's fine. In the actual studio I would have an option of pestering the programmer to make another shader. I don't understand, however, is why there is no option to make material two-sided. I mean, Codemasters make a lot of games about cars, they have to make two-sided glass.
Also, these materials can only be affected by one light source at the time. Which is lovely from performance point of view, but makes me very angry.
In any case, after talking to James about those issues, he agreed to let us use Xoliul shader for those specific bits of the model. This solved my problem with emissive semi-transparent material, but created a new one - apparently Xoliul does not handle transparency gradients, and can only create a clipping mask. Well, too bad for me. I just said "screw all this", and made a different design of that forcefield glow. Now it's a lovely hexagon grid. What's important, it's two-sided and emissive.
 |
 |
Note to self: take more progress screenshots.
No comments:
Post a Comment
Note: Only a member of this blog may post a comment.