Split: Re-scaling experiment

General discussion for players of Oolite.

Moderators: another_commander, winston

User avatar
Redspear
---- E L I T E ----
---- E L I T E ----
Posts: 1520
Joined: Thu Jun 20, 2013 10:22 pm

Re: Split: Re-scaling experiment

Post by Redspear »

FWIW, if you want to try lots of different oxps with the rescaling project then the safest way is to deactivate both rescale_plus and recsale_modest. Here's what you'll lose however...

If you use rescale_modest instead of rescale_plus then you will lose the bulk of the reduction to masslock durations.

If you use neither of the rescale oxps then you will also lose the increased variation in ship sizes.

another_commander wrote:
Thu May 28, 2020 1:48 pm
Redspear wrote:
Thu May 28, 2020 1:33 pm
I did try them out (as you posted in the progress thread) but likely I need to update elsewhere as they displayed in monochrome.
If they (and by they I expect you mean the ships and that you are referring to the oolite-default-shader.fragment) displayed in monochrome, then there was an editing error that prevented the shader from compiling. Latest.log should have a message with the line that killed the shader.
Sorry I wasn't clear, I meant ships, stations, etc.

When I get to try again, I'll report back.
"With our thoughts, we make the world" :-) - - - Game too slow for you? Masslock Compensators - - - Trouble getting out of trouble? Indestructible Injectors

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

Re: Split: Re-scaling experiment

Post by another_commander »

Probably I should have been clearer myself: Ships, stations, asteroids etc. are all controlled by oolite-default-shader.fragment. I have seen for myself them being displayed in b/w and every time I saw that it was because of a syntax error in the shader that was causing it to fail to compile.

The only things that you will want to change in those latest shaders are 1) the cosThreshold equation in oolite-default-atmosphere.fragment so that it matches the values you are using and 2) the numbers for MULTIPLIER_LIGHTSRCRADIANCE and MULITPLIER_EXPOSURE in oolite-default-planet.fragment and oolite-default-shader.fragment. It is recommended that you use the same radiance and exposure values for both shaders. Values like 3.0 and 2.0 respectively seem to have good initial results, but you are welcome to experiment and find a combination that works best for you.

User avatar
Redspear
---- E L I T E ----
---- E L I T E ----
Posts: 1520
Joined: Thu Jun 20, 2013 10:22 pm

Re: Split: Re-scaling experiment

Post by Redspear »

another_commander wrote:
Thu May 28, 2020 2:48 pm
It is recommended that you use the same radiance and exposure values for both shaders.
Presumably this is for a sense of visual consistency rather than to prevent anything from 'breaking'?

another_commander wrote:
Thu May 28, 2020 2:48 pm
Values like 3.0 and 2.0 respectively seem to have good initial results, but you are welcome to experiment and find a combination that works best for you.
Had a quick play with the default shader alone without any problems. Finding so far that I prefer to swap the suggested 3.0 and the 2.0 values around. I may post pics to make my case for that later but first I'll see what happens with the planet fragment file involved as well.
"With our thoughts, we make the world" :-) - - - Game too slow for you? Masslock Compensators - - - Trouble getting out of trouble? Indestructible Injectors

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

Re: Split: Re-scaling experiment

Post by another_commander »

Redspear wrote:
Thu May 28, 2020 6:04 pm
Presumably this is for a sense of visual consistency rather than to prevent anything from 'breaking'?
Correct. You can set the values as you see fit without restriction, but it makes good sense to have the same radiances and exposures across the board, since both the object and the planet shaders use the same light models. The atmosphere shader values are exempt and can be set to really anything you like, as long as the result is pleasing to the eye, because atmosphere is essentially an effect, not an actual lit object. I am keeping it around 1.2 - 1.25 for my setup.

User avatar
Redspear
---- E L I T E ----
---- E L I T E ----
Posts: 1520
Joined: Thu Jun 20, 2013 10:22 pm

Re: Split: Re-scaling experiment

Post by Redspear »

another_commander wrote:
Thu May 28, 2020 6:34 pm
The atmosphere shader values are exempt and can be set to really anything you like, as long as the result is pleasing to the eye, because atmosphere is essentially an effect, not an actual lit object.
Does it not follow then that, to enhance the atmosphere effect, there might be a less raw lighting for the planet than there would be for ships and stations? In other words I would have thought that there is a case for a small but significant difference in terms of lighting anything without an atmosphere.

Again it's very early days for me but I'm finding that a reduced exposure value for planets (compared to ships) is helpful.
"With our thoughts, we make the world" :-) - - - Game too slow for you? Masslock Compensators - - - Trouble getting out of trouble? Indestructible Injectors

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

Re: Split: Re-scaling experiment

Post by another_commander »

Redspear wrote:
Thu May 28, 2020 6:45 pm
Again it's very early days for me but I'm finding that a reduced exposure value for planets (compared to ships) is helpful.
Totally up to you to select your preferred values. The objective of these shaders is to have a good looking game and since we can change their contents without having to rebuild the binary, they can be used just like any other configuration file in the game. The only thing to remember is that planets and objects use the same light model, i.e. same lighting equations, while atmospheres have a separate implementation and they use a different set of equations to the rest.

User avatar
Redspear
---- E L I T E ----
---- E L I T E ----
Posts: 1520
Joined: Thu Jun 20, 2013 10:22 pm

Re: Split: Re-scaling experiment

Post by Redspear »

another_commander wrote:
Thu May 28, 2020 6:52 pm
Totally up to you to select your preferred values. The objective of these shaders is to have a good looking game and since we can change their contents without having to rebuild the binary, they can be used just like any other configuration file in the game
Yes, that's the great thing about it.

Perhaps because planets are round and huge, whilst ships are typically flat and small, I'm finding that considerably different values for the two look best.

Radiance has a tendency to wash out some of the current default planet textures, or to catch a flat surface on a ship (almost an entire side in some cases) and reflect fiercely. Exposure is more useful for illuminating the hidden, and so finally I can reveal more of hidden ships than I can of the dark side of planets.

As might be usual for me, this might sound rather strange but it is both more playable IMHO and makes more sense when you consider multiple light sources. Programming wise there's only the star that illuminates entities other than itself, however gameplay suggests otherwise.

For example, pitch black ships heading into a docking bay that is lit up like a Christmas tree don't really make sense until one remembers that there's only one light source. Up exposure too much and it looks equally ridiculous however (and more often). Still, minds as well as eyes all work slightly differently I suppose...

Are there any plans to add these setings to Game Options on the f2 screen?
"With our thoughts, we make the world" :-) - - - Game too slow for you? Masslock Compensators - - - Trouble getting out of trouble? Indestructible Injectors

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

Re: Split: Re-scaling experiment

Post by another_commander »

Redspear wrote:
Fri May 29, 2020 9:01 pm

For example, pitch black ships heading into a docking bay that is lit up like a Christmas tree don't really make sense until one remembers that there's only one light source. Up exposure too much and it looks equally ridiculous however (and more often). Still, minds as well as eyes all work slightly differently I suppose...
Yup, it would be nice to implement multiple light sources at some point in the future. Also environment mapping (for reflections and image-based lighting) and shadows ,which would be what is needed to bring the in-game lighting to photorealistic levels. Until such time, we will still have to suspend our disbelief in a few places and accept some inherent weirdness here and there. Unfortunately, all the above need - beyond good glsl knowledge - changes to the core of how we do rendering and that ramps up the difficulty a lot, Ideally we need a render-to-framebuffer implementatoin. If there are any graphics wizards out there, this is your call, go for it.
Are there any plans to add these setings to Game Options on the f2 screen?
This is the next logical step in the implementation. Or rather, the third one. The second step would be to turn these multipliers in the shaders to uniforms, so that the core game can send values at will, instead of the values being constants and unchangeable unless you quit the game, edit the shaders and restart. Or alternativelyr, modify the existing sun_color key in shipdata.plist to accept colors with rgb components higher than 1.0,. e.g. sun_color = "15,0, 12.0, 14.0, 1.0";, so instead of multipliers you would supply actual radiance values. Normal RL resumes from Monday on for me, so I know I will not have time to do this. Again, for any graphics wizards out there, this is your call yada yada you know the drill.

User avatar
Redspear
---- E L I T E ----
---- E L I T E ----
Posts: 1520
Joined: Thu Jun 20, 2013 10:22 pm

Re: Split: Re-scaling experiment

Post by Redspear »

another_commander wrote:
Sat May 30, 2020 6:18 am
Normal RL resumes from Monday on for me, so I know I will not have time to do this. Again, for any graphics wizards out there, this is your call yada yada you know the drill.
Well, thank you for the changes you have made recently. Lighting is in a much better state of affairs now and can be adjusted to suit personal taste.

Sadly, I'm not even much of a graphics apprentice but then when I first came here I hardly thought I'd be capable of rescaling the thing...

Don't hold your breath on my account ;) , there are more pressing features on my personal list of things to tinker with.
"With our thoughts, we make the world" :-) - - - Game too slow for you? Masslock Compensators - - - Trouble getting out of trouble? Indestructible Injectors

gizmo
Deadly
Deadly
Posts: 157
Joined: Mon Nov 22, 2010 2:40 pm
Location: aboard the "Kiss of Time"

Re: Split: Re-scaling experiment

Post by gizmo »

Playing the rescaled Oolite I rarely run across other ships.
Even in systems with more than 1.000 entities (according to an entity dump) I usually only see assassins luriking at the witchpoint.

User avatar
Redspear
---- E L I T E ----
---- E L I T E ----
Posts: 1520
Joined: Thu Jun 20, 2013 10:22 pm

Re: Split: Re-scaling experiment

Post by Redspear »

gizmo wrote:
Mon Jun 01, 2020 4:35 pm
Playing the rescaled Oolite I rarely run across other ships.
Even in systems with more than 1.000 entities (according to an entity dump) I usually only see assassins luriking at the witchpoint.
Interesting as that's not my experience...

Key setting here is lane width - wider lane, less mass locks (bear in mind that it's a square of the width however). So if you're compiling it yourself then it's a simple thing to tinker with.

Have you got population control oxp installed by any chance?
"With our thoughts, we make the world" :-) - - - Game too slow for you? Masslock Compensators - - - Trouble getting out of trouble? Indestructible Injectors

gizmo
Deadly
Deadly
Posts: 157
Joined: Mon Nov 22, 2010 2:40 pm
Location: aboard the "Kiss of Time"

Re: Split: Re-scaling experiment

Post by gizmo »

Key setting here is lane width - wider lane, less mass locks (bear in mind that it's a square of the width however). So if you're compiling it yourself then it's a simple thing to tinker with.
I'll tinker with the lane width and see what happens.
Have you got population control oxp installed by any chance?
Not that I'm aware of.

I have the following OXPs active:
Basic-debug
Beercooler
BGS
BountyScanner
comms-pack-a
CompressedF7Layout
Contracted_Goods_Reminder
countdown_to_zero
cup_of_tea
CustomShields
Deep_Horizon_Nav_Buoy
Delightful Docking
DisplayCurrentCourse
escort-formations
GalacticRegistry
GalDrivePod
GNN
HUD Vanisher
Illegal_Goods_Tweak
Library
NSGMaps
PoliceIFFScanner
Randomshipnames
Redspear_HUD
Rescale_Plus
ReverseControl
ShipsCat
StationDockControl
Status_Quo_QW-bomb
SystemDataConfig
WelcomeMat

User avatar
Redspear
---- E L I T E ----
---- E L I T E ----
Posts: 1520
Joined: Thu Jun 20, 2013 10:22 pm

Re: Split: Re-scaling experiment

Post by Redspear »

Can't say I'm familiar with all of those oxps but nothing jumps out at me as problematic.

Re Lane width... It has been adjusted to mathematically match both the new scanner and the longer space lane, so it should be correct. If however, you want to increase encounters then you'll need to reduce lane width. So it's in effect the same number of 'fish' but in a smaller 'tank'.

I hope that makes sense and if you need any further help then of course just ask :-)
"With our thoughts, we make the world" :-) - - - Game too slow for you? Masslock Compensators - - - Trouble getting out of trouble? Indestructible Injectors

Post Reply