Jump to content

rbray89

Members
  • Posts

    2,719
  • Joined

  • Last visited

Everything posted by rbray89

  1. This is an issue that SQUAD needs to address. They don't use proper render queues more often than not, introducing items like these.
  2. I've been seeing weird stuff from my Nvidia driver this week with/without DTL. I update it on a regular basis, and last update was rather recently.
  3. That's a decent Idea.... I use MSI afterburner myself. I wish unity had some profiling objects available so we could display memory usage. Will do. Not a good way of doing this aside from in the texture loader. Though I guess we *Could* override it like ATM does.
  4. Using this release: https://github.com/rbray89/DynamicTextureLoader/releases/tag/DTL-1.4 My Results so far: https://docs.google.com/spreadsheets/d/1K4PbZKUeqfnJEiDWATf0VlVAzFRFbTGuQV2krammYYo/edit?usp=sharing Procedure: Perform entire load to craft once. Then restart KSP using the different graphics profiles. Settings: full texture resolution, windowed, 1280x720
  5. Awesome. I'm just running a suite of tests on my current loaded install, and I'll give this a shot soon once I'm done.
  6. Sorry, I didn't think about it until just now. Looks like it shouldn't matter too much though I think. might matter more if the original graphics were PNG format though it seems. Actually, I'm pushing a new version that would be best to load the vessel of test first then exit You guys really don't have to do all the profile work right now. I've seen enough from your results that It substantiates my thoughts that one of your mods is holding this one back. If you have a CKAN build, that would be fantastic, or even a zip of your GameData folder if you can afford the bandwidth somewhere.
  7. Not sure why it'd be eating system ram. Note that you probably shouldn't be summing these values, as they are state-based. Other than eating system ram, these values are closer to what I'd expect. And another important thing... If you are doing these tests, be sure to let it load and cache the resized textures once, then run again.
  8. I think I'd expect a bit more savings on the stock install... the results you have look like the resolution isn't set to full or something... I'd expect more savings from the modded section for sure. Think similar performance to stock or better. Also keep in mind that display size will affect graphics memory too. I think I'm going to have to start installing more mods to see where the issue lies. For reference, my "Test" install looks like this: 12/25/2015 07:52 PM <DIR> 000_Toolbar 12/25/2015 07:52 PM <DIR> B9_Aerospace 12/25/2015 07:52 PM <DIR> CommunityResourcePack 12/25/2015 07:52 PM <DIR> CrossFeedEnabler 12/25/2015 07:52 PM <DIR> DynamicTextureLoader 12/25/2015 07:52 PM <DIR> Firespitter 12/25/2015 07:52 PM <DIR> FuelTanksPlus 12/25/2015 07:52 PM <DIR> InterstellarFuelSwitch 12/25/2015 07:52 PM <DIR> JSI 12/25/2015 07:52 PM <DIR> KAX 12/25/2015 03:20 PM 1,397 KAX_ReadMe.txt 12/25/2015 07:52 PM <DIR> KineTechAnimation 12/25/2015 07:52 PM <DIR> Klockheed_Martian_Gimbal 12/25/2015 07:52 PM <DIR> KWRocketry 12/25/2015 07:52 PM <DIR> ModuleAnimateEmissive 12/25/2015 03:25 PM 60,928 ModuleManager.2.6.13.dll 12/25/2015 04:23 PM 3,405,486 ModuleManager.ConfigCache 12/25/2015 04:23 PM 148 ModuleManager.ConfigSHA 12/25/2015 04:23 PM 6,605 ModuleManager.Physics 12/25/2015 04:23 PM 44,444 ModuleManager.TechTree 12/25/2015 03:23 PM 719 ModuleManager_README.md 12/25/2015 07:52 PM <DIR> MP_Nazari 12/25/2015 07:52 PM <DIR> NearFuturePropulsion 12/25/2015 07:52 PM <DIR> OPT 12/25/2015 07:52 PM <DIR> PlanetaryBaseInc 12/25/2015 07:52 PM <DIR> RcsSounds 12/25/2015 07:52 PM <DIR> ResGen 12/25/2015 07:52 PM <DIR> SmokeScreen 12/25/2015 07:52 PM <DIR> SpaceY-Lifters 12/25/2015 07:52 PM <DIR> Squad 12/25/2015 06:05 PM 852 toolbar-settings.dat 12/25/2015 07:52 PM <DIR> Virgin Kalactic 12/25/2015 07:52 PM <DIR> WarpPlugin If anyone has a .ckan file that they can share that has a ton of part mods installed where you are seeing less than great performance, that'd be great.
  9. What windows version are you running? what is your mod list? The thing that concerns me with DX9 is that you are already so close to the mem limit. The other thing that I'm having trouble understanding is why there is no difference in your graphics memory for DX11/OpenGL and why the memory usage is so low. On a KSP version loaded with mods that starts up normally around those marks I see a LOT more usage of graphics memory. Are you running with half-textures? Note that only part mods are affected as well. Graphics mod textures like EVE won't be impacted. Also, I'd expect the DX9 graphics mem to be much lower.
  10. Personally, I recommend DX11 if your system can use it, then dx9 then OpenGL.
  11. My guess is that there is a mod preventing DTL from working properly.
  12. Hmmm... The graphics is maxed on OpenGL, yet the system memory usage is virtually unchanged? I'm wondering if you are using shared system/graphics memory? in spillover? In which case you probably won't notice it in the KSP memory usage.
  13. Then it probably needs to be re-compiled.
  14. Pretty simple to compile, but I have no idea if it will work by default in 1.0.4.
  15. This is impossibly difficult to understand. I have no idea what you are trying to say here. There are glitches in the last iteration which I'm trying to get to soon. Great! The latest version should help a LOT with that, as the log files are MUCH more verbose and very specific, pointing out what config items failed parsing. This should help a lot.
  16. Parts only. They are the only thing that is "predictable" enough to do reliably with decent performance. gpuZ is a good application to use.
  17. That comment was directed at the other person I quoted. The forum auto-merges two replies into one now. It does cache. We cache the small textures so that unloading is much faster. We don't cache the regular sized textures, though we probably could do that too... though it'd take up a lot of memory.
  18. I'm not sure if this will address the issue... basically, I was only using one type of renderer to check, and missed some types. If there is a collision with another mod, I haven't found it yet. Are you using the latest release? There shouldn't be lag during flight from deleted (exploded) parts. There also shouldn't be lag when deleting a part until later when a new part is added.
  19. Updated to new release. FIxed issue with certain jet engines, and changed to a mechanism that only unloads textures when new ones are requested. Should save time in loading and unloading between scenes/ships.
  20. The newest version (1.2) unloads textures as the parts are loaded, and after the first run, will unload them once the textures are loaded! This means the only instance it would crash is if there is literally no other way to run the game.
  21. What was the last version you were running? the last version (1.2) included a fix for something that sounds exactly like you are describing.
  22. I included the entirety of the license header from Kopernicus including all authors in the code source where the DDS loading code is. Yeah, it's a neat trick. I was playing around with the idea of using a partmodule that would destroy and re-instantiate the texture, but this had obvious issues with the previews in the Editors. When I happend upon an interesting undocumented feature of Unity's LoadImage method. It works on unreadable textures. This means you can resize and re-load (PNG) textures on the fly even if the graphics object is inaccessible! It keeps all the original properties of the original texture (compression, mip-maps, readability) and it unfortunately requires PNGs, which means we have to re-encode graphics to be PNG. But it seems to work well enough. Haha, though to be fair, they are probably planning something a little more complete (meshes, part modules, animations, etc.) to be dynamically loaded and not just textures.
  23. Hmm... do you have a logfile for your install without my mod? I think there is a conflict with something. Possibly procedural parts.
  24. Updated to fix a minor issue where textures were prematurely unloaded in flight when multiple parts of the same type were involved.
×
×
  • Create New...