Jump to content

[1.10.1] SCANsat [v20.4] -- Real Scanning, Real Science, at Warp Speed! [September 9, 2020]


DMagic

Recommended Posts

You might have noticed some performance problems in the latest release, particularly with low resolution and/or greyscale terrain maps. I should be a little embarrassed and mad about missing such a dumb thing, but in the process of figuring out why performance was so bad I stumbled on a huge performance boost across the board.

It turns out that one of SCANsat's older bits of code (the instance getter property for the scenario module, to be specific) was using a terrifically inefficient method. And since that property is called hundreds to thousands of times per frame by the map generator it was having a huge impact. Simply using a saner approach to accessing the scenario module instance yields significant improvements to map rendering speed.

The following are rendering time differences for a 1000 * 500 pixel big map:

Full terrain map (terrain data pulled from KSP): 20s to 13.5s

Terrain map regen (terrain data from cache): 13s to 6.5s

Stock style biome map: 34s to 5.5s

SCANsat style biome map: 31s to 5.5s

Slope map: 20s to 5.5s

Times for the zoom map improve, too: a terrain map at the standard zoom map size goes from 5s to 3s (little/no drop in frame rate)

As you may notice, 5 - 6 seconds is about the time that it takes for the red line to move up the map at 60 FPS. Almost as important as rendering time, is that there is little to no impact on frame rate while redrawing the map.

To be clear, reading the terrain data directly from KSP is still slow and still has a significant frame rate impact; there isn't much to be done about this aside from distributing SCANsat with some kind of pre-computed height maps, which I am not at all a fan of doing. But once the terrain data is read it will remain cached until you change the planet being displayed or change the map size. After that the maps generate with little delay.

As you've probably noticed I'm not a big fan of incremental SCANsat releases, I've only uploaded 7 or 8 primary release versions of SCANsat in the past year or so. But I think this warrants a quick release, I'll see about getting it out tomorrow.

Link to comment
Share on other sites

The map drawing did seem a bit laggier than usual. Still though, no prob on that DMagic. :)

Does the orientation of the antenna have any influence?

I.e. whether it is actually pointing at the planet, not pointing at the planet at all or at a certain angle with regards to the flight direction?

Or is the scan region simply determined by drawing a line between the ship and the center of the planet?

Nope, orientation doesn't matter at all, it never has.

For the second question, I guess that's how it works, DMagic would be able to explain that better than I can.

Link to comment
Share on other sites

The stock resource scanning appears to be fine.

I had already done two biome samples at this point (of other biomes obviously)

screenshot11_zpszd78kdfl.png

screenshot12_zps6202xwnd.png

I also checked the other resources and they're fine. Being off by a couple hundreths of a percent isn't a big deal, plus the mouse pointer isn't as accurate as the zoom in SCANsat.

Another biome. Also, where the heck is that memory leak (or memory jump or whatever the actual technical term is) coming from?

screenshot13_zpscqwhd7j7.png

screenshot14_zpsljbxxugu.png

I'll check the save with the scansat enabled in it.

Just recording the settings here. Still getting it set up.

screenshot15_zpspwstcn5m.png

Wierd, it's actually working fine in the branchoff KSP, going to reset resource scan data for my main save and see if that does anything.

Edit: Yeah, resetting the stock and SCANsat resource data fixed it. I guess maybe there was some conflict or confusion coming from somewhere. No idea where though.

Edited by smjjames
Link to comment
Share on other sites

It's possible that there is a problem with how SCANsat is checking for biome unlocks. Looking through the code for the resource abundance readout modules I can see where there might be some problems.

That said, the instruments window resource abundance readout should work fine and be less terrible than right-click menus.

Link to comment
Share on other sites

How do I despawn (or turn off or whatever) the green targeting cross? Because it's been where I left it on Minmus for a while now, so I'm just wondering.

Just click off of the map while selecting a waypoint.

YffxdNs.gif

Link to comment
Share on other sites

Hey I have a problem regarding the resource scanning. In 1.0.2, I just had to use the M700 Resource Scanner to get a high res scan of the mun, however in 1.0.4 the resolution of the scan is waaaay lower:

Heres the scan from the M700 in 1.0.2

flqd7z0.jpg?1

And the scan with the same scanner in 1.0.4(Note I started a new save, so ignore the difference between the 2 maps in terms of ore)

vno11aQ.jpg?1

So how can I get the same result? I used the scanner at the best altitude ofc.

Link to comment
Share on other sites

Hey I have a problem regarding the resource scanning.

It's not a problem, it's working as intended in version 14.

I'm assuming you aren't using SCANsat resource scanning (that the instant scan option is toggled on in the resource settings window), or that you also scanned with the narrow-band scanner.

In version 14, the M700 (when used with SCANsat resource scanning) provides only a low-detail scan for all resources. The values on the map and in the info readout below are rounded to the nearest whole number (most of this info can be found on the GitHub docs). To get accurate results you need the narrow-band scanner for ore (and whatever mod resource scanner is required for other resources). With the instant scan option toggled on this doesn't matter, you just do the stock resource scan with the M700 and you get the SCANsat resource map.

As for the low resolution of the map overlay, that is also intended. It provides roughly the same quality map as the SCANsat (and the stock) planetary overlay map. It works this way for several reasons:

It preserves the stock resource scanning mechanic whereby the orbital scan is only one step of locating areas of high resource abundance.

It also makes some sense for the SCANsat map to match what you see on the planetary overlay map.

And, just as importantly, the lower quality resource map can be generated very quickly, it is created almost instantaneously at the beginning of a big map refresh. There is almost no difference in rendering time whether the resource overlay is on or off. Compare that with previous versions where the resource overlay would have a huge impact on map rendering time (the changes made in 14.1 would have little effect on this slow down).

For more-or-less fully accurate resource abundance maps you can use the zoom map. If you don't want to fool around with narrow-band scanner requirements you can disable those in the resource settings window and use all resource overlays freely on the zoom map.

One thing that I might change at some point is for the big map resource overlay quality to use the same quality settings as the planetary overlay. Right now it uses the default quality levels, those can be changed for the planetary overlays (I usually set the interpolation at 4 and the map height to 512, it's fast enough and I think much more useful), but those settings don't affect the big map overlays.

Edited by DMagic
Link to comment
Share on other sites

Ah okay thanks for the clarification <3

Regarding the scanning mode, I tried both the stock and the SCANsat scanning option, but I didn't notice a difference.

And, just as importantly, the lower quality resource map can be generated very quickly, it is created almost instantaneously at the beginning of a big map refresh. There is almost no difference in rendering time whether the resource overlay is on or off. Compare that with previous versions where the resource overlay would have a huge impact on map rendering time (the changes made in 14.1 would have little effect on this slow down).

Personally I wouldn't mind the performance impact^^ I hardly noticed it in older versions of Scansat.

One thing that I might change at some point is for the big map resource overlay quality to use the same quality settings as the planetary overlay. Right now it uses the default quality levels, those can be changed for the planetary overlays (I usually set the interpolation at 4 and the map height to 512, it's fast enough and I think much more useful), but those settings don't affect the big map overlays.

That would be great :)

Anyways, thaaaaank you for this glorious mod :D

Link to comment
Share on other sites

Suggestion(pretty please with sugar on top):

Could you add at least one conformal map projection(mercator, stereographic polar, ect)? That would help immensely to know the bearing of a flight path relative to the north, which would be useful for correctly launching into the plane of an orbiting spacecraft from the surface.

Link to comment
Share on other sites

After a time absent to KSP* I came back recently and I enjoy the current ScanSat also very much. (Thanks DMagic)

But there is a question popping up in my head ...

and I am sure there are a lot of people who figured it out and crunched the numbers ... so as the lazy **** that I am I probably don't have to do it myself

... and that question is "What the optimal polar orbits are for various Kerbol system bodies to scan them in the least time possible"

E.g. in my current simulation** I have set myself for a 250k (+- a few hundred meters) 90° (+- a few fractions) and it takes roughly 4 days for a whole kerbin scan.

That altitude is based on a guts feeling ... I know for the optimal orbit I have to take the orbital period of the satellite in account as well as the rotation period of the planet ... and if synced up properly you don't end up scanning some parts over and over while waiting for others to be scanned.

Well if there isn't already a spread sheet ... at least somewhere has to be a formula. I'm sure NASA has it...


*=mostly because I was annoyed of the constant crashes because with all the beautification I installed it runs out of ram pretty quickly

**= I am using Build Time ... so sims are pretty much a given if I don't wan't to screw up hard time.

Link to comment
Share on other sites

But keep in mind that the link's orbits for Minmus are bogus...

Yea a Minmus orbit I chose left me with a paltry first result. I found I had to do a bit of adjustment around Duna as well to get full coverage from an initial orbit taken from the list of optimal ones. Mun worked almost perfectly the first try though

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...