Posted: Fri Apr 09, 2010 7:36 pm
Not really, it’s the same each time.Killer Wolf wrote:far too late for that.
Page 39 of 138
Posted: Fri Apr 09, 2010 7:46 pm
As of r3134, Oolite supports greyscale+alpha PNGs for textures. I think this means Oolite now handles all valid PNG formats and is therefore truly PNG-compliant, but I haven’t tried any test suites.
This format uses half as much memory as an RGBA texture of the same size and is primarily useful for shaders which happen to need 4 × N + 2 texture channels. Greyscale+alpha PNGs are loaded in GL_LUMINANCE_ALPHA mode, which means the r, g and b vector components are all the grey channel and the a component is the alpha channel. Exactly what you’d get if you converted the PNG to RGBA, in other words.
Most graphics apps don’t support greyscale+alpha mode, but PNG optimizer tools like OptiPNG will automatically convert to greyscale+alpha when appropriate (i.e. when all pixels are grey and the alpha channel isn’t all 100 % opaque). This could cause problems for a non-compliant PNG reader like pre-3134 versions of Oolite, but is now a Good Thing from our perspective. Yay!
This format uses half as much memory as an RGBA texture of the same size and is primarily useful for shaders which happen to need 4 × N + 2 texture channels. Greyscale+alpha PNGs are loaded in GL_LUMINANCE_ALPHA mode, which means the r, g and b vector components are all the grey channel and the a component is the alpha channel. Exactly what you’d get if you converted the PNG to RGBA, in other words.
Most graphics apps don’t support greyscale+alpha mode, but PNG optimizer tools like OptiPNG will automatically convert to greyscale+alpha when appropriate (i.e. when all pixels are grey and the alpha channel isn’t all 100 % opaque). This could cause problems for a non-compliant PNG reader like pre-3134 versions of Oolite, but is now a Good Thing from our perspective. Yay!
Posted: Sun Apr 11, 2010 4:44 pm
Debug flag handling for the console has been changed somewhat. Instead of using a bunch of magic numbers specified in a comment in the script, there are now symbolic constants, so you can do things like:
New shader loading behaviour: when loading a shader in full mode fails (typically due to a syntax error), Oolite now tries to fall back to simple mode. Unfortunately, this currently does not happen when a shader is too complex to run on the current system. This behaviour can be suppressed with the debug flag DEBUG_NO_SHADER_FALLBACK.
Additionally, extra validation tests will be run if the debug flag DEBUG_SHADER_VALIDATION is set. This will catch certain types of inconsistencies between vertex shader and fragment shader, and log warnings about things that don’t break the shader on your system but might on others. The precise nature of this validation is implementation-defined.
I strongly recommend using DEBUG_NO_SHADER_FALLBACK and DEBUG_SHADER_VALIDATION all the time if you write shaders, so here’s a trivial OXP to set them at startup (assuming the debug console is active).
Code: Select all
console.debugFlags = console.DEBUG_BOUNDING_BOXESAdditionally, extra validation tests will be run if the debug flag DEBUG_SHADER_VALIDATION is set. This will catch certain types of inconsistencies between vertex shader and fragment shader, and log warnings about things that don’t break the shader on your system but might on others. The precise nature of this validation is implementation-defined.
I strongly recommend using DEBUG_NO_SHADER_FALLBACK and DEBUG_SHADER_VALIDATION all the time if you write shaders, so here’s a trivial OXP to set them at startup (assuming the debug console is active).
Posted: Mon Apr 12, 2010 6:18 pm
Implemented preliminary support for the emission_map (glow map) material property in non-shader mode. This requires the GL_ARB_texture_env_combine extension (which all but the most ancient systems will support; you can see your OpenGL extensions in Oolite’s log) and is disabled in reduced detail mode.
At the moment, emission_map cannot be combined with emission in non-shader mode. (In shader mode, the emission colour is multiplied with the emission map.) I expect to fix this.
Also, it is not possible to combine a cube-mapped diffuse map with a non-cube-mapped emission map in non-shader mode, while it is not possible to use a cube-mapped emission map with the default shader in shader mode. (You could work around this by using a custom shader.)
I intend to handle illumination_map and emission_and_illumination_map in non-shader mode by converting them to emission maps (i.e., premultiplying the illumination map with the diffuse map and adding to the emission map). This will also be done for emission_and_illumination_map in shader mode, and emission_and_illumination_map will be deprecated. Standalone illumination_map will not be deprecated, because it is potentially useful to save memory by using a single-channel illumination map with a full-colour diffuse map (although this advantage will be lost in non-shader mode). I also intend to add an illumination_color attribute to make single-channel illumination maps more useful.
Note: to convert an illumination map to an emission map in Photoshop or GIMP, put the diffuse map over it in a separate layer and use Multiply blend mode.
At the moment, emission_map cannot be combined with emission in non-shader mode. (In shader mode, the emission colour is multiplied with the emission map.) I expect to fix this.
Also, it is not possible to combine a cube-mapped diffuse map with a non-cube-mapped emission map in non-shader mode, while it is not possible to use a cube-mapped emission map with the default shader in shader mode. (You could work around this by using a custom shader.)
I intend to handle illumination_map and emission_and_illumination_map in non-shader mode by converting them to emission maps (i.e., premultiplying the illumination map with the diffuse map and adding to the emission map). This will also be done for emission_and_illumination_map in shader mode, and emission_and_illumination_map will be deprecated. Standalone illumination_map will not be deprecated, because it is potentially useful to save memory by using a single-channel illumination map with a full-colour diffuse map (although this advantage will be lost in non-shader mode). I also intend to add an illumination_color attribute to make single-channel illumination maps more useful.
Note: to convert an illumination map to an emission map in Photoshop or GIMP, put the diffuse map over it in a separate layer and use Multiply blend mode.
Posted: Tue Apr 13, 2010 1:11 am
Coo! My OpenGL configuration includes GL_ARB_texture_env_combine!Ahruman wrote:Implemented preliminary support for the emission_map (glow map) material property in non-shader mode. This requires the GL_ARB_texture_env_combine extension (which all but the most ancient systems will support; you can see your OpenGL extensions in Oolite’s log) and is disabled in reduced detail mode.
Posted: Tue Apr 13, 2010 6:18 am
too late in that due to multiple reboots using the new 3131 which worked, the log was long gone.Ahruman wrote:Not really, it’s the same each time.Killer Wolf wrote:far too late for that.
Posted: Sat Apr 17, 2010 11:16 am
- New texture option extract_channel, which allows the use of a single channel of an RGBA PNG as a greyscale texture. The intended use is to extract one channel from an effect map for use in a non-shader-mode fallback, as in: emission_map = { name = "foo_effect_map.png"; extract_channel = "a"; };. Valid values are “r”, “g”, “b” and “a”. No effect on greyscale or greyscale+alpha textures. (This is in last night’s nightly.)
- Specular highlights in non-shader mode now use “separate specular” mode, where the specular highlight is applied after the diffuse light colour is modulated with the diffuse material texture (which is also what happens in the default shader). Previously, the specular highlight was added to the diffuse light before modulating with the shader, making it impossible to have a bright specular highlight on a dark texture. This is essentially a fix for a bug in the earliest versions of the OpenGL specification, but it has to be enabled explicitly and Oolite wasn’t doing so.
Posted: Wed Apr 21, 2010 6:22 pm
- Full support for all meaningful combinations of emission and illumination maps and colours in non-shader mode. Test case: non-shady-griff-moray.oxp, requires griff_moray_normalmapped.oxp.
- Material properties diffuse, specular, ambient and emission have been renamed to diffuse_color, specular_color, ambient_color and emission_color. The old names are still supported for compatibility.
- New material property illumination_color. Modulates illumination map. Unlike emission_color, this has no effect if there is no corresponding map.
Posted: Wed Apr 21, 2010 7:15 pm
- Cube-mapped diffuse maps without custom shaders are now mapped using vertex positions rather than normals. Assuming the mesh is properly centred on the origin, this gives a more predictable mapping. The sample OXP’s shader has been updated to do the same thing.
- expandDescription() and expandMissionText() now take an optional dictionary of substitutions, as in:
Code: Select all
expandDescription("police-attack-warning", { "describe-Pirate" : "naughty person" }); - The DEBUG_NO_SHADER_FALLBACK debug flag now has the additional effect of forcing all materials to use shaders in simple shader mode. (Without DEBUG_NO_SHADER_FALLBACK, non-smoothed objects without explicit vertex normals and with no custom shader, emission_map or illumination_map are rendered without shaders.)
Posted: Wed Apr 21, 2010 9:42 pm
Cube maps can now be used for planets. A planet texture six times as high as it is wide is assumed to be a cube map (explicitly specifying cube_map is neither necessary nor possible). Using a cube map for a planet resolves all known problems with planet texture mapping and is the recommended approach from 1.74 on.
Posted: Wed Apr 21, 2010 9:48 pm
Ahruman wrote:Cube maps can now be used for planets. A planet texture six times as high as it is wide is assumed to be a cube map (explicitly specifying cube_map is neither necessary nor possible). Using a cube map for a planet resolves all known problems with planet texture mapping and is the recommended approach from 1.74 on.
Nice!
I like to see an example
It comes to late for Famous Planets. That's now entering Beta Phase and I have not the time to redo all the textures in the cube map style. But for System Redux2 it could be great.!
Posted: Wed Apr 21, 2010 10:13 pm
Quick and dirty, using the cubemap from Ahruman's cubemap test oxp (click thumbnail for full size):pagroove wrote:I like to see an example
Posted: Wed Apr 21, 2010 10:19 pm
There seems to be an artefact right across the Caspian Sea, however.
Posted: Wed Apr 21, 2010 10:55 pm
That’s a scaling artefact in my test texture.
Posted: Thu Apr 22, 2010 2:25 am
Is there, by chance, a forth-coming script or tool to convert a "normal" 2x1 texture to a cube map?