Agost
-
Posts
195 -
Joined
-
Last visited
Content Type
Profiles
Forums
Developer Articles
KSP2 Release Notes
Posts posted by Agost
-
-
No. The ATM config is the only difference.
Perfect. Tweaking process started, I hope I'll get decent results. Aggressive after some time with Basic is a bit uncomfortable :/
-
DXT1 does not have a component for alpha, so it would be compared against RGB, wheras DXT5 has an alpha component and is used with RGBA textures.
Ah, yes, I goofed a bit. The resize factor should be squared to get pixel count factor, so resizing by 1/2 would result in x4 pixel reduction.
I'll make some tests. Even if it will take lots of time...
Is there any major difference between basic and aggressive other than the main ATM.cfg?
-
VERY good question. To answer this, we go to the math: an RGB or RGBA texture uses 1 byte per component per pixel, so that is 3 bytes for RGB and 4 for RGBA.
With DXT, those numbers become 1 byte per pixel for DXT5 and HALF a byte for DXT.
So, to get the same memory value out of your textures, you would have to shrink an RGBA texture by 4 to get the same usage.
Whichever you choose, textures WITH mipmaps are %33 larger.
DXT is lossy, so there is some color error, but overall, it should look better than an RGBA texture, and perform better too as it is yanked in and out of graphics memory.
How to choose between DXT and DXT5?
You said that a compressed pixel is 1 or 0.5 bytes, while RGB/RGBA uncompressed pixel are 3-4 bytes: but which compression scale did you take in account? 2? 4?
Moreover, if a DXT pixel is 1 byte, a resized RGBA texture with half width and lenght would have the same data size as the corresponding DXT compressed (but full size) texture, wouldn't it?
I believe they were talking about running it in x63, and then copying the cache folder out into ATM. Cache files are platform agnostic
I think that many mods which block x64 version don't even load their files with the x64 exe
-
No worries.
More memory usage & higher quality textures, though they are normal maps so you probably wouldn't really notice.
Since I'm tweaking settings, I have a question for you:
What's the main difference between compression and resizing? Is it better ( memory wise) compressing a texture with a scale of 2 or resizing a texture to half width and lenght? Which one gives better image quality?
-
Oh, haha, that is the nature of the bug... I realized I never implemented raw, uncompressed textures until it was too late, so when I did add them in 4.2, I altered the config so they would not have to be re-cached, and memory performance would still be similar.
So, what could happen if I set compress_normals on false in 4.2? Just more memory usage?
p.s.: sorry if I'm polluting this thread with lots of questions, tell me if I'm asking too much
-
Normal Maps aren't being compressed now. They were in 4.1.
So why does activetexturamanagement.cfg 4.1 have "compress_normals=false " while it is "compress_normals=true" on 4.2? D:
And I didn't confuse files, since 4.2 first loading is definitely many times faster than 4.1
-
Yeah. The only big difference is that the Normal maps aren't compressed. Considering there are quite a few 1024*1024 with mipmaps, that could easily account for the memory discrepancy.
But if normalmaps aren't compressed in 4.1, why does 4.1 use less memory of 4.2, which compresses them?
-
Yeah, It looks like the most likely cause is that the new version isn't compressing unhandled normal maps (which is expected) It is an easy change to make to allow an override if that is desired.
Did you take a look at the output log?
-
rbray89, here it is. https://mega.co.nz/#!Y5NjXI4A!shkanKIfaiYKEWET7RR1E4pueveNKBmdMxEDL6HL1YM
I'll add something I've noticed: I don't know if it's normal, but clouds create a strange effect on the horizon, which looks only temporary. I'm using BA and I've never noticed it, but it could have been just a lack of attention, or just so rare and fast which can't be easily seen. Here you are a pair of screenshot, the "anomalies" are on the top of the screen in the first image and on the islands in the second one, while there isnt' anything left where it was before. That's why I'm thinking they're just normal low cloud effects
Javascript is disabled. View full album
Moreover, my RAM usage was ~2.6 GB just after loading, ~2.7 GB on the first KSC screen, ~3 GB after: opening VAB and many other facilities, going in the tracking station and look at every celestial body twice ( from close distance ), loading a ship in the VAB and put it on the launchpad, then again load another ship and put it on the launchpad ( with a short fire test ). Didn't have time to launch and put something in orbit.
So, memory leak is definitely a bit bigger than 4.2 but 4.1 starts with much lower RAM usage. Moreover, after the first loading, successive ones are equally fast on 4.1 and 4.2 ( at least on my machine )
I hope it's enough, feel free to ask me more
-
alright, sounds good. Thanks for your cooperation
Started re-caching. Man, 4.1 is really slow, almost not responsive, even with a high end machine. On the other hand 4.2 works like a charm.
I'll upload the log as soon as I can, I wasn't at home before
-
Ok, could you provide the one with 4.1 now? (I Know, you would have to re-cache...) I think I have an idea of where the issues might be stemming from, but not 100% certain.
Not enough time this night... ( I'm in Italy) I'll do it tomorrow morning
-
That is exactly what I'm trying to figure out. Can you post your output_log.txt file for me? Is it possible you accidentally downloaded aggressive? or there is still a config in ActiveTextureManagement? (it should have moved to BoulderCo)
I downloaded both, but I only used Basic. I was using Aggressive before, I wanted to try the basic and I got those nice results.
However I've played a bit since I've installed 4.2, is my output.log ( the one in KSP_Data, right? ) still valid? Here it is https://mega.co.nz/#!Rs1VBSBK!o28WL-VF9R4OXDsEC3kvPbsmC88lnpJ9-UpJi_ynDlM
-
No... you would have to create a folder entry for every folder in GameData that doesn't already have a config.
Wait... and the ones that already have a cfg file? Like... all my mods?
I'm starting to think that those 400 MB less camefrom black magic.
-
Well... TBH, it shouldn't save that much memory. The only difference would be that normal maps would not be compressed. Everything else should be.
In my case the total saved memory difference was about 400MB... Without any noticeable quality loss
Can I do it by adding "compress=true" to every cfg file?
-
Corsair CX600; got it half a year ago.
Not exactly the best PSU out there, but it's more than enough for you PC. It was definitely overheating.
However, my beloved rbray89 ( no homo ): what about that whole decide-what-to-compress cfg?
-
Ok, cleaned the PC interior, removed the outer casing (for air) and rejittered the cables going into the motherboard to make sure they fit. The thing compressed all the textures without a blink; I could even ALT/TAB out (wasn't possible before). Moreover, loading now is fast and without any hassle.
What the hell x2?
Yes, it probably was overheating. So, what's you exact PSU model?
-
Here you go:
Win 7 64bit
AMD Athlon X2 250 Dualcore (3ghz)
8GB Physical RAM
16GB Virtual RAM
8GB Page File Space
AMD Radeon HD 5850 (1GB)
Corsair PSU (forget what wattage, but it's about roughly half a year old)
All in all it's an old rig granted, but it should run KSP fine (and has). In fact, I managed to compress ALL the textures the other day with 4.1 and 4.2; yet all of a sudden it causes the computer to utterly crash now. What gives?
Your CPU isn't the most suitable for a game like KSP, which likes intel cpus and very high ST performance. However, it's probably due to overheating, as stated before.
Open your case, clean your pc and look at what exact PSU you've got. That's the second most probable cause of the shutdowns
p.s.: it's a bit OT
-
Ok... now when I run the game, whenever the compressor tries to compress the Jool textures from Astronomers Vis Pack (I think its the cloud ones) my whole computer shuts itself down (with the monitor cutting off and the computer then dying down not long after). A reboot shows no problems at all.
...what the hell?
Can't help you without knowing the whole pc configuration.
-
Ah, stupid exadecimal. Can't even try to edit the dll
-
Potentially daft but quick question; I have Win 7 64-bit, but usually run KSP off it's 32-bit mode (for stability). Which version of Aggressive should I be running? x64 or x86?
x86 : the version is based on your KSP install, not on your OS
I just installed v4.2 x86 Basic and the game runs at over 3.5GB with the following addons:000_Toolbar
ActiveTextureManagement
AnimatedDecouplers
BoulderCo (Astronomer's Visual Pack - Edge of Oblivion 512k clouds, no optionals)
Chatterer
CrossFeedEnabler
EditorExtensions
EnhancedNavBall
EnvironmentalVisualEnhancements
Firespitter (plugin only)
Hydrogen NTRs
JSI
KerbalJointReinforcement
KWRocketry
MechJeb2
MechJeb2 Embedded by Dennis6492
NavyFish
NearFutureConstruction
NearFutureElectrical
NearFutureProps
NearFuturePropulsion
NearFutureSolar
NearFutureSpacecraft
NothkeSerCom
NovaPunch2 (only one part)
PlanetShine
ProceduralFairings
QuantumStrutsContinued
RealChute
SDHI
SelectRoot
ShipManifest
StationPartsExpansion
TriggerTech (KerbalAlarmClock and KSPAlternateResourcePanel)
ModuleManager.2.5.1
Is there no spoiler tag?
In previous versions I would be able to play for a bit, but normally a scene change would cause it to crash. However, now it basically crashes once I load the save game.
Did I miss a step or do something wrong? I had no memory issues with a similar setup in 0.24.
Running i5-2500k, 8GB RAM, Win 7 64-bit (launching game in 32 bit).
If it helps any, my textureCache folder is roughly 720MB.
I tried Aggressive, textureCache ~500MB, and it crashes consistently while assembling a modest rocket in the VAB. Similar memory usage.
That's because this versions does not compress everything. However, did you delete texture cache before changing release?
-
It was a default value in the dll. I'll have to add a config item for this I think. In 4-1 all textures were compressed to dxt regardless.
That would be very helpful and interesting!
I didn't notice any graphic or performance issue with all textures compressed, that's why I was asking how to do it
-
no... though, that makes me think about what happens with unhandled mods... Could be where the additional memory usage is coming from.
could be anything depending on the mod. Some use resource maps or read to get information (eg. EVE uses them as a map for volume cloud spawning).
Do you think you will implement a "fix" for unhandled mods? What was the cause for ATM 4.1 to compress every texture? I'd like to replicate this behaviour but I can't find anything relative to it in the general config file ( and the fast loading of 4.2 is too good to be ditched for the slower 4.1 )
Was it in the .dll file?
-
That one I'm not sure about. Likely resource maps and similar things. You would have to find the configs that say "compress = false" to "compress = true"
Is enabled=true equivalent to compressed=true?
I've also noticed that many cfg do not allow make-not-readable command. What could possibly go wrong if I make them not readable? Something like a memory leak when they get reloaded?
-
Memory usage might be up a bit for two reasons:
1) uncompressed textures are supported again. I had forgot about them during DXT caching, so they would always compress. Now, if the config says they shouldn't, they wont.
2) Very Large textures will actually load instead of being skipped (hence the missing clouds) Since these textures are HUGE, they add a good bit to the memory usage (EVE Kerbin 1 would use 8k*8k bytes... so about 67MB in memory. Astronomer has similarly sized textures too...
Which are exactly the textures that did get erroneously compressed? I'd like to compress them anyway :asd:
[1.0][Release-5-0][April 28, 2015] Active Texture Management - Save RAM!
in KSP1 Mod Releases
Posted
Just noticed that Interstellar ( Warp Plugin ), which takes a lot of memory, almost doesn't get any compression/resizing at all. Is there any reason for this? Maybe some issue with compression? Sounds a bit strange