Progress

[JensAyton]

Is this subject to debate

No. We’ve had the debate, at length, and the decision reached was to make this change after the next stable release (i.e., 1.76).

[m4r35n357]

Is this subject to debate

No. We’ve had the debate, at length, and the decision reached was to make this change after the next stable release (i.e., 1.76).

OK, sad times, but at least I can keep 1.76 as a retro retro game . . . .

[JensAyton]

To clarify, the energy bomb is still available in Strict Mode. Unrestricted mode offers a more balanced alternative and the ability to add a wide variety of overpowered cheat weapons.

[Gimi]

Is the Q-bomb installed internally, and available on the tab-key? If so, it could actually become a key I can use in Oolite. My current Commander has never used an Energy Bomb.

[JensAyton]

Is the Q-bomb installed internally, and available on the tab-key?

Only if you map your missile launch key to tab. :-) It’s just a normal Q-bomb. (True energy bomb fans might want to use that for primeable equipment instead; it shouldn’t be hard to make an energy bomb OXP.)

[Commander McLane]

it shouldn’t be hard to make an energy bomb OXP.)

The weakest of the Killit über weapons is practically an energy bomb, although more effective (guaranteed to kill), and of course also pylon mounted. Still, it should be very easy to change its effect from killing to subtracting a fixed amount of energy, and to turn it into primeable equipment.

[Thargoid]

And some of the bombs in Armoury are e-bomb replacements, although none are direct clones (they are all more balanced in that they take player energy to do their work).

[JensAyton]

Since it kinda-sorta came up: I’m currently working on porting the “shader synthesizer” from the defunct Oolite 2 project.

In Oolite 1.76,  standard materials are implemented by enabling and disabling features in a large, complicated shader template. This is both incomprehensible and inflexible. Adding more features and options is difficult because all possible combinations must be explicitly written into the template.

In contrast, the shader synthesizer writes a specialized shader for each material definition. Since this is done in “real” code instead of the GLSL preprocessor, it can support many more variations. Some concrete benefits:

• Swizzling. The existing extract_channel attribute is extended to support extracting multiple channels, such as rgb. As a practical example, you might want to use the RGB channels of a texture as the diffuse map, the alpha channel as a specular intensity map, and use a constant specular exponent; this would currently require a custom shader. (You can also reuse channels; for instance, a white/grey ship with red details can use the same channel for green and blue using extract_channel = "rgg".) Unlike the existing extract_channel, which creates a separate texture, the new form is efficient; each texture will only be sampled once per fragment, no matter how the channels are used.
• Orthogonality. With swizzling, it is no longer necessary to use fixed combinations like normal_and_parallax_map, emission_and_illumination_map or specular_map (which requires you to combine specular intensity and specular exponent terms). There will be new parallax_map, specular_intensity_map specular_color_map and specular_exponent_map attributes.
• More parameters. It should be easy to add support for custom scaling factors and offsets to most or all types of texture, and allow them to be randomized and/or bound to ship properties.
• Repeatability. I intend to add support for multiple light maps, of both types. Combined with property bindings, this will allow for things like engine and weapon glow maps.
• Template generation. There’s a  hidden setting to write the generated shaders to the log folder, so you can use the material model as a base for custom shaders.

The overall goal here is to allow most of the effects used by Griff’s ships to be done without custom shaders.

At the moment, the synthesizer is capable of generating diffuse and ambient lighting with support for normal and parallax mapping. Specular lighting and light maps are missing. I expect to have these finished this week and will enable the synthesizer in nightlies when they are done.

In the meantime, here’s what a synthesized fragment shader currently looks like. It’s terse, but hopefully a little less scary than the current template. (Note: the diffuse colour is swizzled so it’s visually obvious whether the synthesizer is in use.)

Code: Select all

// Uniforms
uniform sampler2D       uTexture0;


// Varyings
varying vec2            vTexCoords;
varying vec3            vLightVector;


void main(void)
{
    vec3 totalColor = vec3(0.0);
    
    vec2 texCoords = vTexCoords;
    
    // Texture lookups
    vec4 tex0Sample = texture2D(uTexture0, texCoords);  // cobra3_redux.png
    
    vec3 diffuseColor = tex0Sample.bgr;
    
    vec3 lightVector = normalize(vLightVector);
    
    // Diffuse (Lambertian) and ambient lighting
    vec3 diffuseLight = (gl_LightSource[1].diffuse * max(0.0, lightVector.z) + gl_LightModel.ambient).rgb;
    
    totalColor += diffuseColor * diffuseLight;
    gl_FragColor = vec4(totalColor, 1.0);
}

[JensAyton]

The overall goal here is to allow most of the effects used by Griff’s ships to be done without custom shaders.

I’d like to highlight the fact that this is awesome. :-)

Specular lighting is now implemented. Separate parallax_map, specular_color_map and specular_exponent_map too. Also, specular_exponent has been introduced as a preferred synonym of shininess; it’s nerdier, but helps highlight the relationships between attributes.

I need to think a bit about how to handle the light maps in a way that’s both backwards-compatible and flexible.

[JensAyton]

The new shader synthesizer is now at feature parity with the old system. (There are some missing translation cases for things like solid glow colours without a light map, but I don’t think anyone uses that.) It will be active in the next nightlies (r4776 or later).

When the shader synthesizer is active, the built-in player Cobra Mk. III (shown on the startup screen) is pink.

Modders who make ships which don’t use custom shaders are requested to test them in upcoming nightlies. There may be warnings about textures being used more than once in the same ship; these are not a problem and will be rectified soon.

For the curious, you can dump the synthesized shaders by setting the  hidden setting dump-synthesized-shaders – they will appear in a folder called “Synthesized Materials” beside the log.

The new attributes specular_color_map, specular_exponent_map, specular_exponent and parallax_map, as well as swizzling, are supported.

Previously, I’ve said that illumination_map is slightly less efficient than emission_map. This is not the case with the new synthesizer, although illumination maps do still involve extra work in non-shader mode.

[JensAyton]

I forgot to say, the heat glow effect isn’t implemented yet.

[JensAyton]

Q&A (or at least Q) about the new material stuff has been split to a new topic.

[Kaks]

In the meantime... err, I mean a couple of months later:

New planets are live-ish! I don't think there are many major problems left with the new planets code - (well, there's an annoying memleak which I left in for the moment to avoid a more annoying CTD) but we're getting there. I've enabled them in the trunk builds, so you can have a quick look if you want to.

Next steps: trying to improve on the speed of the planet generation code, getting a materials dictionary inside planetinfo.plist to work properly (based on submersible's work of course), and getting Oolite to create a light map based on tech level / economy type.

Still, I just wanted to say there's a few fairly pretty OoPlanets out there, if I may say so myself!
Please feel free to post in the screenshots thread if there's any that take your fancy:D

[m4r35n357]

Is this subject to debate

No. We’ve had the debate, at length, and the decision reached was to make this change after the next stable release (i.e., 1.76).

Yes, I remember the debate, ISTR it concerned the proposed Oolite 2 branch. AIUI the latest proposal is to get rid of the energy bomb in the 1.x branch, which I consider a major difference.
So will it be feasible to maintain a source tree containing the energy bomb, ie can we have a definitive statement of the final SVN revision for which it is possible to enable the energy bomb?

[Kaks]

If you have access to the source code and can compile it, you can do whatever you like with it. That's the major point of open source.

Therefore: it's very feasible to maintain a source tree with energy bombs enabled, and most of your questions don't compute: it's impossible to give 'definitive statements' on when it's possible or not for anyone to enable energy bombs. It'll always be possible to do so (and it'll always be possible to add/remove any arbitrary features to Oolite), as long as you know what you're doing.

However, here's a final statement, one it's been made before, and 'a few times' already:

1.76.x is the last version in which the energy bomb is enabled & supported within Oolite.

1.77 and above will not have energy bombs enabled, due to the availability of many, many other alternative weapons.
Energy bomb usage is not supported after 1.76.x and - in my own case - it's actively discouraged. Other developers might have different ideas about 'actively discouraged', though!