pingopete

I understand, and none taken lol, the system used here is super hacky, and only really looks ok from orbit, there might be ways of mitigating it in the future to some extent, but for now I wan't to just get the 64k aspect of this mod working to some degree of reliability, might look at doing something like you suggest in the future though

Ok I haven't fired up EVE yet with the latest game, still waiting on some other dependancies, thanks for the info though, from my testing in ks3p 1.9.1 the AO looks absolutely fine so far. Took some pictures with the component space shuttle in orbit, turned out pretty nice Album below: https://imgur.com/a/ez0AGNM

OK thanks for that, I'll try out SMAA. And this is very concerning regarding no negative values, basically how everything on the dark side works, which version with EVE was this for? 1.8.1?

BTW if you guys aren't getting city lights as sharp/defined as this you need to do the 'eve city lights apply' trick (whenever the view position changes e.g. Atmosphere to Space, or loading a vessel; the city lights are placed on top of the terrain layer and thus show the rough mask resolution and do not shine through the 64k terrain cutout). Higher Quality Gif

Thanks for all the continued work on this, I will await Kop 1.9.1 to drop then will update RVE64k to the latest version of the game. Very interested to see graphical and performance differences in RVE moving from 1.7.3 to 1.9.1! Haven't touched visual modding since seting up 64k for 1.7. IIRC I remember seeing something about the engine now only rendering screen space pixels of textures improving performance.. or something to that affect, would be interested to hear if anyone had observed anything like this.

If I get some time I might try and update this to the latest ksp, required/recommended mods, and try and add support so this can be run with other planet visuals from other mods

Thanks for the link! I used a mixture of different methods for dividing into cube face, projection, and stitching. Ranging from Photoshop batch scripting, to imagemajik, to space engine cube tools. definitely took a while to get it all figured out but the space engine tool was invaluable for cube faces comprised of hundreds if not thousands of individual squares that needed stitching and is very customizible. That sounds nice, although I'm taking a break from modding endevours at the moment as I may be moving to the states for work so i have some more pressing priorities right now, I was also working on an ac130 mod for ArmA3. The cloud shadows cloud layer is a fake shadow layer that is necessary if you want the appearance of the cloud layer casting shadows on the sudo terrain layer, which doesn't receive the true shadows from the EVE system (as it's not actually land, and eve doesn't cast shadows onto cloud layers).

Yes I was using that but what I mean is my PS can't open DDS images at 16k or above without crashing, however I can save psb to DDS, I just can't open it after to edit unity isn't able to load single images greater than 16k, so that''s the hard limit afaik for single global terrain maps. Also thanks for posting that request, I asked around myself but the kop guys said it'd require a new re write of the whole pqs system to get tiled cubes working. Hence my reluctance to continue work on this in ksp1, KSP2 will hopefully bring much greater engine capabilites and I will certainly be keen to try and adapt RVE 64k to it. As mentioned above, this current method for loading 64k terrain as an EVE cloud layer is horribly hacky and is subsequently plaqued with bugs, but there isn't any other way to get above 16k terrain

I wasn't able to open or convert any dds over 8k without PS crashing to produce anything usable. Hence I was forced to use non-DDS, do the edits then convert down, each of the 16x16k cube faces for the terrain took 10+ minutes to pack into DDS from large photoshop format lol

The glowing white rings around the other planets are due to them not having configured scatterer shaders, RVE 64k only has (limited) support for Earth, no other planets have been adressed

Wow, is you pc the blue horizons super computer?! My performance with a barebones install was soso, but then my pc I'snt really that high end anymore these days. Are you using the detail texture mapped over the entire planet in that last pic? I can see the mirroring. Love a little secret ingredient in my installs too I thought up using the terrain texture as a city mask by cutting out a 64k city lights map from it effectively getting 2 64k textures in one, with only the performance drop from one

Thanks, I'm using the patch provided in the thread comments for KS3P, I used this method to make them, as using all the xported document text doesn't work and isn't formatted correctly, also some value don't export properly and remain as default unless you manually change them in the cfg. I may make individual configs for different scenes but at the moment I'm just using one for all like you. And yeah I still haven't been able to figure out how people saved textures with working mips, although it occured to me that I never manually defined an alpha channel and this had caused me issues before, so next time I have a go at the city lights I'll try messing with that

Hey so I gave that .dll a try, didn't seem to change anything sadly, did you try it yourself by any chance? I tried also increasing the PQS and SS far clipping plane for Kopernicus but it didn't change anything? Thanks again though for recompiling it

I deliberately have left out the skybox for the time being as I wasn't sure how KSP would handle running the 64k textures as well as additional stuff like that, in the old RVE I actually exported a realistic skybox from SpaceEngine, I believe there have been several skyboxes made for KSP already, so might be worth giving those a try, I can't recall the name of the mods which I used before, sorry Sorry I haven't done any work in the way of merging this with 1.6.1 myself but apparently it is possible as others have claimed to get it running here, someone else would have to chip in with there findings

Exactly it's completely broken. And ok, I guess I may just hold out then, the whole basis of this project was pushing 64k terrain or 32 at a minimum

Hey guys, so I'm working on a new project that uses textures larger than the 16384^2 pixels per texture unity limit. It's probably a bit of a long shot but I was wondering if there would be any way to integrate a cube mapping system for the ScaledSpace textures being mapped onto planets, allowing us to surpase this hard limit an achieve 64k texture resolution in KSP, properly mapped to surfaces? It'd be miles better than the current only method which involved pasting terrain textures onto a cloud layer just above the terrain while in ScaledSpace

Great seeing you again man! and thanks! Amazing! thank you so much, I'll be sure to test this as soon as possible!

1) not sure what you mean sorry 2) so basically the terrain 64k resolution will give a 1:1 texture pixel to screen pixel (1080p monitor) at around 300-400kms with a normal 75 degree fov, below this you get some blurring, above this texture pixels are smaller than screen pixels so you get effectively super sampling, that's terrain but the cloud has 1 pixel for ever four that the terrain has (32k) so I'm guessing that you'd need to be roughly 4 times as far for the clouds to be completely sharp, I prefer iss altitudes ~400km orbit, this looks nice with the terrain, for some reason whenever people take screen shots with rve they go to about 8000km which just wastes tons of the resolution of the textures lol

OK, I assumed this was the reasoning behind dropping the wip terrai support, I'll see what's possible in kopernicus

Thanks, but I've been trying those and they don't affect scatterer, I've found the exact line of code in the scatterer source code that controls it: Effects, Atmosphere, Utils, AtmosphereProjector: line 24: projector.farClipPlane = 4*Rt; I'm actually currently installing visual studios in an attempt to recompile the latest version of scatterer with this line modified to 8 or 10, but I have 0 prior experience making or recompiling .dlls. If you wanted to recompile that that'd be amazing, as I'm sure it'd take me days to get my head around the whole business. (I imagine that value being X'd by the planets radius would need to be like at least 7 or 8 instead of 4 Just so you know this is still very experimental,this wouldn't work with the 64k texture setup, I've already tried, we'd need an addition to EVE to allow us to map terrain onto earths land via cubemaps, I've posted a comment on the thread about that. Regardless it'd be cool to just see what this looks like with the 16k rss textures. Also godrays would be awesome, I looked back through the changelogs, apparently it was only removed for compatibility with MFD cameras and some ailiasting on the atmosphere

CrossPost from my mod thread for anyone interested: I recalled how good scatterer's height wrapping haze effect looked in PQS, sadly I completely forgot ScaledSpace doesn't use the height map to deform the Earth's surface, and Using the Earth Object model is far to low resolution for LEO scatterer, but I found that Scatterer can be tricked into rendering the height wrapping based of the PQS height map by raising the PQS deactivate distance, while keeping the fade in/out range at normal heights. Problems: Scatterer camera far clipping plane issue Scatterer rendering ocean edges from PQS Scatterer no longer supporting godrays for terrain which would've looked absolutely insane Album : https://imgur.com/a/5Fb9KU8 Non-Spherical ScaledSpace model in Tracking center Scatterer rendering haze from PQS heightmap, over 2D (or 3D object deformed) ScaledSpace flat surface textures I can't begin to imagine how good this would look with the 64k textures if EVE could wrap cube map terrain textures to the surface

I recalled how good scatterer's height wrapping haze effect looked in PQS, sadly I completely forgot ScaledSpace doesn't use the height map to deform the Earth's surface, and Using the Earth Object model is far to low resolution for LEO scatterer, but I found that Scatterer can be tricked into rendering the height wrapping based of the PQS height map by raising the PQS deactivate distance, while keeping the fade in/out range at normal heights. Problems: Scatterer camera far clipping plane issue Scatterer rendering ocean edges from PQS Scatterer no longer supporting godrays for terrain which would've looked absolutely insane Album : https://imgur.com/a/5Fb9KU8 Non-Spherical ScaledSpace model in Tracking center Scatterer rendering haze from PQS heightmap, over 2D (or 3D object deformed) ScaledSpace flat surface textures I can't begin to imagine how good this would look with the 64k textures if EVE could wrap cube map terrain textures to the surface

I didn't design this to work in 1.6.1 so it's down to people to figure that one out I'm afraid, I know people here have done it so I guess try with all the latest dependancies and just figure it out via process of elimination, I'm not aware of EVE having problems going back, I have no idea about kopernicus though. I may look into it but I feel it'd be going backwards assuming mods will eventually update to 1.7.3 or above. And yeah at some point soon I'll downscale the textures for terrain to 32k and put them in a seperate zip with the main DL

Pretty sure that's just the Eye Adaption, I thought this myself when looking at Earth from this exact angle - side on to the terminator, obviously you'd want the camera to ajust the aperture to the bright side in this instance but I think it always calculates it based on total screen space brightness so would average between night and dark in this instance. However I found without the Adaption it's virtually impossible to see the stuff on the dark side of Earth. Either way it was just my first shot and ks3p configs, and due to these preferences that no doubt differ between users I've left the ks3p configs as an optional extra.

Well thank you very much!!