Jump to content

[WIP][1.0.5]* RSS Visual Enhancements (RVE)


pingopete

Realistically what would you prefer in RVE? -- choose one from each letter  

2,062 members have voted

  1. 1. Realistically what would you prefer in RVE? -- choose one from each letter

    • A) 1 main cloud layer, 1 cirrus layer (Medium/Compromise)
    • A) Low, Medium, High cloud layers (Heavy/Realistic)
    • B) Detail bias towards Land/Atmosphere visuals
    • B) Detail bias towards Orbit/Space visuals
    • C) Realism
    • C) Detail
    • C) CPU accessibility


Recommended Posts

Forgive me, but how does this hold up in .25?

Untested, at least thoroughly, and RVE hasne't been update to it, as RSS won't run on .25-winx64 due to instabilities, sticking to RSS 7.4 / .24.2 for the time being. You can probably quite easily port this to .25 but you'd have to slash allot of textures to make it run.

Is this compatible with the stock planets?

Sorry no, so far this has been designed specifically for StandardRSS 'sol'ar system planets. It may be something I'll work on later though.

Link to comment
Share on other sites

We've finally made KSP look like real life...

Almost there! ;)

i tested in 0.25

RSS 2k textures (Kerbal/Mun 4K) Mem use 2.9 gb ram

RSS 2K textures (Kerbal/Mun 4k) WIP-RSS-Visual-Enhancements-DEV Mem use 6.8 gb ram

all max in ksp settings

it looks realy nice

Nice one, was that with rss 7.4?

Link to comment
Share on other sites

Lemme guess: is it the power of linux x64? One day I'll set aside enough disk space to try that, one day.

I'm on Windows x64, but I'm still running 24.2. The game.. could not be running better for me. Get this... I actually ended my play session last night by hitting quit to menu and then exit.. CAN YOU BELIEVE IT?! Lol I went from the 8k RSS textures to the 4k. That REALLY helped.

Link to comment
Share on other sites

Yeah gonna put that in the OP now, about the 8k's

Haha, no man. The credit goes to you. I'm just an enabler.

Haha.. no rbray, you are the creator,don't never forget that! I'm still discovering features you included I'd totally looked over. e.g. how transparency could be used in the texture detail to basically use the earth cloud texture as a mask for MUCH greater detail :D It's like procedural, but not continuous :P

Javascript is disabled. View full album

And spooks that's good to here, thanks for testing :)

Edited by pingopete
Link to comment
Share on other sites

Have you considered making the sun white Pingo?

haha yeah, that is a horrible mess of mostly incorrect textures lol, that blue spikes were in the wrong position on the DDS file, I've fixed that but the sun glare texture isn't bright enough on RSS because of increased distances from the sun, if any one know how to make this aspect of the sun brighter, please let me know. I was experimenting with a bluish flare, but I will probs use a white when when I get the brightness sorted.

Link to comment
Share on other sites

Howdy! I'm attempting to get this working with RSS 8.0, and I'm getting some layer weirdness. I'm well below the RAM limit, using EVE Overhaul 9-2 and RVE 0.2.2. Any suggestions as what I might be able to do to fix this?

Some notes: I rescaled all textures above 4096 to be 4096 or lower in dimensions. I did not overwrite the RealSolarSystem.dll and am using the one that came with RSS 8.0. All other .dlls in the RVE 0.2.2 package are being used. (When I overwrite the RSS .dll, I get a "not compatible with .25" message.)

Link to comment
Share on other sites

Howdy! I'm attempting to get this working with RSS 8.0, and I'm getting some layer weirdness. I'm well below the RAM limit, using EVE Overhaul 9-2 and RVE 0.2.2. Any suggestions as what I might be able to do to fix this?

Some notes: I rescaled all textures above 4096 to be 4096 or lower in dimensions. I did not overwrite the RealSolarSystem.dll and am using the one that came with RSS 8.0. All other .dlls in the RVE 0.2.2 package are being used. (When I overwrite the RSS .dll, I get a "not compatible with .25" message.)

Ashamedly this isn't to do with an incompatibility. This is the effect the 2D/fake atmosphere layers have on the 3D terrain. The layers only really work in ScaledSpace because I force it to use SphericalSSMesh through RSS so all the layers stay above terrain. This is the main reason this is WIP, until rbray has time to finish the Atmosphere shader, there are few other options I'm afraid :(

Link to comment
Share on other sites

Note that at least as far as RSS is concerned (although this is also true for EVE, I just didn't get around to making that file, and is true for ATM see below) you can do what you want by making your *own* RVE folder, putting these cfgs in it, and putting EarthColor.dds (note dds!) in the RVE folder, and EarthSurface.png in RVE\PluginData

This way it doesn't require overwriting anything RSS (since any files in PluginData don't get loaded, there's no harm in leaving the original RSS textures lying around).

RVE.cfg:

@REALSOLARSYSTEM:FOR[RVE]
{
@Kerbin
{
%SSFStart = 94000
%SSFEnd = 100000
%PQSfadeStart = 100000
%PQSfadeEnd = 120000
%PQSSecfadeStart = 100000
%PQSSecfadeEnd = 120000
%PQSdeactivateAltitude = 125000
%SSColor32 = RVE/EarthColor
%SSBump = GameData/RVE/PluginData/Earth_NRM.png
%PQS
{
@Kerbin
{
@Add
{
@PQSMod_VertexColorMapBlend
{
@vertexColorMap = GameData/RVE/PluginData/EarthSurface.png
}
}
}
}
@AtmosphereFromGround
{
%innerRadius = 6357290 // 0.99
%outerRadius = 6496000 // 1.025
%waveLength = 0.65, 0.6, 0.5, 1.0
//invWaveLength = 0.75, 0.82, 0.89, 0.55
%ESun = 20
%Kr = 0.0008
%Km = 0.0006
}
}
}

RVE_ATM.cfg


ACTIVE_TEXTURE_MANAGER_CONFIG
{
folder = RVE
enabled = true
OVERRIDES
{
RVE/.*
{
compress = true
mipmaps = true
scale = 1
max_size = 0
make_not_readable = true
}
}
}

This is occasioned by my actually, finally getting to try RVE (in very stripped down form--I can only use one cloud mask, and no planet but Earth, and very few mod parts). And HOLY CRAP IT'S AMAZING.

But please, please put it up on github so the above could be a pull request, not just posting in the forum :)

Link to comment
Share on other sites

Note that at least as far as RSS is concerned (although this is also true for EVE, I just didn't get around to making that file, and is true for ATM see below) you can do what you want by making your *own* RVE folder, putting these cfgs in it, and putting EarthColor.dds (note dds!) in the RVE folder, and EarthSurface.png in RVE\PluginData

This way it doesn't require overwriting anything RSS (since any files in PluginData don't get loaded, there's no harm in leaving the original RSS textures lying around).

RVE.cfg:

@REALSOLARSYSTEM:FOR[RVE]
{
@Kerbin
{
%SSFStart = 94000
%SSFEnd = 100000
%PQSfadeStart = 100000
%PQSfadeEnd = 120000
%PQSSecfadeStart = 100000
%PQSSecfadeEnd = 120000
%PQSdeactivateAltitude = 125000
%SSColor32 = RVE/EarthColor
%SSBump = GameData/RVE/PluginData/Earth_NRM.png
%PQS
{
@Kerbin
{
@Add
{
@PQSMod_VertexColorMapBlend
{
@vertexColorMap = GameData/RVE/PluginData/EarthSurface.png
}
}
}
}
@AtmosphereFromGround
{
%innerRadius = 6357290 // 0.99
%outerRadius = 6496000 // 1.025
%waveLength = 0.65, 0.6, 0.5, 1.0
//invWaveLength = 0.75, 0.82, 0.89, 0.55
%ESun = 20
%Kr = 0.0008
%Km = 0.0006
}
}
}

RVE_ATM.cfg


ACTIVE_TEXTURE_MANAGER_CONFIG
{
folder = RVE
enabled = true
OVERRIDES
{
RVE/.*
{
compress = true
mipmaps = true
scale = 1
max_size = 0
make_not_readable = true
}
}
}

This is occasioned by my actually, finally getting to try RVE (in very stripped down form--I can only use one cloud mask, and no planet but Earth, and very few mod parts). And HOLY CRAP IT'S AMAZING.

But please, please put it up on github so the above could be a pull request, not just posting in the forum :)

Wicked.. My own mod folder :D TBH I don't know why it never occurred to me to write the addresses to my own mod folder anyways!

What's a PullRequest? Is gitHub free then?

Are DDS files really so compressed/fast that having residual RSS png texures doesn't matter?

Why wouldn't any files in *which*? plugindata folder be loaded sorry?

Also didn't really understand your post over on your thread, earthsurface.dds DOESN'T work? but all else do? how about normals?

Oh and one other thing, if I do switch over to DDS will I need to use the new DDS loader by sarbian?

And about the crashing, I know, it's super heavy loading and inefficient atm, when I get more time, I'll run back though and sift out any unnecessary memory usage.

Edited by pingopete
Link to comment
Share on other sites

Github is free, yes, and a Pull Request is basically someone making a copy of your repository, making a change, and then sending that back as a suggested change, where if you like it all you have to do is click "merge,"

Here is a page describing how KSP handles textures. What happens is that all supported images in GameData are loaded, along with all CFGs and MU files and WAV files and...etc. The only exception is: if a folder is named PluginData, KSP won't look inside it.

As each image is loaded by the KSP loader, it's converted to DXT1 or 5 (.dds is the file extension for DXT images btw).

For RSS, I keep all textures under a PluginData folder, which means they are invisible to KSP's loader, and thus they are only loaded by RSS itself. This is so that I have complete control over how and when they are loaded, and whether or not they are kept in memory after their job (creating a heightmap PQSMod, say) is completed.

Sarbian wrote a loader for .dds images. The advantage to them is that they can be loaded directly to the video card, rather than first being loaded into RAM, decompressed if PNG or compressed-TGA, then compressed to DXT1 or 5, *then* sent to the video card. There are even bugs with the stock loader, and it leaks memory, so avoiding it is quite useful, even apart from the fact that loading from DDS is about 30-100x faster than loading from PNG due to all the skipped steps.

The downside is that that loader does not keep the texture "readable" in RAM, and thus cannot be used for the cloud mask, or for RSS's heightmaps or vertex color maps. However, for scaled space maps, which need not be kept readable in RAM, it works great.

The tl;dr is this: Any texture used in a PQSMod must, for now, be kept as before: as a PNG that RSS loads itself. This includes textures that are used *both* as scaled space maps *and* for a PQSMod, like MoonColor. If it is *only* used as a scaled space map, like EarthSurface or Moon_NRM, then it can be taken out of PluginData and made a dds so KSP loads it normally (via Sarbian's loader).

Link to comment
Share on other sites

Ok thanks for the info, that all makes sense now, sorry about my incessant questions, I'm abit new to it all :P I've uploaded all previous versions to my new github, (link on the OP) now just tryna figure out where I can place a release that can be continuously updated.

Link to comment
Share on other sites

Ok thanks for the info, that all makes sense now, sorry about my incessant questions, I'm abit new to it all :P I've uploaded all previous versions to my new github, (link on the OP) now just tryna figure out where I can place a release that can be continuously updated.

I think you should try either Curseforge or Kerbalstuff. Handling new releases should be easy on these.

Link to comment
Share on other sites

This thread is quite old. Please consider starting a new thread rather than reviving this one.

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