[PLUGIN+PARTS][0.23] SCANsat terrain mapping

[automcdonough]

that's just my $0.02.

[sirkut]

too many separate parts.

how about like.. 2. that weigh the same. ?

Just edit one part's CFG and paste all the module SCANsat definitions...

[Hodo]

Great job, but I will wait a bit on the download till it is a bit more polished. (Read, I have more RAM space)

[DMagic]

I am working on offline apps that make use of the data collected from ksp missions. higher level mapping applications, data comparisons to see change over time, spatial / temporal changes or overlaps between all items that can be mapped. Bringing in other data, such as kethane, ore, etc to be able to build layered stack maps for optimization of exploration missions. etc.....

I haven't seen any offline apps for KSP, but I know that it's common in flight sims to have some kind of mapping app that takes data output from the sim to plot your location, like a GPS map. One of the things that came up over and over again in the thread I created about using portrait mode is that some kind of multi-window support would be really great for KSP (think putting the map in one window, regular screen in another, IVA or instruments in another, etc...). It won't happen, this is a Unity limitation that's not likely to change anytime soon, but it would be really neat. So the possibility of having some kind of offline map, maybe one showing your present location above, or on, the surface, and some info like Kethane, slope, altimetry, etc..., is really interesting. It's not something I would expect from this mod, but providing the data output to allow this (if it's possible) is something to think about.

I like that there are many parts actually. I can pick and choose my objective.

I like this aspect too and I hope that we see some further differentiation between the parts. I'm thinking something like a wide range of size and mass for different scanner types. That way you would have to be more selective about which parts you want to add, unless you just want to make a really huge mapping craft. Having different scanners work at different altitudes could be interesting, too. For instance, the high resolution scanner could be limited to under ~100km, while the low resolution scanner might work anywhere below ~750km.

Great job, but I will wait a bit on the download till it is a bit more polished. (Read, I have more RAM space)

RAM usage for these parts actually seems to be really low. It doesn't have the same issues that ISA did where the map files got blown up by KSP/Unity's inefficient way of dealing with texture files, and the parts are really simple.

I also got around to testing this again on my desktop and the map overlays definitely seem problematic. Using all three overlays only dropped my FPS from 60 to around 50 (on an quad-core i5 3470), but CPU usage shot way up. With the big map open and no overlays turned on the CPU was at about 15%, but turning on the orbit and grid overlays pushed it up to 55% (that's the highest I've ever seen for KSP). That's ok for the tiny little mapping satellite I was using, but if you put some of these parts on a big space station, or larger craft it would be a problem. I'm not sure if having multiple mapping crafts further increases CPU usage, I'll try to check that later.

[damny]

So the possibility of having some kind of offline map, maybe one showing your present location above, or on, the surface, and some info like Kethane, slope, altimetry, etc..., is really interesting. It's not something I would expect from this mod, but providing the data output to allow this (if it's possible) is something to think about.

I have this idea in the back of my head of a proper client/server system where a client could connect to the plugin and request all this data... I won't have time to do anything like that anytime soon though. I just like the idea.

I like this aspect too and I hope that we see some further differentiation between the parts. I'm thinking something like a wide range of size and mass for different scanner types. That way you would have to be more selective about which parts you want to add, unless you just want to make a really huge mapping craft. Having different scanners work at different altitudes could be interesting, too. For instance, the high resolution scanner could be limited to under ~100km, while the low resolution scanner might work anywhere below ~750km.

I feel that limiting a sensor to 100km will just make people switch to another craft to time warp. I'd rather make it more challenging, or at least more interesting. It might be an option to just reduce the field of view of the high res sensor drastically, so that you really need a proper mapping orbit - but if you get into one it would hopefully not be more annoying than it is now to complete the map. (I think the mod makes it very easy now to get into a good orbit with equatorial crossings displayed on the map.)

Ideally, restrictions placed on sensors or features would not make it a chore to use the feature but still create missions. Like the Anomaly/BTDT pair is basically a mission to get an anomaly sensor into orbit that then provides more missions to go to marked places to identify the anomalies there.

I'm thinking that in a similar vein, the zoom box could require that the spot you're zooming must be visible from a satellite with the right type of sensor right then. "Visible" could mean as little as "the satellite has to be on the same side of the planet". It wouldn't be a huge deal, but it would basically provide this mission to set up satellites in suitable orbits so that the planet is always covered (optionally with synchronous orbits in SoIs that allow those).

I also got around to testing this again on my desktop and the map overlays definitely seem problematic. Using all three overlays only dropped my FPS from 60 to around 50 (on an quad-core i5 3470), but CPU usage shot way up. With the big map open and no overlays turned on the CPU was at about 15%, but turning on the orbit and grid overlays pushed it up to 55% (that's the highest I've ever seen for KSP).

At least the grid will be implemented differently in the next build. (With a texture that's only updated when the grid changes because the projection was changed or the window was resized.)

That's ok for the tiny little mapping satellite I was using, but if you put some of these parts on a big space station, or larger craft it would be a problem. I'm not sure if having multiple mapping crafts further increases CPU usage, I'll try to check that later.

I'd hope it wouldn't have a noticeable impact, as the "scanning" process is not very complicated. The main work is rendering the map.

[OrtwinS]

At least the grid will be implemented differently in the next build. (With a texture that's only updated when the grid changes because the projection was changed or the window was resized.)

But you would still have to resize/compress/stretch that texture every time you change the projection. You can do a similar thing with the GroundTrack.

In a circular orbit the ground track will always be sinus shaped (2 periods to include past en future orbit).

• Vertical compression is based on orbital inclination.
  
• Horizontal compression depends on the orbital period. (for the polar and Kavrayskiy projection you'd still need to apply their deformations on top of that). The only tricky math part will be to compensate the horizontal compression for non-circular orbits. (Since the velocity won't be constant the time to reach a certain x-coordinate on the sinus will be harder to calculate.

A mathematically prettier (and simply more robust) solution is to start with an elliptic function (actually the orbit equation), input the orbital parameters and use that to calculate a few dozen points for the X axis in the past and present. Vertical scale would still be a simple compression based on inclination.

You could render 1.5 periods in front of the vessel in stead of 1 (so 3 periods in total for past and future) and only update the calculation once every half orbit.

Display could be by texture, or spline (if KSP UIs can display splines).

The ground track mechanism should then probably be disabled during time warp, to prevent frantic calculation updates.

This ground track wouldn't disply correctly when the orbit is changing, but you can add a check for that (IF Thrust=/=0 OR RCS=/=off THEN GridCalc=false)

Downside of that check would be that we can't see the orbital track change on-the-fly.

[KhaosCorp]

Advanced SAR sensor cluster..extends to 4meters to reduce backround 'noise' from spacecraft:

got a bit more polishing to do on the two altimeter sensors, the low res will be radial unit, the high res one mounted on a extendable boom.

Should be on to textures for everything this evening, then I will either ship em all off to damny or post em on mediafire or some such.

[damny]

A mathematically prettier (and simply more robust) solution is to start with an elliptic function (actually the orbit equation), input the orbital parameters and use that to calculate a few dozen points for the X axis in the past and present.

I'm pretty sure that's what happens behind the scenes in the Orbit class. I'm not going to re-implement that until it's really the bottleneck (now, inefficient rendering is the bottleneck). The only thing that I do outside the existing Orbit class is account for the planet's rotation around its axis. The final geographic coordinates get sent through the active projection function and then the inefficient part starts

Equatorial crossings are similar, except I couldn't figure out how to get those out of the Orbit class. The functions seem to be there if I go by names, but they don't seem to do what I'd expect. Now I just calculate the mean anomaly at the ascending and descending node myself and then let the Orbit class calculate the position at the nodes for a few periods.

if KSP UIs can display splines

I wish...

The whole reason why I even use text for the first implementation is that I seem to have these options:

1. draw text on the screen
   
2. set individual pixels of a texture
   
3. draw 3D objects (this includes lines) on a rendertexture
   

So it's very tempting to just say "write a • here, here, here, and here". Now that it looks like the math that determines the "here" is working, I can do something more efficient and if that doesn't work I'll know it's not the math.

This ground track wouldn't disply correctly when the orbit is changing, but you can add a check for that (IF Thrust=/=0 OR RCS=/=off THEN GridCalc=false)

The orbit changes all the time when a craft is off rails just from the physics engine playing with itself. I can't just pretend that's not happening. I also think it's really desirable to see changes live.

[BananaDealer]

Interesting... And I really like where this is going...

Also- any chance on any feedback on why the GUI changes between warp and no-warp? Is it a glitch or something on my end?

[damny]

Also- any chance on any feedback on why the GUI changes between warp and no-warp? Is it a glitch or something on my end?

I already replied to that earlier in the thread - I don't see GUI changes when warping. I did see them when pausing. I was able to stop that though, so if your issue is related, there's a chance the next build will fix it too.

[BananaDealer]

I already replied to that earlier in the thread - I don't see GUI changes when warping. I did see them when pausing. I was able to stop that though, so if your issue is related, there's a chance the next build will fix it too.

Hmm... May have missed that... The thread is growing fast... Is the default GUI the old style or the new style?

[damny]

Should be on to textures for everything this evening, then I will either ship em all off to damny or post em on mediafire or some such.

Nice!

If you want me to include them in my packages, please don't forget a license.

[damny]

Hmm... May have missed that... The thread is growing fast... Is the default GUI the old style or the new style?

The default GUI is the Unity default GUI. The one that you see in my screenshots.

[Nemoricus]

First, let me say that it's nice to see a mapping plug-in that's under development again. And one that has more uses than ISA, too!

However, after playing around with it a bit, there are a few things that bug/confuse me. Some of them were mentioned earlier in the thread, but I think they're worth repeating.

1. Too many parts. While I can understand the desire to have each function in a separate part, at the moment the need to place multiple sensors is a little annoying, especially as you can't use symmetry to ensure that they're evenly spaced. An all-in-one sensor would be very nice.

2. Altitude has no effect on the area scanned? This seems odd to me, perhaps because I'm used to ISA, but it would still seem to make sense to have an area scanned/resolution trade off for altitude. Especially since a quick, low resolution map might be adequate for some purposes...

3. An auto-update for the big map would be nice, since it shows more detail than the smaller map.

4. The big map could probably use some performance optimization, since it noticeably slows down the game for me, but it seems you're already working on this one.

Keep up the good work, by the way! For a second release, this is already very nice, and I'm looking forward to using it more in the future.

[sirkut]

The fuss about multiple parts can be fixed by copying the module scansat portions from the 6 parts into one. Then all you need to do is right click and pick from the 6.

Maybe create a 7th part that is a little heavier and possibly bigger that houses all of the scanners them everyone can be happy.

[KhaosCorp]

Honestly I think the specialized parts really add alot to this mod. I for one am enjoying creating little constallation to map bodys with role specific sats. I hope the parts become role specific, needing specific orbits to idealy map for any given sensor. Im kinda using that idea (and loose RL inspiration) for the parts I am making.

I was planning on making a larger (2.5ish meter) all-in-one part when I get the replacements made. The other drawback to an all-in-one unit, other than it being supper heavy and (maybe eventually) more power usage, is that each type of scan may need (now or in future versions) diffrent orbits to hit ideal. But for those wanting to tweek the 'perfect' orbit..either for these sensors, or using them as tools to calibrate other scanners (like kethane), are still gonna want the single role sensors.

Edited November 1, 2013 by KhaosCorp

[sirkut]

Considering that more than one satellite can map at the same time I don't care about havin an all in one. Just deploy some mini sats from the main one and be happy.

[TinyPirate]

I would have thought different orbits for different sensors would be ideal - at least altitudes. I hope we get this integrate with science soon as well!

[OrtwinS]

I would have thought different orbits for different sensors would be ideal - at least altitudes. I hope we get this integrate with science soon as well!

Different height requirements for different sensors would certainly justify the multitude of sensors .

I mean: of course there are so many parts! They require different altitudes! *cough*.

[automcdonough]

I suppose. But as things are now, who has honestly went through the effort of putting up a sat and did NOT have ALL the sensors on it??

exactly.

[BananaDealer]

The default GUI is the Unity default GUI. The one that you see in my screenshots.

Hmmm... It uses the bulkier grey GUI on my end... When I warp however it switches to the lighter, transparent GUI...

No, scratch that... I launched now and it switched to the lighter GUI... No more warp glitchiness too!

Edit 2: Wop... Nope... Dropped out of warp and the GUI switched on me again...

Edited November 1, 2013 by BananaDealer

[OrtwinS]

I suppose. But as things are now, who has honestly went through the effort of putting up a sat and did NOT have ALL the sensors on it??

exactly.

Eh, I did, but that is beside the point.

The different data types (and tech levels) warrant a range of sensors.

The only scanners I can think of that

should

actually be combined into one is the Altitude and Slope RADARS. (When you have altitude you can calculate slope!) There can still be 2 or 3 different versions with different ranges/resolutions/power requirements for different tech levels.

Biome/terrain regions are a specific type (I imagine spectroscopy to detect different elements).

Anomaly Scan

could/might

be integrated in the altitude RADAR at the higher tech levels (the adv. altimeter radar could be precise enough to detect 'anomalies'). Detecting something the size of a monolith from orbit requires a pretty high tech level.

The BTDT (great name btw) scanner should stay unique as well. This is some composite scanning method with advanced image recognition. Very different from a 'simple' radar.

(I can imagine people will append this functionality to command modules by default though, like we do with MechJeb. 'simply' by adding a MODULE {name=SCANsat sensortype=0} to it)

Maptraq is also unique. It will probably have a significant smaller model and lower energy consumption, the kind of part that you put on everything to allow it to access mapdata (I imagine Kerbals prefer a stand-alone system that can quickly scan it's surroundings and compare that to the known database, in stead of a system relying on an external and complex network of sats like GPS)

And that leaves us the optical sensor (which does not exist, and perhaps never will). Another completely different type of sensor.

This is a part of immersion. Different sensors belonging to different tech-levels. It has a flair of realism as well, omni-sensors do not exist! For every mission you will need to decide what you want, and what you need. If you have a strict part/dV/energy budget you might have to make cuts!

Of course, the part budget restriction is just very unfortunate, but in that case there is always .cgf editing.

The scanning surface restriction is also 'part of the game'. I don't think it has ever been the intention of any mapping plugin to *poof* supply you with all info you want. We have a wiki for that. If you just want an ingame map display I think you should request a seperate plugin for that.

The entire acquisition process will expand the game and give us goals.

The high-warp and multi-sat capabilities of SCANsat already prevent it from becoming 'grindy'.

Edited November 1, 2013 by OrtwinS

[KhaosCorp]

I suppose. But as things are now, who has honestly went through the effort of putting up a sat and did NOT have ALL the sensors on it??

exactly.

I have launched multiple sats for ALL the mapping I have done since this was first posted...

Effort? Launching rockets is the basis for just about everything...dont really consider it an effort past any other mission mission...thats the game.

[drtedastro]

@KhaosCorp. Well put... that is the reason we do this....

[drtedastro]

I'm happy to, just wasn't sure whether it was allowed.

Beholdeth:

[uNOFFICIAL] Texture Pack #2:

https://www.dropbox.com/s/u7084fjpl0nx6gh/SCANsat.zip

Many thanks..... That is a great quick way to keep them sorted out....

Want those sensors? Clicky linky!

(Everything except the .tga files and the license.txt has been stripped out. Whack it in GameData, and it'll update the textures.

Good stuff. Exactly what was needed to keep them sorted out nice and easy for now... Thanks.