rbray89

The long loading times should only occur once (or after you add a big mod).

Hold-up here, what textures did you have problems with? ATM shouldn't do anything like that, it preserves alpha.

To those with the HEAP error: A couple questions: I noticed a pattern that those with the error have 32 bit machines running windows... is that correct? There may be something we can do, but it will probably mean disabling the multithreaded option. Please add your windows version, processor core count, and ram size.

Firstly, I can't do anything with just this. This doesn't tell me what platform you are on, how much memory you have, and most importantly, you don't provide the logs. Secondly, I'd appreciate it if you keep support questions on the mod thread. Not only does it mean that the community that uses ATM can help provide support, but other users with similar issues can expand and help elaborate on what is going wrong. So please collect the log, gather the info I mentioned (windows/mac/linux version and architecture (32 or 64 bit), ammount of Ram, CPU count, etc.) and create a post in the ATM thread

Both are normal.

The whole idea is that for one small payment of an hour or so, you get several minutes off of each following load. A bonus, is that because they are being loaded as DXT, there are no memory leaks that normally show themselves when using Unity's texture loading. There is no way to disable DXT compression without disabling compression entirely, and believe me, unless you are running stock, you don't want to do that. Watch a show, read a book, or browse reddit for a while as it loads . As KSP consumes more, and more memory on each new version, we had to get creative to save memory. This is one of those ways.

Wow that looks great! Love the textures.

The cache file is only loaded in-place of the original texture. No original texture, means we don't load a cache file. That being said, ATM won't automatically clean the cache out either.

Alright, this should be a pretty easy change I think. - - - Updated - - - 2) the idea being that it should be the absolute smallest any texture should go down to.

Do you have an example? There are minor issues that go along with this, but they might be able to be worked around.

and more with equator proximity? I like it. I'll have to look into doing this.

TECHNICALLY, you have a Voltage, and resistance, which specifies the Current draw (amps) Amps (Ampere) translates to Coulombs per second. Coulombs are a number of electrons. A certain number of electrons at a given eV have a certain potential (jouls) so, you can multiply Coulombs by voltage to get Joules. Joules over time is Wattage. So, we have "Power (Watts) = Voltage*Current (Amps). Realistically, parts specify a MAX number of wattage (based off of voltage and current draw), hence why your power supply that says 90W (laptop) or 1000W (desktop) doesn't ACTUALLY use that much power at any given time. Note that Power (wattage) is a unit of energy per given time. This is often why capacity of batteries are provided as A*hrs or mA*hrs. Along with the voltage, you can calculate the Power that the battery can provide, for a max time. eg. A 4Ahr battery at 12V, could provide 4A for 1 hour at 12V, or 1A for 4 hours at 12V (not necessarily, usually batteries have max current draws, so you couldn't get 4000A for 1/1000th of an hour.). This would equate to 48W for 1 hour, or 12W for 4. From those, you can get the Joules that could be provided. Soooo... Realistically, parts that draw/generate electricity should use Watts as a resource draw indicator, and storage mediums (aka. batteries) should use Joules/KJoules or W*Hrs. There should be no mention of current (Amperes) unless you also plan on introducing voltage. Disclaimer: I'm a Computer/Electrical engineer with a B.s. in Computer Engineering.

Ha! Funny! I did pretty much the EXACT same thing with KSP for my EVE overhaul... The atmosphere effect and ocean depth changes I'm working on required a working depth buffer, so I extracted the Squad shaders so I could add the "RenderType" shader tag to them. I then grab all the materials and forcefully replace all the shaders. I do this at the begining before parts are created, so when the parts are duplicated, they bring the new shader with them. I also go through the cameras and enable the depth rendering. It works pretty well for me, but unfortunately, as you said, the multiple cameras thing is tricky. So far, I've resigned to only doing depth stuff on the "Far" camera, and making sure the effects "fade in" as they approach the camera before they hit the near clipping plane. You can check out all the work I've done so far at https://github.com/rbray89/EnvironmentalVisualEnhancements/tree/Overhaul

Yeah, that would be the idea. I've been thinking of integrating the 2d cloud layers into the atmosphere rendering as an optimization/enhancement anyways. The downside is that there would be a hard limit on the max number of 2d cloud layers (probably 2-3).

Hey All! I was thinking about creating a shader loader for EVE, and then it occurred to me, why not just make it a new standalone plugin? The idea is that it would read in all files ending in *.shader, load them up in unity so that they can be called on with Shader.Find(). I *think* this should work with parts, but I'm not entirely certain. This could mean authors could craft their own shaders for specific uses, and have an easy way to get them into KSP. Thoughts?

Yeah, I have to figure out a good lighting system to correctly render the scattering and (hopefully) red sunsets:) In other news: https://www.desmos.com/calculator/pisfzpljko I think I finally pegged down the correct form to generate a realistic atmosphere. Modeling density as an inverse function of radius (instead of the root as I had assumed) and taking the integral leads to a summation of the density along the path traveled. At least, this is the theory... I have two different functions to try out

The cache *SHOULD* automatically detect config changes, new mods, replaced textures, etc. There is a hash for the textures that we use to verify original texture changes, and we store the old and new size of textures in the cache config files to check against.

ATM is working as intended. Sarbian (who wrote the multithreaded portion of ATM) implemented it such that all available cores/hyperthreads are utilized to their full potential to try and get the caching done as soon as possible. If your computer is overheating, I'd suggest that you look into your thermal design. I assume you built your rig? You need to look at the specs for the processor, get the thermal wattage at full power, and use that as the basis for your cooling design. Your heatsink is probably undersized if you are worried about killing your CPU. Also note: CPUs have thermal protection in them. They will automatically shutdown once they cross a certain threshold. You are very unlikely to blow it unless you are running without any sort of thermal mitigarion attached.

Interesting... I have no idea why that might happen. This may be a bug with KSP.

That is kinda the point. This mod compresses textures on load. This takes a TON of CPU/memory. Read the first post. If it doesn't work, retry. KSP 32-bit can only index 4Gb of ram, so it doesn't matter how much your computer has. You just have to wait for it to cache all the textures.

I'm already doing this for my cloud's shadows using projectors... Shouldn't be too hard to add it as an effect within my shadow projector shader.

This is on my EVE to-do list

I finally implemented the atmosphere change... you can try it out to see if it works for you. I may have to add an additional variable though. I also need to figure out a better lighting model.

We compress a few more files in 4.3, more configs, etc. I'd suggest temporarily removing some mods that have already been cached, just to let it finish, then put the mods back.

Maybe in the future...