What is the dotted texture in the ore survey?

[MathmoRichard]

Because that's a single picture and not an album.

Use [noparse][/noparse] instead.

Thank you! What a noob I am.

Edited May 21, 2015 by MathmoRichard

[Harry Rhodan]

yNBUNo2

Click on the picture to get the direct link to the file. It has to look like this: [noparse][/noparse]

[KerikBalm]

The info is the same in all cases, it just looks different depending on a person's eyesight.

No, the displayed information is objectively different.

That the starting data, which isn't shown to the player, is the same, and then it gets processed in different ways - is entirely irrelevant

There could be a display that just shows 1 color for the entire planet - lets say it averages the data, before displaying 1 color for the whole sphere (more intense= more resources). The difference between this and the other modes wouldn't just be "a person's eyesight".

The way the data is processed before presenting information to the player is relevant, and the displayed information is significantly different.

* Ore concentration is defined per biome. It appears to be that every patch of biome with the same name will have the same concentration regardless of where it is on the planet.

This is not true (or you should phrase it better). There is local variation in abundance. Not all spots in the "east Farside crater" will be the same, even if they are the same biome.

In one game, the east farside crater may be a good spot, in another, it may not. It appears to be randomly generated, but with some rules (like ore is never found on a liquid biome, or the sun, or Jool).

The ground scanner only gives you a text reading of the concentration of the biome it is currently located in.

This is also not true (at the very least, the *only* part is wrong). The ground scanner seems to update the overlay (displayed in map view) with more accurate data.

In my current game, the initial scan showed the east farside crated was a good spot, and fairly uniform.

I landed, and used the ground scanner (you only use it once per biome), and it then it displayed a more blotchy distribution in the crater (and I landed in a bad spot).

Aside from that, it also seems to display the concentration at your specific coordinates, the biome you are in, and your specific coordinates.

First off, don't for a minute believe the "cut-off" value directly correlates to Ore concentration because you can have it only show 80% or greater when you know that really the max concentration is about 15%, maybe less. What the orbital overly is really saying is that the large general region it shows with a ridiculously higher cut-off value than the rest of the planet

I think it's displaying the % of maximum, so an 80% cutoff would mean an ore concentration cutoff of 12%, since 15% is the maximum? (12/15 = 0.8)

just has more of the high-concentration biome(s) located in it. It does NOT tell you which biomes those are, nor what their real concentrations are.

Again, other than excluding ore from certain biomes, I don't think it has anything to do with biomes.

The surface scanner just gives you higher resolution data for the biome it is in.

Because all patches of the same biome have the same concentration, it doesn't matter where on the planet that patch of biome is.

This is demonstrably not true.

I would take your entire post with a grain of salt.

[Murph]

I concur, the dotted view is showing a significantly different data set to the other 2 views. The difference is far more than the distance between a pair of dots, it can have nothing to do with the way the dot represents a larger square around it. Entire areas (containing many rows and columns of dots) light up that were entirely unlit in the other 2 views, and vice-versa with entire areas of dots going dark when you switch away from dot view.

Nothing to do with eyesight, nothing to do small error rates, nothing to do with sampling/averaging/precision/etc. It is either showing a significantly different data set, or has a significant error in the way that it is mapping the same data set onto the surface (an entirely different projection). One of the cases is showing highly incorrect data, but I have no idea if it's the dots that are wrong, or the other 2 that are wrong.

[KerikBalm]

Well, here is the relevant file for the overlays:

RESOURCE_OVERLAY_CONFIGURATION_SOLID

{

MapResolution = 256 //(Integer) should be power of 2

InterpolationLevel = 4 //(integer) 0+ - How many interpolation iterations to do

LoOpacity = 0.25 //(float) 0.0 to 1.0 - Opacity of overlay (lower bound)

HiOpacity = 0.50 //(float) 0.0 to 1.0 - Opacity of overlay (upper bound)

GridWeight = 0.5 //(float) 0.0 to 1.0 - How dark/light the grid is

LoColor = 0.01 //(float) 0.0 to 1.0 - Contrast level for monochrome

HiColor = 1.50 //(float) 1.0 to 2.0 - Contrast level for monochrome

CapPixels = 64 //(int) 0+ - Number of pixels to extrapolate polar caps

FilterMode = 2 //(Integer) 0=Point, 1=Bilinear, 2=Trilinear

}

RESOURCE_OVERLAY_CONFIGURATION_LINES

{

MapResolution = 256 //(Integer) should be power of 2

InterpolationLevel = 4 //(integer) 0+ - How many interpolation iterations to do

LoOpacity = 0.50 //(float) 0.0 to 1.0 - Opacity of overlay (lower bound)

HiOpacity = 0.75 //(float) 0.0 to 1.0 - Opacity of overlay (upper bound)

GridWeight = 0.5 //(float) 0.0 to 1.0 - How dark/light the grid is

LoColor = 0.01 //(float) 0.0 to 1.0 - Contrast level for monochrome

HiColor = 1.50 //(float) 1.0 to 2.0 - Contrast level for monochrome

CapPixels = 48 //(int) 0+ - Number of pixels to extrapolate polar caps

FilterMode = 2 //(Integer) 0=Point, 1=Bilinear, 2=Trilinear

}

RESOURCE_OVERLAY_CONFIGURATION_DOTS

{

MapResolution = 256 //(Integer) should be power of 2

InterpolationLevel = 3 //(integer) 0+ - How many interpolation iterations to do

LoOpacity = 0.75 //(float) 0.0 to 1.0 - Opacity of overlay (lower bound)

HiOpacity = 1.00 //(float) 0.0 to 1.0 - Opacity of overlay (upper bound)

GridWeight = 0.0 //(float) 0.0 to 1.0 - How dark/light the grid is

LoColor = 0.01 //(float) 0.0 to 1.0 - Contrast level for monochrome

HiColor = 1.50 //(float) 1.0 to 2.0 - Contrast level for monochrome

CapPixels = 0 //(int) 0+ - Number of pixels to extrapolate polar caps

FilterMode = 1 //(Integer) 0=Point, 1=Bilinear, 2=Trilinear

}

There are three major differences.... the filter mode, the Interpolation level, and cap pixels.

I think fewer interpolations will give more precise data, no? I'm not sure what an interpolation iteration is (interpolation itself is using a weighted average... could it iteratively average stuff until the whole planet displays as more or less the same?)

I'm not sure if filter mode has much effect other than the display.

As I previously remarked that the differences seem to be greater as one nears the poles, its interesting that there is a different value for "CapPixels", I don't know what it does exactly, but its related to the display for the polar caps, and that likely then affects the averaging and "smearing" further towards the equator.

[Bogeyman]

Sorry if I cut in here but since you are talking about it: I was wondering what the "Source" button at the bottom of the Narrow-Band-Scanner means? If you click on it, it does not change anything...

[MathmoRichard]

Thanks both for great replies!

Sorry if I cut in here but since you are talking about it: I was wondering what the "Source" button at the bottom of the Narrow-Band-Scanner means? If you click on it, it does not change anything...

I conjecture that this is for future use when we get different resources (water, breathable air etc.) appearing.

[MathmoRichard]

That much ore hey?

(This was a hang/crash, see also http://forum.kerbalspaceprogram.com/threads/122703-Hangs-Spins-Crashes.)

[RoverDude]

To hop in.

As the guy who wrote that code.

The same interpolation data is fed to the rendering engine. Precisely the same.

But dots/lines/splotches interpolate it in different ways by filling in different dots. Because they interpolate different things you will get slightly different patterns. These things are *shockingly* inaccurate. They just give you a rough idea of what is there. Hence the other scanners.

If you want to fiddle with the settings, by the way, you can.

And can get neat things like this (assuming you want to wait 20 seconds for a render on a high-end computer)

[Superfluous J]

These things are *shockingly* inaccurate. They just give you a rough idea of what is there. Hence the other scanners.

I'm cool with them being inaccurate. Even shockingly so. My problem is that they're inaccurate in different ways.

It'd be one thing if they were a little dimmer in one mode than the other, or one mode showed off a hotspot (that may be a phantom) that the other didn't. But these modes have vast swaths of area that are completely different. One is perfectly transparent while the other blazes in color, and the outlines are even suggestions of each other. It'd be like showing someone a map of Kerbin's coastlines, then Eve's coastlines, and saying "Yeah this map of Laythe is wildly inaccurate, but the data comes from the same place."

What you're saying here is that the maps are useless. I'm cool with that too. I assume once I ground truth everything they will become more useful. But maybe instead of showing data that is terribly useless but appears very accurate, you should just put "DATA IS USELESS AT THIS LEVEL OF ACCURACY. TRY DOING SURFACE READINGS." Or at least have some sort of confidence reading on the screen.

If the game said "Confidence 10%" then I'd know to not trust it. As it is, I assumed that if there was a huge 1/8th section of a planet' surface that was colored pretty brightly, then there would probalby be more ore in that 1/8th section than average. But then I switch modes and that 1/8th section is dark, telling me that on average it has less ore than the rest of the planet.

Again, I'm cool with the readings being wrong. I would just like them to all be wrong in the same way.

[RoverDude]

Let's be clear, since it seems you are putting words in my mouth. Perhaps a better term vs. inaccurate would be 'low resolution'. They are not by any stretch pixel perfect. But the data is not, in any way. 'Wrong'.

I explained, very nicely, that because the dots are in different places you will have some variance in the interpolation, but it should be very minor (unless you happen to ping a weird biome, like Kerbin's shores. But even then I get enough data for interpolation. They also have different levels of contrast (i.e. your monochrome displays vary by intensity but your heat maps vary by color). That I expect is what is causing you confusion. Your dark patch is probably at the low end of the monochrome threshold, but showing up a vivid green on the heat map (it's low-end threshold). There's a similar variance with lines vs dots vs solid, so again, I expect you have a visual/contrast concern.

Funny thing, in my save game just as a sanity check I did a resource comparison accross the mun with all three overlay types. The data result was pretty much the same regardless of what I picked. I did this accross about ten resources, and each one gave me an appropriate idea of where to place my base (turns out water was only in two craters... substrate was nearby one of these, so I landed, ground truth'd, and now have a fairly decent base after some poking around.

So to put this to bed. And again, this is coming from the guy that wrote the code.

The overlays use the same set of data points. Any variance you see is visual, and likely due to color intensity levels. But you're going to get roughly the same map no matter how you choose to visualize the data. But as noted, this data is not pixel perfect. It is not WRONG, it's just very low resolution, and gives you a pointer in the right direction. The narrow band scanner is the pixel perfect one (and also later in the tech tree).

Edited May 23, 2015 by RoverDude

[MathmoRichard]

different places you will have some variance in the interpolation, but it should be very minor

Firstly thanks for writing the code, I do love the new mining stuff! Really appreciate all the efforts that went into the game

My (our?) point is that I AM (we ARE) seeing very major differences. Btw I only ever use green/red, and have never spoken about a different scheme.

When the entire polar region of the mun, which has the the lowest concentration of ore on the entire body, is showing up as blanket red at the highest cut off level on red/green with the smooth or striped patterns, I'll need some convincing to see how the isn't "wrong".

I appreciate that it's just an interpolation but its code need re thinking if it can make vast areas of low concentration look like high, that just not any kind of averaging is it.

Javascript is disabled. View full album

Edited May 23, 2015 by MathmoRichard

[RoverDude]

Ahhh! What you're seeing there is polar pinching. It gets a bit wonky with interpolation because of how the poles pinch, etc.

Note that the rest of the planet is pretty much in-line.

(edit)

To add a bit more, the interpolation at the poles gets pretty extreme, because otherwise we end up with weird stretchy/smeared textures. That polar region is interpolated from a very tiny subset of data points - so one pixel off (especially as weird as the poles are anyway) and you get a different interpolation. This in turn affects the blending as you come off the poles.

If you want to see how this affects the different overlays, feel free to fiddle with your overlay config file - it has comments. Just be sure to back it up first.

Edited May 23, 2015 by RoverDude

[KerikBalm]

What I'm sensing is that the dot overlay is the most accurate.

I got a bit screwed over using the other overlays on a duna mission.

The ISRU thing says it "can take raw materials containing even trace amounts of oxygen and hydrogen, and crack them into useful fuel products."

Then I looked at Duna, and its poles were all lit up.

I thought "cool, that makes sense, the poles must have a lot of water ice- thats cool that the resource distribution is correlated with terrain, and some special cases where it just makes sense"

Then I landed.. and there was nothing there.

As I pointed out on a previous post, the dots seem to have 1 less iteration of interpolation, and they have a value of 0 for the CapPixels

"CapPixels = 0 //(int) 0+ - Number of pixels to extrapolate polar caps"

I don't know if this means they don't *ever* show resources at the poles (ie, they take 0 data points for the poles?)

I'm guessing the different filter modes don't have any major effect, but that the difference is due to 1 less interpolation iteration, and the polar cap extrapolation.

But RoverDude, since you're following this thread... I can't find any file describing what the surface scanner does.

It seems to update the map, and make it more accurate, but I'm not sure precisely what it does, can you explain what happens to the map after it is used?

I was sort of hoping that if I used the surface scanner on all biomes, that the map would be very accurate, and the NBS would be redundant/not needed.

As it is, I find the NBS to be clunky and not well suited for use. It seems like a scansat system would be better for gameplay.

I don't want to click to update the view as I go along orbiting, losing the old image with each new one (or am I doing something wrong? does it update the overlay for that area?)

[RoverDude]

So here's how the three scanners work. And as a preface - don't use the large survey scanner as your main source for determining a landing spot. You pretty much always want to follow up to get better data (probably some of the few exceptions being very clear biomes like the minmus flats and the mun craters).

Use the big survey scanner to get a rough idea of what's even on a planet. Identify some interesting places to investigate.

Drop in a rover with a surface scanner. This makes both the orbital and the NBS more accurate. Not by much tbh in the case of the orbital (it just replaces average with precise values when it does its check, but resolution is the same).

If you're happy with the spot, awesome, you're done.

If not, use the NBS to do flybys of areas of interest till you find something you like.

[cybersol]

I had one more question about the surface scanner:

Do you need to use the surface scanner in each biome or will it help resolution for all the biomes?

[RoverDude]

Each biome.

[MathmoRichard]

Ahhh! What you're seeing there is polar pinching. It gets a bit wonky with interpolation because of how the poles pinch, etc.

Note that the rest of the planet is pretty much in-line.

(edit)

To add a bit more, the interpolation at the poles gets pretty extreme, because otherwise we end up with weird stretchy/smeared textures. That polar region is interpolated from a very tiny subset of data points - so one pixel off (especially as weird as the poles are anyway) and you get a different interpolation. This in turn affects the blending as you come off the poles.

If you want to see how this affects the different overlays, feel free to fiddle with your overlay config file - it has comments. Just be sure to back it up first.

I'm not sure what wonky means but surely the algorithm can be modified to take a proper average of the points nearby (as Euclidean) uniformly and then this 'pinching' thing just isn't an issue.

[RoverDude]

Rest assured I've been through all of this

(To expand a bit)

The way in which the texture is rendered, and the resolution that we are working with, given the performance constraints, etc. result in tradeoffs in how interpolation is done - the net result is the fellow in the post above got a bit unlucky with which dots got picked for polar interpolation.

You are more than welcome to fiddle with the settings - I left them there so folks could adjust the stock experience if so desired. Our initial cut represents what I felt was a good compromise between performance, aesthetics, and accuracy. YMMV.

Edited May 24, 2015 by RoverDude

[MathmoRichard]

Rest assured I've been through all of this

(To expand a bit)

The way in which the texture is rendered, and the resolution that we are working with, given the performance constraints, etc. result in tradeoffs in how interpolation is done - the net result is the fellow in the post above got a bit unlucky with which dots got picked for polar interpolation.

It was a bit worse than unlucky though right? It was â…“ of the whole Mun's surface. So you're saying there's only one way to write the algorithm? And if settings need changing, it sounds like the defaults need tweaking.

[RoverDude]

We both know that 1/3 of the surface area is a bit of an exaggeration.

As noted, if you are dissatisfied with the default settings you're welcome to change them (these were left exposed precisely to give people more options), or log an issue on the public tracker.

But given this is the Gameplay/Tutorial forum not the Suggestions/Feedback forum, I expect at this point this horse has been sufficiently beaten.

[AaronLS]

If a player who is doing mining for the first time encounters this, they are going to be misled to that huge polar area, and have a very frustrating time!

My take away from this would be that an average player is going to look at this and think, wow, even though I know this is a rough map, surely I can hop around just about anywhere on the pole and find some good areas of ore. As bright and solid as the area is. Intuitively, one would think something that is inaccurate would mean edges and lightly colored area should be taken with a grain of salt, but a very large solid bright area would be a strong indication that ore can easily be found there.

A purely GIS approach would solve the pinching problem by generating the density map separately for each pole using a polar specific projection, then patch each result on to each of the poles with a gradient mask at something around a 50 latitude that gives a good transition onto the original. There can be alignment issues at the transition though. This would probably triple the processing time but be less than an order of magnitude. Maybe that is not feasible within the engine though.

Personally, if it were me I would keep it on the radar to revisit when bandwidth is available.

[Murph]

If a player who is doing mining for the first time encounters this, they are going to be misled to that huge polar area, and have a very frustrating time!

My take away from this would be that an average player is going to look at this and think, wow, even though I know this is a rough map, surely I can hop around just about anywhere on the pole and find some good areas of ore. As bright and solid as the area is. Intuitively, one would think something that is inaccurate would mean edges and lightly colored area should be taken with a grain of salt, but a very large solid bright area would be a strong indication that ore can easily be found there.

A purely GIS approach would solve the pinching problem by generating the density map separately for each pole using a polar specific projection, then patch each result on to each of the poles with a gradient mask at something around a 50 latitude that gives a good transition onto the original. There can be alignment issues at the transition though. This would probably triple the processing time but be less than an order of magnitude. Maybe that is not feasible within the engine though.

Personally, if it were me I would keep it on the radar to revisit when bandwidth is available.

That sounds like an excellent suggestion. The processing time shouldn't really be a huge concern, as it's not something that needs to be constantly recalculated. It gets updated when we scan a new biome, but is static apart from that.

Right now, even if the system is definitely using the same data for the 3 presentations, and technically operating correctly, the visual result has a significant problem. There is a large significant difference between the styles which gives the appearance of working from a significantly different data set. The difference is visible over the entire sphere, not just the poles  I've seen big changes in the 0–30°.latitude band as well.

Small variations, not a problem, that just serves to emphasise that it's not high precision data, particularly if the variation is mostly around the edges of hot spots, not entire hot spots moving significantly. Big variations, that leads to confusion and people thinking it's useless or broken, not knowing which version to trust. Right now, it's big variations.

[MathmoRichard]

We both know that 1/3 of the surface area is a bit of an exaggeration.

As noted, if you are dissatisfied with the default settings you're welcome to change them (these were left exposed precisely to give people more options), or log an issue on the public tracker.

But given this is the Gameplay/Tutorial forum not the Suggestions/Feedback forum, I expect at this point this horse has been sufficiently beaten.

I'm happy for the thread to be moved, it's really only here because I didn't realise the nature of the issue.

Given that we are talking about both poles, it's very close to â…“.

If a player who is doing mining for the first time encounters this, they are going to be misled to that huge polar area, and have a very frustrating time!

My take away from this would be that an average player is going to look at this and think, wow, even though I know this is a rough map, surely I can hop around just about anywhere on the pole and find some good areas of ore. As bright and solid as the area is. Intuitively, one would think something that is inaccurate would mean edges and lightly colored area should be taken with a grain of salt, but a very large solid bright area would be a strong indication that ore can easily be found there.

A purely GIS approach would solve the pinching problem by generating the density map separately for each pole using a polar specific projection, then patch each result on to each of the poles with a gradient mask at something around a 50 latitude that gives a good transition onto the original. There can be alignment issues at the transition though. This would probably triple the processing time but be less than an order of magnitude. Maybe that is not feasible within the engine though.

Personally, if it were me I would keep it on the radar to revisit when bandwidth is available.

Agree 100%. And as Murph says, calculation time really shouldn't be a concern.

New players shouldn't be mislead into thinking that the worst region is the best.

By the way, I had to spend 10 whole hours doing 'manual labour' just staring at the narrow band because I had no ability to trust the orbital... That's just not fun!

[RoverDude]

If you spent ten hours staring at the narrow band, you may want to review the use of the different scanners. I'm sorry you do not trust the orbital, that's your call. But it does serve it's purpose in providing a reasonable subset of areas in which to further investigate. To reiterate the gameplay flow, since that may be missed in the noise (and add a bit more detail while I am at it).

- Use the orbital surveyor to get a general layout and identify potential areas to investigate.

- Investigate by dropping a Rover on the ground to unlock the biome, or use the NBS over an interesting area to get a clearer idea of the level of resources in that biome

That large red splotch you saw does in fact indicate that there is stuff at the poles (in a specific biome)... but given the edges of the various biomes (some are actually pretty even concentric areas, some are not), it may not have been on the precise spot you landed on. No different than a stray hit on, say, a shores biome or one of the minmus slopes can cause a splotch to appear, when the actual area with resources is extremely small.

The biome bit is important - resources always follow biome edges. So if you see a hit inside of, say, one of the Mun craters.. rest assured, that crater has Ore.

Regarding some of the other suggestions regarding map projection, etc. - you have three things that influence the default settings.

First - the textures are VERY small. Most of the interpolation you see is being handled by Unity. There simply is not enough pixel space to do many of the usual map stretching techniques one would use, and the objects are uv spheres not icospheres. This does make a significant difference in the way trilinear interpolation makes the texture look.

Second. Nothing is stored. Everything is procedural. So performance is absolutely critical (again, an alternate projection is a completely moot point anyway due to pixel density and interpolation, unless one makes a sacrifice in performance. Trust me - this was looked into).

Third. The biomes themselves have some interesting angular artefacts and very sharp edges (this is not just a case of slapping some simplex noise on a sphere), so additional interpolation, simplex noise, etc. are used to give the overlay a more organic look, and to avoid smearing/tearing artefacts, weird edges, etc.

The intent, as noted below, is that this scanner is used to provide a 'hint' of where to look - other scanners cover the rest based on those hints.

That being said, there is something odd about that specific picture - if I could get a seed value from the persistence file, I'd like to peek and see precisely what caused the hit that gave you that splotch.

(Edit)

Did some of my own poking around, found the edge case that's giving you a false splotch.

Edited May 24, 2015 by RoverDude