Split: Re-scaling experiment

[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.

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.

[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.

[Redspear]

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'?

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.

[another_commander]

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.

[Redspear]

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.

[another_commander]

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.

[Redspear]

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?

[another_commander]

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.

[Redspear]

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.

[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.

[Redspear]

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?

[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

[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

[Redspear]

A bit on relative ship sizes (nice to be able to talk about a conceptual issue rather than a coding one )...

TLDR: ignoring the ship dimensions I based size on description and made a table (see below)

A reminder for anyone who's new here: this thread isn't about trying to rationalise scales in oolite (honest! ) but rather trying to hide their glaring irregularities whilst playing the game.

Here's a link from the Ian Bell website that purportedly represents the guide notes he wrote for the Elite player's manual.

There's a few little gems in there that didn't make it into the finished product (moray pilots with latinised 'fish fingers', how many missiles can a mamba carry? 2) or were just reworded slightly such as was the case for this entry:

ORBIT SHUTTLES
are large unarmed craft which run cargo between the planet and its orbitting space stations. The naughty old player can shoot these and reap a rich harvest of cargo canisters. Of course, the space station might have something to say about it....

Large? It's amongst the smallest by recorded dimensions, about the size of a worm (in game worm, not the garden variety).

From the manual this time:

ORBIT SHUTTLES
These unarmed and often unmanned craft are built under license in every planetary system. Based on a prototype developed by Saud-Kruger AstroDesign, they are used for cargo ferrying between planet and space station, but can be modified to hospital ships, or orbiting prisons. Favorite targets for small-time criminals, because of their instantaneous release of cargo canisters, they are often followed by single fighter patrol ships.

Orbiting prison? Hospital (not medical) ship? and with 60TC capacity (as recorded in elite manual) and a crew of 6. This thing should be pretty big shouldn't it?

What if I completely ignored the recorded dimensions of the ships and instead focused on their descriptions, could size be reassessed almost entirely?

A strict formula is likely to be so debatable as to be of questionable utility but a guideline of some sort might help.

It can carry up to 100 passengers, and has a cargo capacity of 10 tonnes undefined bulk.

Interpeting this sentence from the manual to mean that 1TC storage soace can accomodate up to 10 passengers, I now have a guide.
OK, so they're Gal Tonnes and not necessarily metric tonnes but given the use of grams and kilograms in the 4th millenium, I'm guessing it's not too far away. Besides, it doesn't need to be accurate, just proportianal and functional.

Furthermore I'll be assuming that extra crew means extra equipment, both of which will take up extra space. Equipment could be enormouisly variable (and perhaps automated for the presumably solo pilot in oolite) but again, for convenience I'll be assuming that each crew member after the first (plus the equipment they're supervising) is equivalent to 2TC.

Minor adjustments for weapon references and presence/absence of a hyperdrive and what would we get?

Maybe something like this :



Remarks are all from the manual or Ian Bell's notes.
I've marked any changes I've made in red and they are as follows.

Krait and Mamba

10TC seems quite a lot for a 'one man fighter', especially with the mamba having space added as an afterthought. For comparison the cobra mk I trading vessel has the same ammount of cargo space and (unlike either of these two) a hyperdrive. I'm going with either an unlikelt '1.0 TC' or a (perhaps only slightly less unlikely) '1o TC' with an ornate full stop eventually making it into a zero. Remember: this isn't a search for truth on my part but rather convenience and a more varied and interesting ship population.

Anaconda

Was it 750 TC? Could it have been 250 TC? Or, perhaps more likely, 150 TC?
Python: 100 TC
Boa: 125 TC
Anaconda: ?
Personally, I think 150 fits best given that they're all supposed to be able to dock within a slot that was (in Elite) the bane of inexperienced cobra pilots.

Crude size

Of questionable merit this one when it comes to game sizes but I'm not trying to represent things accurately (with those numbers how could an anaconda pilot ever be expected to scoop a cargo pod?), just to hide the fact that I'm cheating. Maybe once we get to the largest vessels I could reduce or ignore the modifier for crew. Not every crew member need be attending to an essential piloting function. Announcers on an anaconda, 'butlers' on a fer de lance, doctors/prison guards on a shuttle.

Anyway, I'm not quite sure what I'm going to do with this yet but I do quite like the idea of some orbital prisons and hospitals popping up, perhaps with an AI that remains stationary until attacked (escorts perhaps?) And one man fighters that are actually small (costing them an energy bank or two I suspect).

[Cody]

Re the Anaconda: doesn't the (possibly apocryphal) story say that a coffee stain made 150 look like 750?