Post by marscaleb on Jun 21, 2017 14:31:05 GMT -5
Does anyone here have some experience editing the colormap? Or know of any tutorials on editing it, or tools to create one automatically?
I was experimenting with changing the palette for the game. This of course invalidates the colormap, producing awkward results.
Of course, apart from the palette, the only data used in the colormap is used in software rendering, but still, I would like to set it up to operate properly.
Part 1: lightmap values
The section that gives values for the lighting is not as straight-forward as it was in Doom. It now can simulate values brighter than the default pixel value. And properly simulating this brightness is pretty tricky.
First of all, there is no straight "center value" where all colors will display their native values. It come close in the middle, but not quite. I had originally thought I might just have 32 values that blend dark, and 32 values that blend bright, but the original colormap doesn't do that. It blends a small range of "normal brightness" colors to give a smoother blend between light and dark.
Second of all, the bright values don't blend evenly into their brightest shades.
Look at the top row of brights. The black is still black. The next several shades of grey also remain very dark, but gradually fade into the bright band of white. On the far end of the detail image above, you can see the blue-to-red band do the same thing. And yet almost all the colors in-between do not turn so bright.
Last night I made a super quick-and-dirty test just to see how much it matters.
I made the bottom two-thirds gradually fade to black, and I made the top third fade to white, but I toned down the strength of the white by adjusting the opacity of that layer.
The example below is also using a custom palette I am working on, and the textures have not been updated to this palette, but you can still see the problem.
Because I had the brights simple "fade to white" the bright sections looking like they are turning white, not simply turning brighter. I should have changed that layer to some effect like "multiply" or "brighten," but it still reveals that if I don't match up the colormap properly, it is going to look drastically different between software and OpenGL renders. I need to create a colormap that is going to match the values as the engine renders lighting in the OpenGL render, which is not quite so straightforward as making it go from light to dark.
Part 2: Transparency
At first I just took my palette stretched it out, duplicated the layer, rotated the copy and reduced its transparency to fifty. But this produces a table that is identical across diagonal values. You can see in the original that the band of bright green is more noticeable in one direction than the other. So the next step would be to adjust that transparency to something else. (This is pretty smart when you think about it. It give you TWO look-up tables for transparency, so you can have two separate options for transparencies.)
But looking at the original colormap shows more going on than a simple blend between two colors. If you follow the first color, pure black, you will see more than just each color turning 50 % black (or 1/3 or whatever it is.) In fact, it looks closer to the original color than most of the other colors will turn. It would seem that the color of the transparent color is dynamically adjusted so that some colors (ideally the brighter ones) retain more of their original color, and some colors (ideally the darker ones) take on a more transparent color.
Its a brilliant design to create a more natural look for water effects, but still, I don't know the exact method being used, so I can only create some half-baked attempted at recreating this effect in the colormap. I don't even know which direction is for which effect.
BTW, random tidbit I discovered while working on this:
When using the OpenGL render (not software) the skyboxes will obtain their palette info straight from the original file, so you could create skies that use more color depth that the original palette, even in vanilla Q2.
I was experimenting with changing the palette for the game. This of course invalidates the colormap, producing awkward results.
Of course, apart from the palette, the only data used in the colormap is used in software rendering, but still, I would like to set it up to operate properly.
Part 1: lightmap values
The section that gives values for the lighting is not as straight-forward as it was in Doom. It now can simulate values brighter than the default pixel value. And properly simulating this brightness is pretty tricky.
First of all, there is no straight "center value" where all colors will display their native values. It come close in the middle, but not quite. I had originally thought I might just have 32 values that blend dark, and 32 values that blend bright, but the original colormap doesn't do that. It blends a small range of "normal brightness" colors to give a smoother blend between light and dark.
Second of all, the bright values don't blend evenly into their brightest shades.
Look at the top row of brights. The black is still black. The next several shades of grey also remain very dark, but gradually fade into the bright band of white. On the far end of the detail image above, you can see the blue-to-red band do the same thing. And yet almost all the colors in-between do not turn so bright.
Last night I made a super quick-and-dirty test just to see how much it matters.
I made the bottom two-thirds gradually fade to black, and I made the top third fade to white, but I toned down the strength of the white by adjusting the opacity of that layer.
The example below is also using a custom palette I am working on, and the textures have not been updated to this palette, but you can still see the problem.
Because I had the brights simple "fade to white" the bright sections looking like they are turning white, not simply turning brighter. I should have changed that layer to some effect like "multiply" or "brighten," but it still reveals that if I don't match up the colormap properly, it is going to look drastically different between software and OpenGL renders. I need to create a colormap that is going to match the values as the engine renders lighting in the OpenGL render, which is not quite so straightforward as making it go from light to dark.
Part 2: Transparency
At first I just took my palette stretched it out, duplicated the layer, rotated the copy and reduced its transparency to fifty. But this produces a table that is identical across diagonal values. You can see in the original that the band of bright green is more noticeable in one direction than the other. So the next step would be to adjust that transparency to something else. (This is pretty smart when you think about it. It give you TWO look-up tables for transparency, so you can have two separate options for transparencies.)
But looking at the original colormap shows more going on than a simple blend between two colors. If you follow the first color, pure black, you will see more than just each color turning 50 % black (or 1/3 or whatever it is.) In fact, it looks closer to the original color than most of the other colors will turn. It would seem that the color of the transparent color is dynamically adjusted so that some colors (ideally the brighter ones) retain more of their original color, and some colors (ideally the darker ones) take on a more transparent color.
Its a brilliant design to create a more natural look for water effects, but still, I don't know the exact method being used, so I can only create some half-baked attempted at recreating this effect in the colormap. I don't even know which direction is for which effect.
BTW, random tidbit I discovered while working on this:
When using the OpenGL render (not software) the skyboxes will obtain their palette info straight from the original file, so you could create skies that use more color depth that the original palette, even in vanilla Q2.