Progress

General discussion for players of Oolite.

Moderators: winston, another_commander

another_commander
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 6671
Joined: Wed Feb 28, 2007 7:54 am

Re: Progress

Post by 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.
User avatar
Griff
Oolite 2 Art Director
Oolite 2 Art Director
Posts: 2482
Joined: Fri Jul 14, 2006 12:29 pm
Location: Probably hugging his Air Fryer

Re: Progress

Post by Griff »

Amazing work on these rendering improvements, those metal examples in the screenshots thread are pretty awesome!
tokugawa
Average
Average
Posts: 12
Joined: Fri Sep 01, 2006 12:51 am
Location: Wroclaw, Poland

Re: Progress

Post by 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
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 6671
Joined: Wed Feb 28, 2007 7:54 am

Re: Progress

Post by 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.
User avatar
Nite Owl
---- E L I T E ----
---- E L I T E ----
Posts: 556
Joined: Sat Jan 20, 2018 4:08 pm
Location: In The Dark

Re: Progress

Post by 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.
Humor is the second most subjective thing on the planet

Brevity is the soul of wit and vulgarity is wit's downfall

Good Night and Good Luck - Read You Soon
another_commander
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 6671
Joined: Wed Feb 28, 2007 7:54 am

Re: Progress

Post by 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.
User avatar
Nite Owl
---- E L I T E ----
---- E L I T E ----
Posts: 556
Joined: Sat Jan 20, 2018 4:08 pm
Location: In The Dark

Re: Progress

Post by 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.
Humor is the second most subjective thing on the planet

Brevity is the soul of wit and vulgarity is wit's downfall

Good Night and Good Luck - Read You Soon
User avatar
cbr
---- E L I T E ----
---- E L I T E ----
Posts: 1420
Joined: Thu Aug 27, 2015 4:24 pm

Re: Progress

Post by 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
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 6671
Joined: Wed Feb 28, 2007 7:54 am

Re: Progress

Post by another_commander »

Nite Owl wrote: Wed Aug 29, 2018 6:44 am
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
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 6671
Joined: Wed Feb 28, 2007 7:54 am

Re: Progress

Post by another_commander »

cbr wrote: Wed Aug 29, 2018 1:11 pm
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
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 6671
Joined: Wed Feb 28, 2007 7:54 am

Re: Progress

Post by another_commander »

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


Image
Image

Image
Image

Image
Image

Image
Image


Note that the atmosphere does not fade out when far from the planet. It looks good enough to not be any need for it. :-)
User avatar
Svengali
Commander
Commander
Posts: 2370
Joined: Sat Oct 20, 2007 2:52 pm

Re: Progress

Post by Svengali »

Looks really good, a_c!

And I do have a question about your answer in the Screenshot topic.
another_commander wrote: Sun Oct 07, 2018 8:24 pm
Mauiby de Fug wrote: Sun Oct 07, 2018 7:42 pm
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.-)
User avatar
Cody
Sharp Shooter Spam Assassin
Sharp Shooter Spam Assassin
Posts: 16081
Joined: Sat Jul 04, 2009 9:31 pm
Location: The Lizard's Claw
Contact:

Re: Progress

Post by Cody »

Thanks, Devs! Oolite 1.88 installed and looking good!
I would advise stilts for the quagmires, and camels for the snowy hills
And any survivors, their debts I will certainly pay. There's always a way!
User avatar
Svengali
Commander
Commander
Posts: 2370
Joined: Sat Oct 20, 2007 2:52 pm

Re: Progress

Post by Svengali »

Yes! Muchas gracias and congrats for the new version!
another_commander
Quite Grand Sub-Admiral
Quite Grand Sub-Admiral
Posts: 6671
Joined: Wed Feb 28, 2007 7:54 am

Re: Progress

Post by another_commander »

Svengali wrote: Thu Oct 25, 2018 12:11 pm
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. :-)
Post Reply