[1.12.X] Orbital Survey Plus v2.3.6

[Enceos]

@DMagic lovely! Are the scaled textures generated on the fly or during the game loading? Does the game lag a bit when switching textures? And yeah, I'm with you that bump map should be turned off untill the original high res texture is revealed. I agree with @CaptRobau, 64x32 texture size hides the details beautifully while giving the idea of the planet's color.

This was one the first images of Mars from Earth.

Edited May 7, 2016 by Enceos

[ShotgunNinja]

In OpenGL/DX you can specify an arbitrary base mipmap level (the bottom of the pyramid, the default is 0) on the fly, this parameter is then used directly by the hardware when filtering the texture.

The base mipmap level is exposed as a texture property by many 3D engines, haven't checked about unity however.

Note that this will not work if that particular texture is using linear filtering.

[Enceos]

@DMagic Is this function any good for tweaking the displayed mipMaps?

http://docs.unity3d.com/ScriptReference/Texture-mipMapBias.html

@Wheffle sorry that we went a little offtopic in your thread.

Edited May 10, 2016 by Enceos

[Wheffle]

@Enceos Not a big deal There's some good info being discussed.

[Apollo13]

Thanks to KottabosGames YT, I learned about this.

KottabosGames Review

Edited May 13, 2016 by Apollo13

[Genolution]

4 hours ago, Apollo13 said:

Thanks to KottabosGames YT, I learned about this.

Same with me just now. And like others have said, How did I miss this?  @Wheffle I really like how this stands out from MAPSAT with its stock-alike feel. Does this work with other planet packs assuming they have resources and biomes defined? And what about Sigma Dimensions rescale mod?

[ShotgunNinja]

@Enceos That is used in the selection of the mipmap level when the hardware is sampling the texture. Putting a positive number in there will make the hardware sample from higher mipmap levels (meaning smaller image, with more 'blurry' results). I suggest using integers. Setting that to '1.0' will make the hardware sample from half-resolution texture, setting it to '2.0' from 1/4 resolution texture and so on. The max level that can be choosen is limited to log2(max(width, height)) where width and height are the dimension of the base level of the mipmap pyramid (meaning: the dimension of the original texture).

Note that the above is a simplification of the thing, I suggest reading about mipmapping online. Anyway, here is an eagle view of how it works:

Spoiler

• during execution of a shader for a particular 'region' of pixel (usually 2x2 pixels), some texture sampling instructions are emitted referring to a texture unit and coordinates in texture-space
• depending on the texture coordinates used in the region, an horizontal and vertical txcoord derivative in texture-space is found
• if the texture unit is configured for mipmapping, the derivatives are used to select the appropriate level in the mipmap pyramid
  (farther away from the camera means bigger derivatives in texture-space, and an higher [meaning lower resolution] level in the mipmap pyramid is selected)
• then, the mipmap bias is added to the computed level (this is what you are changing)
• the level selected can be an integer or a fractional number, depending on the particular mipmap filter used (there are multiple ones)
• so now in addition to the texture coordinate (fractional) there is also a mipmap level (possibly fractional)
• the hardware sample up to 8 texels from up to 2 adjacent mipmap levels and mix them, then return the result (that is now filtered)
• the sampling instructions return, the shader happily goes about doing whatever it was doing

 

Edited May 13, 2016 by ShotgunNinja
typos

[Apollo13]

delete this post

Edited May 14, 2016 by Apollo13

[Wheffle]

23 hours ago, Apollo13 said:

Thanks to KottabosGames YT, I learned about this.

KottabosGames Review

Oh hey, cool!

 

19 hours ago, Genolution said:

Same with me just now. And like others have said, How did I miss this?  @Wheffle I really like how this stands out from MAPSAT with its stock-alike feel. Does this work with other planet packs assuming they have resources and biomes defined? And what about Sigma Dimensions rescale mod?

So, it should work with any kind of mod that adds planets (based on how the mod works), although there's an old post on this thread that I noticed saying there might have been a bug on an old version with extra planets. I might do some testing myself, as I'm curious. As far as scaled planets go, the size of the scan data depends on the planet's size, so a mod that scales up, say, 10x, will scale up the scan data 100x. This could cause slow-downs. If it turns out to be a huge performance issue, I might try to address it.

 

16 hours ago, Apollo13 said:

ddddddddddddd

Cool.

[Genolution]

I can now confirm this works just fine with the current Sigma Dimensions based Kscale2. My PC may be a bit better than most but I don't see any real performance drops. This mod should be stock. @Wheffle Have some magic internet points.

[curiousepic]

Hope the shrouding is coming along. Couple more questions/feature hopes...

• Would it be possible to customize the width of the scan?
• Is there any way to see the names of biomes, like a color key?
• I know this is coming close to crossing the streams with SCANSat, but is there any possibility of altitude/topographic and/or slope data? 

Edited May 21, 2016 by curiousepic

[Wheffle]

If you look in the "patches" directory in the OSP folder, you can make changes to the module patch there. It includes scan radius, electric charge drain, and science bonus I believe.

It would be cool to have some kind of biome key. I will look into it, but I have no idea how feasible it will be.

I most likely will never add any other kinds of maps, like altitude or anomolies or whatever. My goal is to keep OSP as simple and stockalike as possible.

[aeroeng14]

Just tried this in KSP v1.1.3 and everything seems to work fine! Thanks for making such a great mod!

[Wheffle]

On 6/26/2016 at 2:22 PM, aeroeng14 said:

Just tried this in KSP v1.1.3 and everything seems to work fine! Thanks for making such a great mod!

Thanks for testing it for me! I'll officially update it when I get the chance, along with a few small improvements probably.

[Grizzington]

So by my understanding, this mod will work very well with AntennaRange, because the data needs to be transmitted back to KSC, correct? My only other question: any idea if the scan will continue when out of Line Of Sight with a relay satellite?

[Wheffle]

On 8/5/2016 at 1:56 PM, Grizzington said:

So by my understanding, this mod will work very well with AntennaRange, because the data needs to be transmitted back to KSC, correct? My only other question: any idea if the scan will continue when out of Line Of Sight with a relay satellite?

Although I haven't personally tested it, yes, the mapping data/science transmission should need a connection when you're using AntennaRange. I'm not familiar with AntennaRange's internal workings so I can't guarantee it (if you test it, let me know!).

To answer your second question, the scan will definitely continue while it is out of range or has no line of site. It stores up the map data it has scanned without any need for transmission, and then the map is revealed once it is transmitted back. So theoretically you can scan the entire planet with no active connection, bring it into range and transmit the whole map back to the KSC all at once.

[Jiraiyah]

Hi

Can i ask for a feature request? I am not sure if it's possible or not or how hard it would be to implement. but...

As you can see in the image above, that is a single orbit around kerbin and a very wide strip of the planet is being scanned, that means scanning a planet would take very few minutes with time warp. Is it possible to add a config to change the cone angle of the scanner? So if we desire, we could change it to lower numbers to reduce the width of the strip it would scan?

Thanks

Edited September 29, 2016 by Jiraiyah

[Wheffle]

On 9/29/2016 at 3:05 AM, Jiraiyah said:

Can i ask for a feature request? I am not sure if it's possible or not or how hard it would be to implement. but...

As you can see in the image above, that is a single orbit around kerbin and a very wide strip of the planet is being scanned, that means scanning a planet would take very few minutes with time warp. Is it possible to add a config to change the cone angle of the scanner? So if we desire, we could change it to lower numbers to reduce the width of the strip it would scan?

 

I believe I made it adjustable in the config file for the scanner. If you've messed with KSP config files before, it should be easy to find. If not, let me know and I will walk you through it. It's a simple value change that will reduce the radius of the region scanned every tick.

[Jiraiyah]

Hi, I think I found it? ScanRadius = 8, now, how does this 8 being used? for example, if i set it to 2, what will happen?

[Wheffle]

Yes, that's it. The radius units unfortunately are in arbitrary grid cells, so you might just have to tinker with it to get a radius you like. If you set it to 2, the radius of the scan area will be 1/4 of the default.

[Jiraiyah]

Ok, now i have a problem in 1.1.3, not sure if i am doing something derpy or not, but when i toggle the biome map or Ore map either in KSC's track station or map view in the flight, it's not updating in real time and i need to toggle the map off/on again to update it.

thanks

Edited October 2, 2016 by Jiraiyah

[Wheffle]

@Jiraiyah  That's normal behavior. Unfortunately the map update is too laggy to do auto updates. You'll notice a small stutter when you bring up the ore or biome map; that would not be fun to deal with if it was happening automatically every second or multiple times a second.

[Jiraiyah]

how about adding a cool down to at least auto update it every 3 secs? would it still stutter? honestly, i am surprised to hear that it does that ! but I am still cool with your mod, specially when i set the radius to 1 (Miny Tiny Little Time Consuming Devil) and using tweak scale i rescaled the part to 1/8th of original size, also balanced the electric charge usage so when the whole planet is finished, the same amount of electric charge would be used. All in All, GREAT MOD. thanks for making it possible for us sir.

[Wheffle]

Thanks! With KSP 1.2 on the doorstep, OSP is due for an update. Unfortunately I have to give the usual caveat: I'm in the middle of a semester at university and have been pretty busy, so I can't give a time frame on the next update. I haven't figured out how (design-wise or technical-wise) OSP will integrate into some of the new features, namely KerbNet, so that might take some time as well.

All-in-all, when I get the ball rolling again, I'd like to roll the next update out with new and improved features as well as 1.2 compatibility. Specifically I'd like to fix the scan-skipping on high warp times and improve the method of data storage in the persistence file. I will also take a look at the much-asked-for-but-probably-given-up-on-by-now planet shroud feature and auto-updating the resource and biome map.

[Jiraiyah]

take your time, i am medical doctor and i still get nightmares seeing univ exams after 12 years of getting out of that hell  :D