Jump to content

Proot

Members
  • Posts

    1,068
  • Joined

  • Last visited

Posts posted by Proot

  1. I have an update really close to be ready. Lighter in memory but with better look, and with much better fps performance. I've improved the clods (textures and particles) in almost all planets, some terrain textures too. The hugest clouds has been converted to the EVE cubemaps, wich looks much better than the old system. I've overhauled the terrain scatters in all bodies and I've added that scatters in some bodies where before there hadn't.
    Now you can climb or hit the trees, rocks, cactus.... there are rocks and sea weed in the oceans. And well, wait to see the crags at Duna...
    We just need and update in EVE to solve a gap in the clouds, and I need to solve an inconsistency in the terrain scatter collisions (I guess is my fault somewhere in my Kopernicus configs, but its hard to find it).
    Then it will be released. ;)

  2. Just now, Poodmund said:

    It happens when the PQS Fade is initiated, the Cloud Layer renderer seems to stop working until PQS has been 100% faded in. I reported this with a description, logs and a video a while back but not sure whether it was seen. Anyhow, I will log it as an issue on the Git repo.

    AFAIK, it might be worth waiting for a fix to be committed rather than trying to fudge KSP's own workings to get around it as it may introduce more issues than solve.

    Rbray is pretty bussy lately with Dynamic Texture Loader, but I bet he gonna fix this as soon as he can. Anyways +1: IMHO is better to wait for a fix than just try to avoid it (if this were avoidable would not be an issue).

  3. 4 minutes ago, Sigma88 said:

    Have you tried setting everything to a fixed number?

    For example 160000 or 55000?

    That shouldn't leave any gaps, but the transition will probably lose the fade and skip directly between pqs and scaledversion

    I know @Poodmund reported this multiple times, maybe he already tried this...

    If you need help with the cfg let me know, I'm happy to share the few things I know

    Ugh, I've spent a month precisely working in avoid the stock gap in the change from SS to PQS. That solution would make the change even more harsh than stock. Don't seem suitable for me.
    Anyways I'm not requesting a solution right now, I just want to report the issue and help to solve it. Many thanks for your help anyways! ;)

  4. I've tried the last github master version, but I still have the problem with the clouds altitude. Is this known?

    The clouds (not the shadows) dissapears in the change from Scaled Space to the PQS scales. So in Kerbin, as example, we have a gap in the clouds from the 160000 meters (end of scaled space)  to the 55000 meters (PQS complete "deploy").

    I've tried to change the heigths with Kopernicus. Changing the fade of ScaledVersion to 159000-160000 (instead 55000 to 60000) you can avoid the clouds gap but -obviously- then you have a gap where the terrain dissapears in the range of 60000 to 130000 meters (which is the fading of the PQS scale).

    This doesn't seem to left any error in the debug but I'll try to leave you here my logs ASAP.

  5. I've been using the experimental version for a while. I must say that works very, very well, looks great and is truly perfect for a stock install.
    But for heavy-environmentally-modified installs (like with KSPRC), where the scenes become more complicated, the experimental version does a visible impact on frame rate. A similar thing happens with particles systems in Kopernicus and with Texture Replacer Relfections (which works in a similar way to your experimental version but generating a small cubemap of the scene). The fps drop is completely logical: if we stack several shaders (EVE+Scatterer and so on), particles (EVE+Kopernicus), huge textures (clouds, details and so on)... at the end we have a bottleneck.
    It's not your fault at all, maybe with Unity5 we will see an improvement in all this aspects but, meanwhile I want to do a humble request: would be possible to maintain both ways? I mean the current color config system and the experimental version, to be able to use one or other as needed?

  6. I'm turning the biggest textures to the cubemap system and I must say this: congrats @rbray89, looks much better than the old system and with a sightly less memmory usage. The terminators and the colours of the clouds seem much more nice and accurate (not so dark at the sunsets/sunrises as with the "base" system"). Also, as you pointed time ago, the map look less deformed and "clean" with an equivalent texture quality.

    Very well done!

  7. 6 hours ago, rbray89 said:

    The slight artifact is a result of re-loading the textures and saving as PNG. It results in "double" compression. I have a couple ideas on how we could get around this though. Ironically, the artifacting is due to the original textures being dds (compressed). If squad never added the dds loader they'd look better :)

    Mainly caused by the normalmaps compressed in DXT, yes. And I don't know if you can change that behaviour but... despite that bc3 compression of the DDS/DXT format is quite bad in quality terms... something in the way where GIMP saves that format makes the results to be much better than with any other software.
    It uses some writing way whose artifacts are not so noticeable (those normalmaps get a pink aspect, instead the usual grey aspect). Recommended!

     

  8. 5 hours ago, SkyKaptn said:

    @Proot Is your scaledspace texture downsized for public release because of memory limits, and is there a "developer's ultrahypermega resolution" for your own devkit?

    -Just asking because I run 64bit and memory is of no concern. I lowered scaledspace to 65000m and things get somewhat fuzzy at that altitude.

    Textures are generated and sized to look the better they can do it, related to the size of the bodie/object and the memory cost. That is usually the double of stock. Going to higher sizes don't add very much: will be not related to the PQS scales and color heightmaps are blurried by default, so you only get a bit of sharpness in scaled space, with an excessive cost of memory.

    The problem is not the texture, are the stock changes between PQS and scaled space, and I'm working on that, to avoid the "gap" effect and set the scaled space at more "correct" heights.

    I don't have the textures at higer resolutions, but I'll do it in the future, with the unity5, the official 64 bit windows version and the multithreading support. Just not for the moment.

  9. 4 hours ago, Murdox said:

    Your welcome and glad you got it work! Okay so you have 32bit game, DTL and Half-Res textures working right now, but one more thing i would like to suggest to try with is dx9 instead of dx11. I think it should reduce RAM usage even more than dx11 and you may get even more fps/performance with dx9. also VRAM savings with dx9 + DTL is awesome if you can pass that loading screen. Idk if you tried with it already this was only my assuming. i think magical limit is near 3.3 - 3.5gb at least for me.

    If you want to try it out command is:   -force-d3d9

    Edit: Also apologies to Proot... we're filling your ksprc topic with helpdesk things here :D

    In fact I appreciate the favor, a lot. If I dedicate my time to solve all this "small" things, with my crappy and slow english, all would be much more slow and worse...
    But seriously, I wait anxiously the update to Unity 5, basically with the expectation of send to the oblivion most of the memory problems... This thread has much more messages related to the memory usage than with the mod by itself.
    Anyways, as I've said many times in past pages: atm is hard to play this in dx9/windows without "tweaks" in your install; dx11/windows does it better but has some problems (as black Jool)... so the best choice, in memory saving and in general terms, -imho- is to force OpenGL in windows.
    I play with several mods (not parts), forcing OpenGL, without memory crashes. For me the only problem with OpenGL is the lack of antialiasing, but I can force it in the GPU options, so is not a problem at all.

  10. 3 minutes ago, Bandus said:

    To be clear, my concern here isn't the haze. My concern is the the fact that when I zoom in slightly towards a vessel, all the ground textures go to jaggedy and..not pretty. Also, you can't see it in the screenshot, but in real time the outline of the continents has like...moving lines...on them? 

    I really appreciate all the effort into this but if I've done something wrong I'd like to fix it OR if I can help resolve a problem with the mod I'd like to do that too! :)

    Is not a "problem". The Ocean Shader in Scatterer is simply not finished yet. I've talked about this gap with @blackrack he will work on it, but he not even has a GPU right now... So if you want this detail "finished", sadly you need to wait. Of course, if you want/can lend him a hand to get a new GPU, probably the work will be done sooner:

    http://forum.kerbalspaceprogram.com/index.php?/topic/103963-wip-scatterer-atmospheric-scattering-v002182-24122015-ocean-shaders-get-them-while-theyre-hot/&page=1

  11. Textures are like they are, no by caprice but to fit with everything else.
    You can add a lot of thing to the texture, but at the end it will not be in the surface, so imho that have no sense. I don't have as goal to add just eye candy to the game, I have as goal to enhance the stock game as much as possible.
    That means that what you see in the KSPRC texture is exactly what you have in the surface.
    With the Unity5 enhancements I have the hope of have more memory room to add PQS details to Kerbin with Kopernicus, wich could do similar changes, but at all levels.

    But is not possible atm, imho, with the current memory management/limit.

  12. On 31/12/2015 at 6:47 PM, blackrack said:

    Alright, I'll see what I can do. It might be a while though, my GPU died and I'm right in the middle of oven baking it :(

    I've done a contribution, to thank you for your efforts and to push for the continuity of this awesome project.
    Hope more people do the same to help if needed.

    Many thanks for your work!

×
×
  • Create New...