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 wrote:Is this subject to debate
Progress
Moderators: winston, another_commander
- JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
Re: Progress
E-mail: [email protected]
Re: Progress
OK, sad times, but at least I can keep 1.76 as a retro retro game . . . .Ahruman wrote: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 wrote:Is this subject to debate
OXPs: Furball 1.8, Factions 1.12
- JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
Re: Progress
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.
E-mail: [email protected]
Re: Progress
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.
"A brilliant game of blasting and trading... Truly a mega-game... The game of a lifetime."
(Gold Medal Award, Zzap!64 May 1985).
(Gold Medal Award, Zzap!64 May 1985).
- JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
Re: Progress
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.)Gimi wrote:Is the Q-bomb installed internally, and available on the tab-key?
E-mail: [email protected]
- Commander McLane
- ---- E L I T E ----
- Posts: 9520
- Joined: Thu Dec 14, 2006 9:08 am
- Location: a Hacker Outpost in a moderately remote area
- Contact:
Re: Progress
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.Ahruman wrote:it shouldn’t be hard to make an energy bomb OXP.)
Re: Progress
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).
My OXPs via Boxspace or from my Wiki pages .
Thargoid TV
Dropbox Referral Link
Thargoid TV
Dropbox Referral Link
- JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
Re: Progress
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:
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.)
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 asrgb
. 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 usingextract_channel = "rgg"
.) Unlike the existingextract_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
orspecular_map
(which requires you to combine specular intensity and specular exponent terms). There will be newparallax_map
,specular_intensity_map
specular_color_map
andspecular_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.
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);
}
E-mail: [email protected]
- JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
Re: Progress
I’d like to highlight the fact that this is awesome. :-)Ahruman wrote:The overall goal here is to allow most of the effects used by Griff’s ships to be done without custom shaders.
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.
E-mail: [email protected]
- JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
Re: Progress
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
The new attributes
Previously, I’ve said that
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.E-mail: [email protected]
- JensAyton
- Grand Admiral Emeritus
- Posts: 6657
- Joined: Sat Apr 02, 2005 2:43 pm
- Location: Sweden
- Contact:
Re: Progress
Q&A (or at least Q) about the new material stuff has been split to a new topic.
E-mail: [email protected]
Re: Progress
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
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
Hey, free OXPs: farsun v1.05 & tty v0.5! :0)
Re: Progress
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.Ahruman wrote: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 wrote:Is this subject to debate
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?
OXPs: Furball 1.8, Factions 1.12
Re: Progress
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!
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!
Hey, free OXPs: farsun v1.05 & tty v0.5! :0)