Progress

[another_commander]

In today's nightly we will have a few more changes to the rendering system.

First of all, shininess is no longer the way to denote glossiness for materials. Shininess is supposed to be an expression for the specular exponent, which is not the same as glossiness. We have used it till now because it was easy to do so and required no additional coding in the core. But... as you can imagine, there are some issues with it. For starters, shininess can be an integer only value form 0 to 128. Aside from the fact that this scale is not exactly convenient, the main problem is that only integers are allowed. We have 129 distinct steps in this scale and nothing in-between.

So, now we can have two new additional property for our material (standard and shader) definitions. The first one is, unsurprisingly, "gloss", which is clamped from 0.0 to 1.0 and actually expresses glossiness or, if you prefer, lack of roughness of the material. The default value for this property is 0.375 for standard materials and 0.5 for shader ones. Gloss values like 0.6477 are now fine, which is something we could not do before with shininess.

The second property is "ior", whcih stands for Index of Refraction. This affects the specular light calculation and it allows us to establish a basic implementation for energy conservation of light. This means that the energy of the light we see coming from the direction of an object (reflected and refracted) is equal to the energy of the light that hit the object in the first place. In other words, things should look even better now. The default value for this property is 1.0 and it cannot be a negative number.

With the addition of those two, we should now have pretty much all the control we need in order to create materials that look as realistic as possible. There are some more things that I would like to see happening in the rendering system before I can color me happy (shadows and environment mapping come to mind), but I hope this is going to be a good start.

[Griff]

Amazing work on these rendering improvements, those metal examples in the screenshots thread are pretty awesome!

[tokugawa]

Looks slick, I gave it a try. And I'm happy to report that

https://github.com/OoliteProject/oolite ... gment#L355

float f0SqRt = ((1 - uIOR) / (1 + uIOR));
changed to
float f0SqRt = ((1.0 - uIOR) / (1.0 + uIOR));

works on little older GLSL too

[another_commander]

Thanks for the input tokugawa, much appreciated. In any case, it looks like with the latest trunk energy conservation changes, IOR may no longer be required (and it is not used in the latest nightly) so the line causing problems for older cards may be removed soon.

[Nite Owl]

Older versions of OpenGL (OpenGL renderer version: 4.6.0 on a GeForce GTX 750 Ti) have a problem with the f suffix and the variable eyeVector in this latest version of oolite-default-shader.fragment as shown here.

Code: Select all

Latest Log:
0(194) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals in versions below 120
0(194) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals in versions below 120
0(195) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals in versions below 120
0(195) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals in versions below 120
0(195) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals in versions below 120
0(198) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals in versions below 120
0(198) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals in versions below 120
0(199) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals in versions below 120
0(199) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals in versions below 120
0(202) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals in versions below 120
0(203) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals in versions below 120
0(203) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals in versions below 120
0(208) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals in versions below 120
0(209) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals in versions below 120
0(210) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals in versions below 120
0(211) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals in versions below 120
0(214) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals in versions below 120
0(345) : warning C7502: OpenGL does not allow type suffix 'f' on constant literals in versions below 120
0(291) : error C1008: undefined variable "eyeVector"

Since the Latest Log was kind enough to provide the line numbers removing the offending suffixes and variable was not a problem even for a novice coder like myself. Unfortunately many players with older versions of OpenGL (when grabbing a future stable release) may not be so inclined to fiddle with such code. Using the latest stable version of Oolite here (v1.86). All seems to be working as planned with the latest lighting/shader improvements in place even with the above variables removed. Cannot be 100% sure of that as there is no way of comparing to what things might look like if the variables had remained in place since oolite-default-shader.fragment will not load at all unless the above suffixes and variable are removed. No option to upgrade my GPU at the moment as cash is rather tight. Enjoying the improvements none the less but wondering how much better things might be without the removal of these suffixes and the variable.

[another_commander]

Removal of the error line may fix the shader, but it destroys the effect, as the halfVector variable, calculated at the point of error, is an absolitely required one for all the new light calculations. The shader will not work as expected in 1.86 anyway, becasue the binary does not know how to handle the gloss shader uniform and you only get ships without gloss at all. I suggest switching to the latest trunk if you want to have a chance of seeing what the new lighting is about.

Regarding the errors themselves, I'll try to remove all the f's from the float numbers - I think that should not be a problem. For the eyeVector definition, if it persists with trunk, try running the game with shift down so that all material dictionaries in the cache get rebuilt. The default shadder should be defining OOSTD_SPECULAR, the absense of which seems to be the reason for the error.

[Nite Owl]

It's all academic since Stable Version 1.86 is in use but here goes anyway.

Removing just the f's does work. As to the eyeVector variable. The original line 291 was as follows:

Code: Select all

vec3 halfVector = normalize(lightVector + eyeVector);

This was tweaked to remove only the eyeVector variable resulting in this:

Code: Select all

vec3 halfVector = normalize(lightVector);

Both of these tweaks will allow the new oolite-default-shader.fragment to load in v1.86 with an older version of OpenGL. As for the usual "Shift Key - Reload It All" step that happens every time Oolite starts as my .GNUstepDefaults is tweaked to force this as default behavior. Takes a bit longer to load the game but it saves a minor bit of hassle when tweaking files with a forgetful brain.

A noticeable difference in the lighting effects was evident once both of these tweaks were made to the updated oolite-default-shader.fragment with stable v1.86 even if it was not the full effect. Of particular note is the way light moves across the hull of a ship while it is in motion which is easily identified with the spinning ship in the Ship Respray OXZ. Liking the way things look even if it is not the full effect.

To Trunk Or Not To Trunk, That Is The Question.

[cbr]

During an occasional read(ing), i found some 'shader' errors in the latest log.

Code: Select all

15:03:37.139 [shader.load.failed]: ***** ERROR: Could not build shader oolite-tangent-space-vertex.vertex/oolite-default-shader.fragment.
15:03:37.145 [material.synthesize.loop]: Synthesis loop for material Hull.
  15:03:37.392 [shader.compile.failure]: ***** ERROR: GLSL fragment shader compilation failed for oolite-default-shader.fragment:
>>>>> GLSL log:
0:355(26): error: could not implicitly convert operands to arithmetic operator
0:355(39): error: could not implicitly convert operands to arithmetic operator
0:355(40): error: operands to arithmetic operators must be numeric


15:03:37.393 [shader.load.failed]: ***** ERROR: Could not build shader oolite-tangent-space-vertex.vertex/oolite-default-shader.fragment.
15:03:37.393 [material.synthesize.loop]: Synthesis loop for material oolite_coriolis_diffuse.png.
  15:03:38.354 [shader.compile.failure]: ***** ERROR: GLSL fragment shader compilation failed for oolite-default-shader.fragment:
>>>>> GLSL log:
0:355(26): error: could not implicitly convert operands to arithmetic operator
0:355(39): error: could not implicitly convert operands to arithmetic operator
0:355(40): error: operands to arithmetic operators must be numeric

oolite trunk 1.87.0.7108

[another_commander]

Removing just the f's does work. As to the eyeVector variable. The original line 291 was as follows:

Code: Select all

vec3 halfVector = normalize(lightVector + eyeVector);

This was tweaked to remove only the eyeVector variable resulting in this:

Code: Select all

vec3 halfVector = normalize(lightVector);

The "fixed" code is in reality incorrect. The halfVector is not the same thing as a normalized lightVector - its direction and magnitude are different. How visible is the error? Not sure, but what you are seeing is certainly not what was intended.

To Trunk Or Not To Trunk, That Is The Question.

To Trunk. Definitely. Especially since you can install it alongside 1.86 without one installation affecting the other and especially since current trunk is so, so far ahead of 1.86.

[another_commander]

During an occasional read(ing), i found some 'shader' errors in the latest log.

Code: Select all

15:03:37.139 [shader.load.failed]: ***** ERROR: Could not build shader oolite-tangent-space-vertex.vertex/oolite-default-shader.fragment.
15:03:37.145 [material.synthesize.loop]: Synthesis loop for material Hull.
  15:03:37.392 [shader.compile.failure]: ***** ERROR: GLSL fragment shader compilation failed for oolite-default-shader.fragment:
>>>>> GLSL log:
0:355(26): error: could not implicitly convert operands to arithmetic operator
0:355(39): error: could not implicitly convert operands to arithmetic operator
0:355(40): error: operands to arithmetic operators must be numeric


15:03:37.393 [shader.load.failed]: ***** ERROR: Could not build shader oolite-tangent-space-vertex.vertex/oolite-default-shader.fragment.
15:03:37.393 [material.synthesize.loop]: Synthesis loop for material oolite_coriolis_diffuse.png.
  15:03:38.354 [shader.compile.failure]: ***** ERROR: GLSL fragment shader compilation failed for oolite-default-shader.fragment:
>>>>> GLSL log:
0:355(26): error: could not implicitly convert operands to arithmetic operator
0:355(39): error: could not implicitly convert operands to arithmetic operator
0:355(40): error: operands to arithmetic operators must be numeric

oolite trunk 1.87.0.7108

Thanks for the report. This will be fixed once the IOR (now redundant) code has been removed.

[another_commander]

Check out the new atmosphere shader coming up in the next nightly. Here are some before / after pics:















Note that the atmosphere does not fade out when far from the planet. It looks good enough to not be any need for it.

[Svengali]

Looks really good, a_c!

And I do have a question about your answer in the Screenshot topic.

Nice! Does this mean that blending is only available for visual effects? And that they are drawn after all of the other, usual, 'solid' entities?

Yes, at the moment blending is deliberately limited to visual effects only. These are drawn during the opaque rendering pass, by momentarily tricking the system and switching blending on for just about the time needed to complete rendering the visual effect mesh and switching it off again to continue with the next object in the opaque pass list.

Can you tell us a bit about the future plan for the blending? It's such a nice feature and I really would like to (mis)use it at some point. I know that Oolite is in feature freeze and it's all future music, but it would be good to know a bit more (e.g. own render pass, disable CULL_FACE, control settings in effectdata.plist, etc).

After all, anticipation is already half the fun.-)

[Cody]

Thanks, Devs! Oolite 1.88 installed and looking good!

[Svengali]

Yes! Muchas gracias and congrats for the new version!

[another_commander]

Can you tell us a bit about the future plan for the blending? It's such a nice feature and I really would like to (mis)use it at some point. I know that Oolite is in feature freeze and it's all future music, but it would be good to know a bit more (e.g. own render pass, disable CULL_FACE, control settings in effectdata.plist, etc).

After all, anticipation is already half the fun.-)

To be honest, I don't really have a future plan about blending. The objective of the exercise was to enable transparency in effects and that's it. I don't know if there is a point in trying to enable transparency on non-effect entities (maybe that would not be too difficult), but anything else will have to overcome two somewhat important issues:
1. I am not really that familiar with the game's rendering system. Any change like those you mentioned would require some additional studying and digging into the lowest-level internals of the code base before I even consider attempting it.
2. Oolite has a really robust internal system for checking its render state while drawing a frame or parts of it. If it detects an inconsistent or unexpected change of rendering parameters at any time, it will a) report the state it found and the state it was expecting to find and b) switch OpenGL settings to match the expected state. Therefore, before attempting anything low-level, this will have to be tamed somehow and that would add even more effort. Not impossible (we did manage to trick the system with effects transparency after all), but certainly no trivial task. And maybe we should not adopt a habit of applying hacks like I did either. The transparency was a one-off; if more is to be done, it should probably be handled properly by setting up the system to know what to expect..

Still, if anyone feels like diving in and coming up with a patch to improve rendering even further, I would certainly not object.