[1.1][1.1-1] Apr-19-2016 Dynamic Texture Loader

[Proteus]

would like to report something,the icon for ambient light adjustment mod is completely white when shown in blizzy toolbar.

im talking about this mod http://forum.kerbalspaceprogram.com/index.php?/topic/64901-105-ambient-light-adjustment-1542-101115-continued/

and the opt space plane mod textures in vab are blurry and low pixel,i know this is part of the effect of the mod,but is there a way to repair it in the next future updates?

but other than that this mod is amazing,thank you for this mod.

 

[Green Skull]

Glad to see you are still making KSP a more awesome place rbray! Keep up the good work!

[rbray89]

On 1/13/2016 at 1:03 PM, plausse said:

Freedomtex and the tantares texture one (can't remember the name). I could give better details and or logs if it would help... When im at home. Maybe it's just me ruining the paths with bad vibes?

I can't replicate this. Try deleting the cache folders in C:\Users\rbray\Documents\ksp\ksp-x86-1-0-5\GameData\DynamicTextureLoader\Plugins

On 1/13/2016 at 1:47 AM, helaeon said:

I think I may have discovered a bug with 1.6.3. It appears when using TextureReplacer the default KSP textures are loaded for the EVA helmet rather than the texture in the TextureReplacer folder. The other textures it appears are loading as expected, this is new with this version.

I can't replicate this. Try deleting the cache folders in C:\Users\rbray\Documents\ksp\ksp-x86-1-0-5\GameData\DynamicTextureLoader\Plugins

On 1/15/2016 at 5:29 AM, Proteus said:

would like to report something,the icon for ambient light adjustment mod is completely white when shown in blizzy toolbar.

im talking about this mod http://forum.kerbalspaceprogram.com/index.php?/topic/64901-105-ambient-light-adjustment-1542-101115-continued/

and the opt space plane mod textures in vab are blurry and low pixel,i know this is part of the effect of the mod,but is there a way to repair it in the next future updates?

but other than that this mod is amazing,thank you for this mod.

 

I can't replicate this. Try deleting the cache folders in C:\Users\rbray\Documents\ksp\ksp-x86-1-0-5\GameData\DynamicTextureLoader\Plugins

[theonegalen]

So if this is based off of Thomas P.'s work on Kopernicus, is this mod still helpful if I'm running Kopernicus?

[rbray89]

29 minutes ago, theonegalen said:

So if this is based off of Thomas P.'s work on Kopernicus, is this mod still helpful if I'm running Kopernicus?

Kopernicus only loads body textures on demand. This is for parts.

[theonegalen]

9 minutes ago, rbray89 said:

Kopernicus only loads body textures on demand. This is for parts.

Awesome, thanks.

[plausse]

I tried what you (rbray89) suggested - still no normal maps for the extra procedural parts textures, although the quality is normal with the latest version. As they are referenced from a different folder I tried putting them in the main PP folder (and changing the paths), still no normals.. I then thought it might be because they are referenced with module manager, so I put them in the main config, still no change. I then re-installed everything the way its supposed to be, still no normal maps (bet you didn't guess that). I then removed DTL and all normal maps came back again. But the game crashed after ten minutes.

My conclusion is that it probably is an interaction with something you didn't have when you tried to verify it as a bug. My next burden must be to find out with what. I really should have waited to type anything until then I guess. But I didn't. Great mod still. 

[rbray89]

22 hours ago, plausse said:

I tried what you (rbray89) suggested - still no normal maps for the extra procedural parts textures, although the quality is normal with the latest version. As they are referenced from a different folder I tried putting them in the main PP folder (and changing the paths), still no normals.. I then thought it might be because they are referenced with module manager, so I put them in the main config, still no change. I then re-installed everything the way its supposed to be, still no normal maps (bet you didn't guess that). I then removed DTL and all normal maps came back again. But the game crashed after ten minutes.

My conclusion is that it probably is an interaction with something you didn't have when you tried to verify it as a bug. My next burden must be to find out with what. I really should have waited to type anything until then I guess. But I didn't. Great mod still. 

Ah... so it's the normalmaps? what format are they in (PNG?TGA?DDS?)

[Alewx]

Hi,
I guess it was already asked a few times but is this mod x86 exclusive?
You should set up a little FAQ

[Motokid600]

35 minutes ago, Alewx said:

Hi,
I guess it was already asked a few times but is this mod x86 exclusive?
You should set up a little FAQ

Works fine for me in x64 except for a few things that I was able to recreate in x86.

DTL seems to be blurring the ASET props badly. I thought it was JSI at first, but that seems fine. But the Chaka Orion pod ( which uses ASET ) iva is a blurry mess.

This in the 32bit app. And is as stock as stock gets with only the mods in question installed. Texture res is at full.

Also was the MK Pod's texture always this rough or is something going on there as well?

LOG

Output_log

Edited January 21, 2016 by Motokid600

[smjjames]

I've noticed that when I place either of the two small landing legs from NovaPunch, it causes a significant FPS drop in the VAB from the 50-60 starting FPS down to around 30. I've checked without DTL and it doesn't happen without DTL.

The two parts that I'm talking about (they're in the command and control tab, for whatever reason) are the LM-10-2 support structure (aka landing leg) and LM-10-3 support structure.

edit: What in the wierd? It's not reproducing now after I loaded the game back up from checking it without DTL. When I was having the FPS drop, the KSP memory leaks had filled the memory to about 3.2gb. Editwhiletyping: Okay, after doing some stuff, it has now reproduced.

Edited January 21, 2016 by smjjames

[Svm420]

+1 to ASET props being blurry.

[rbray89]

7 hours ago, smjjames said:

I've noticed that when I place either of the two small landing legs from NovaPunch, it causes a significant FPS drop in the VAB from the 50-60 starting FPS down to around 30. I've checked without DTL and it doesn't happen without DTL.

The two parts that I'm talking about (they're in the command and control tab, for whatever reason) are the LM-10-2 support structure (aka landing leg) and LM-10-3 support structure.

edit: What in the wierd? It's not reproducing now after I loaded the game back up from checking it without DTL. When I was having the FPS drop, the KSP memory leaks had filled the memory to about 3.2gb. Editwhiletyping: Okay, after doing some stuff, it has now reproduced.

I can't reproduce this. I believe it is due to the garbage collector doing its thing. Sounds like you are hitting the memory limit due to stock mem leak.

[rbray89]

9 hours ago, Motokid600 said:

Works fine for me in x64 except for a few things that I was able to recreate in x86.

DTL seems to be blurring the ASET props badly. I thought it was JSI at first, but that seems fine. But the Chaka Orion pod ( which uses ASET ) iva is a blurry mess.

This in the 32bit app. And is as stock as stock gets with only the mods in question installed. Texture res is at full.

Also was the MK Pod's texture always this rough or is something going on there as well?

LOG

Output_log

I can't replicate the alcor issues. All the textures show up in perfect detail. Make sure your texture settings in KSP are set to max, and try deleting the cache folders in C:\Users\rbray\Documents\ksp\ksp-x86-1-0-5\GameData\DynamicTextureLoader\Plugins if you were running an older version at some point.

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

[MKellerBR]

@rbray89

I found a situation, at least interesting.
     The same game, Same Mods, same paste, whether SaveGame, ie ALL equal ...
   Used in two different computers, copied from one to the other:
      Computer 1: AMD Phenon2 945, 12Gb, GTX660, Windows 10 64b
      Computer 2: Intel Xeon E5-1620, 16Gb, Quadro600, Windows 8.1

    In the computer 1, memory usage in the KSP Menu is between 2.5G and 2.8G, at Gameplay up to 3.2G after 23min, memory crash occurs, by gradual up mem usage.
    On Computer 2, memory usage in the KSP Menu is between 1.3G and 1.5G, at GamePlay oscillates between 2.3G and 2.8G, according to the complexity of the craft in use.

I am using about 78 mods, and only 50 have parts of ships.

Anyone else noticed this problem?
You know what might be causing this?

PS: Computer 1 is my home computer, used only for games.

[Delta_8930]

After I installed this my modded parts loaded fine without no problems, but the stock parts are just gray models in the game and they are missing their textures. 

[sarbian]

1 hour ago, MKellerBR said:

@rbray89

I found a situation, at least interesting.
     The same game, Same Mods, same paste, whether SaveGame, ie ALL equal ...
   Used in two different computers, copied from one to the other:
      Computer 1: AMD Phenon2 945, 12Gb, GTX660, Windows 10 64b
      Computer 2: Intel Xeon E5-1620, 16Gb, Quadro600, Windows 8.1

    In the computer 1, memory usage in the KSP Menu is between 2.5G and 2.8G, at Gameplay up to 3.2G after 23min, memory crash occurs, by gradual up mem usage.
    On Computer 2, memory usage in the KSP Menu is between 1.3G and 1.5G, at GamePlay oscillates between 2.3G and 2.8G, according to the complexity of the craft in use.

I am using about 78 mods, and only 50 have parts of ships.

Anyone else noticed this problem?
You know what might be causing this?

PS: Computer 1 is my home computer, used only for games.

You should give info about each computers graphics card model and memory.

[smjjames]

7 hours ago, rbray89 said:

I can't reproduce this. I believe it is due to the garbage collector doing its thing. Sounds like you are hitting the memory limit due to stock mem leak.

Uh, I reproduced it the second time after a restart and the memory was down around 2.500gb.

[linuxgurugamer]

1 hour ago, MKellerBR said:

@rbray89

I found a situation, at least interesting.
     The same game, Same Mods, same paste, whether SaveGame, ie ALL equal ...
   Used in two different computers, copied from one to the other:
      Computer 1: AMD Phenon2 945, 12Gb, GTX660, Windows 10 64b
      Computer 2: Intel Xeon E5-1620, 16Gb, Quadro600, Windows 8.1

    In the computer 1, memory usage in the KSP Menu is between 2.5G and 2.8G, at Gameplay up to 3.2G after 23min, memory crash occurs, by gradual up mem usage.
    On Computer 2, memory usage in the KSP Menu is between 1.3G and 1.5G, at GamePlay oscillates between 2.3G and 2.8G, according to the complexity of the craft in use.

I am using about 78 mods, and only 50 have parts of ships.

Anyone else noticed this problem?
You know what might be causing this?

PS: Computer 1 is my home computer, used only for games.

One thing you should consider is anything else running on the Xeon system, possibly loading stuff into the graphics card.  Also, memory on each video card would be useful.

[MKellerBR]

46 minutes ago, sarbian said:

You should give info about each computers graphics card model and memory.

Computer 1:   AMD Phenon2 x4 945, 3.2ghz, 12Gb DDR3 1600   /     Nvidia GTX660 2gb GDDR5   /   Windows 10 Pro 64b   /   Using SSD for Windows and KSP

Computer 2:   Intel Xeon E5-1620 3.6Ghz, 16Gb DDR3 ecc 1600   /   Nvidia Quadro600 1Gb DDR3   /   Windows 8.1 Ent 64b   /    500Gb / 7500rpm HDD

@linuxgurugamer   if it were question of video memory, it would be the opposite!

 

Edited January 22, 2016 by MKellerBR

[Proot]

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!

 

[plausse]

@rbray89 the dysfunctional normals in Hraban's texture pack for Procedural Parts were .png, whilst the ones in the original pack are .dds. Which all seems to be in line with what you and Proot said, I think? 

Edit: To verify this I converted all the images to .dds, but... then they didn't show up at all. I probably did it wrong though. I must try again.  

Edited January 22, 2016 by plausse

[helaeon]

I got it sorted by installing a different texture pack for the suits. The only difference I can tell is that the new pack are all .png rather than .dds.
Not sure if that's really what was going on or not. Either way works now. Thanks for checking into it.

eta: spoke too soon... tried a different pack and EVA helmets aren't loading again. Deleted the cache just to make sure. I'll keep looking into it and report back if I figure out what is going on. It appears the normal maps may not be loading either but I cannot tell for sure.

It appears to be the way the image is saved. I popped them into photoshop and put the desired texture in over the working one then saved again, and it works. It appears the ones do not work are not on the background layer they are floating so there's an alpha layer in the file.

Edited January 23, 2016 by helaeon
further info.

[Denko666]

On 1/21/2016 at 10:54 PM, Alewx said:

Hi,
I guess it was already asked a few times but is this mod x86 exclusive?
You should set up a little FAQ

I can confirm it runs on X86_64 Linux with KSP in 64bit mode. 146 mods loaded,... game is still zippedy

[damerell]

3 hours ago, Denko666 said:

I can confirm it runs on X86_64 Linux with KSP in 64bit mode. 146 mods loaded,... game is still zippedy

It serves little purpose on 64-bit, since the address space is more than large enough for any mod set. It's basically writing your own swap algorithm which is rarely a good idea.