Problems loading textures and .dds file formats

Discussion area about developing with Ogre-Next (2.1, 2.2 and beyond)


xrgo
OGRE Expert User
OGRE Expert User
Posts: 1148
Joined: Sat Jul 06, 2013 10:59 pm
Location: Chile
x 169

Re: Problems loading textures and .dds file formats

Post by xrgo »

We use mostly Nvidia cards and no crash, my notebook have a 540m, and the pcs at the office have 970, we use opengl on xubuntu
User avatar
GlowingPotato
Goblin
Posts: 211
Joined: Wed May 08, 2013 2:58 pm
x 10

Re: Problems loading textures and .dds file formats

Post by GlowingPotato »

Your asset manager looks amazing!! Wish we have something like this in our engine... people still focusing on developing the engine/game, so no time to make artist happier. But I'am looking forward for spookyboo Editor, its getting good.

Btw, I was saving a dds file and the Nvidia DDS Tool does have the unsigned/signed option, but not for DXT compression.
Image

The intel plugin don't have these options.
al2950
OGRE Expert User
OGRE Expert User
Posts: 1227
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 157

Re: Problems loading textures and .dds file formats

Post by al2950 »

GlowingPotato wrote: The intel plugin don't have these options.
FYI I have added a feature request for the intel tool to add this, I have also tried compiling the intel tool to support signed textures with 100% success :D. Depending on comments on my feature request I may tidy up and create a pull request
User avatar
GlowingPotato
Goblin
Posts: 211
Joined: Wed May 08, 2013 2:58 pm
x 10

Re: Problems loading textures and .dds file formats

Post by GlowingPotato »

al2950 wrote:
GlowingPotato wrote: The intel plugin don't have these options.
FYI I have added a feature request for the intel tool to add this, I have also tried compiling the intel tool to support signed textures with 100% success :D. Depending on comments on my feature request I may tidy up and create a pull request
That's great! nice initiative!
User avatar
SolarPortal
OGRE Contributor
OGRE Contributor
Posts: 203
Joined: Sat Jul 16, 2011 8:29 pm
Location: UK
x 51
Contact:

Re: Problems loading textures and .dds file formats

Post by SolarPortal »

oops. i did not see the second page lol :P so i am moving my edit to a new post:


Debug compared to release had only 1 crash, which i was able to fix and was an aliasname set to BlankString. However, running in release is giving a lot more crashes.
We use mostly Nvidia cards and no crash, my notebook have a 540m, and the pcs at the office have 970, we use opengl on xubuntu
I will give it a go on my laptop as well i think :)

Q) So could it be release builds with Nvidia cards? (was posted before xrgo's comment)

When trying to run release in a sort of debug mode, visual studio says only 1 error on the callstack.

Code: Select all

>	msvcr120.dll!memcpy() Line 128	Unknown
 	000000003db02100()	Unknown
Just to clarify, this debug mode in release usually does give a valid call stack. It appears to throw this error when loading a .tga in release mode when the memory is full.
Debug got through all the mateials error free and most of the other folders.
Your asset manager looks amazing!! Wish we have something like this in our engine... people still focusing on developing the engine/game, so no time to make artist happier. But I'am looking forward for spookyboo Editor, its getting good.
Thanks :), we have been developing for a few years now on the engine and it was really stable until we moved to 2.1.
But hopefully that will be rectified whether it is our source or ogres :)

Edit: More notes: lol :P
The tga's that do throw an exception when being loaded happens by this function:

Code: Select all

   
    Codec::DecodeResult FreeImageCodec::decode(DataStreamPtr& input) const
    {
        // Buffer stream into memory (TODO: override IO functions instead?)
        MemoryDataStream memStream(input, true);

        FIMEMORY* fiMem = 
            FreeImage_OpenMemory(memStream.getPtr(), static_cast<DWORD>(memStream.size()));

        FIBITMAP* fiBitmap = FreeImage_LoadFromMemory(
            (FREE_IMAGE_FORMAT)mFreeImageType, fiMem);
        if (!fiBitmap)
        {
            OGRE_EXCEPT(Exception::ERR_INTERNAL_ERROR, 
                "Error decoding image", 
                "FreeImageCodec::decode");
        }
and then throws that memcpy() Visual Studio call stack.
This must be where its going wrong.

I suspect it refers to the line 571 of Codec::DecodeResult FreeImageCodec::decode(DataStreamPtr& input) const

Edit2: Should it not return after the ogre exception....
Last edited by SolarPortal on Tue Apr 12, 2016 4:45 pm, edited 1 time in total.
Lead developer of the Skyline Game Engine: https://aurasoft-skyline.co.uk
User avatar
TaaTT4
OGRE Contributor
OGRE Contributor
Posts: 267
Joined: Wed Apr 23, 2014 3:49 pm
Location: Bologna, Italy
x 75
Contact:

Re: Problems loading textures and .dds file formats

Post by TaaTT4 »

Hi SolarPortal,

I don't know if it's your case, but are you aware of this behaviour?
The problem (but maybe it's intended) is when the .material script files are parsed, during the resource groups initialization, the associated data blocks and textures are immediately created and loaded into memory.
Considering what you've said, the fact you end the video memory very soon, at the beginning, pops up this issue in my mind.

Nice engine BTW :wink:

Senior programmer at 505 Games; former senior engine programmer at Sandbox Games
Worked on: Racecraft Esport — Racecraft Coin-Op, Victory: The Age of Racing

User avatar
SolarPortal
OGRE Contributor
OGRE Contributor
Posts: 203
Joined: Sat Jul 16, 2011 8:29 pm
Location: UK
x 51
Contact:

Re: Problems loading textures and .dds file formats

Post by SolarPortal »

Thank you. We load data in on the fly rather than using the resource group.
If we load a mesh, then we load the materials/datablocks which would load textures etc....

Memory is not cleared off though as you say and builds up, but it should not crash. As other users have mentioned it just gets slow and should be placed onto system memory :)
Lead developer of the Skyline Game Engine: https://aurasoft-skyline.co.uk
User avatar
GlowingPotato
Goblin
Posts: 211
Joined: Wed May 08, 2013 2:58 pm
x 10

Re: Problems loading textures and .dds file formats

Post by GlowingPotato »

This appears with any TGA ?

We had problems with TGA that were in INDEX mode instead of RGB (substance painter export greyscale TGA's in INDEX mode by default).
Also, the tool for converting DDS that matias posted, won't work with TGA in INDEX mode. What about LRE compression ? I know the decompression is done by CPU, but did you turned it off?

Those probably isn't the cause of your problem, but you can give it a try.
User avatar
SolarPortal
OGRE Contributor
OGRE Contributor
Posts: 203
Joined: Sat Jul 16, 2011 8:29 pm
Location: UK
x 51
Contact:

Re: Problems loading textures and .dds file formats

Post by SolarPortal »

It happens at different times with different .tga's from the same folder, so they could have the issues with eash one and depending on memory it could take another one to break.
I know the decompression is done by CPU, but did you turned it off?
I don't think so. I don't even know where to find it to turn it off lol :P
Lead developer of the Skyline Game Engine: https://aurasoft-skyline.co.uk
User avatar
GlowingPotato
Goblin
Posts: 211
Joined: Wed May 08, 2013 2:58 pm
x 10

Re: Problems loading textures and .dds file formats

Post by GlowingPotato »

SolarPortal wrote:It happens at different times with different .tga's from the same folder, so they could have the issues with eash one and depending on memory it could take another one to break.
I know the decompression is done by CPU, but did you turned it off?
I don't think so. I don't even know where to find it to turn it off lol :P
In photoshop, when you gonna save, a wild check box appear, asking if you want to save using LRE.... its off by default.
User avatar
SolarPortal
OGRE Contributor
OGRE Contributor
Posts: 203
Joined: Sat Jul 16, 2011 8:29 pm
Location: UK
x 51
Contact:

Re: Problems loading textures and .dds file formats

Post by SolarPortal »

I have RLE and its off. :) Also, these images were not made by us, they are from different sources.

Edit: Some new news :)
The difference compared to debug is the fact that release mode runs in a Multithreaded sceneManager. When i set it to Single threaded, it stopped crashing and the exceptions just stopped the image loading into the system. Finally some headway.

Edit2: On more testing, crashes still occur. :(
Lead developer of the Skyline Game Engine: https://aurasoft-skyline.co.uk
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5588
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1413
Contact:

Re: Problems loading textures and .dds file formats

Post by dark_sylinc »

al2950 wrote:Interesting to note, I had a look at GTA V and UE4 and neither use SNORM. GTA V use BC1 (which i was very surprised at!), unreal uses BC5_UNORM and converts in the shader.
Iam intrigued as to why this would be, perhaps to be compatible with as much hardware as possible.....?
UE4's is just a mistake or someone lazy enough to not want to deal with converting to BC5_SNORM (instead I just placed that responsible on the user, asshole me) since most plugins tend to forget about BC5_UNORM. All cards that support BC5_UNORM also support BC5_SNORM.
There was a GDC presentation this year where it was yelled STOP USING UNORM FOR NORMALS!!! Eh... you get the picture :lol:

GTA V is different. BC1 consumes half the memory of BC5 (but quality is considerably worse). Considering GTA V is a huge title running on multiple platforms (some of them memory constrained), it's no surprise (well, a little, but not a huge one).

There are other schemes. For example a while ago I learned some guys used BC3: Using specular workflow, pack diffuse & specular into the RGB channels, and X normal in Alpha channel of diffuse, and Y normal in Alpha channel of specular. The amount of memory consumed is the same as two BC1 + one BC5, however the shader can retrieve the three things (diffuse + specular + normals) in two tex fetches instead of three.
However this comes at the expense of having to deal with packing 3 textures into 2 and compressing them.
SolarPortal wrote:If i load the assets in without the scene then the asset shows, but lets face it, no game is just 1 asset in a scene lol :P
I am sorry that i can't provide more information, based on i don't know what to provide as it just crashes at random points, not sure how a full level is going to load and work atm....
Do you want anything specific to work with?
You're going crazy about something very simple: You're running out of GPU ram. As simple as that. The crashes happen at random because memory is fragmented, thus it may be able to service an allocation that failed on the previous run, but fails on the next one. Or the one after that one. But it's always "more or less around those assets".

What would be of great help in understanding as a dump of your texture memory usage.
Go to the end of HlmsTextureManager::createOrRetrieveTexture and add a call to dumpMemoryUsage:

Code: Select all

catch( Exception &e )
	{
		LogManager::getSingleton().logMessage( LML_CRITICAL, e.getFullDescription() );

		if( e.getNumber() != Exception::ERR_FILE_NOT_FOUND )
			throw e;
		else
		{
			retVal.texture  = mBlankTexture;
			retVal.xIdx     = 0;
			retVal.yIdx     = 0;
			retVal.divisor  = 1;
		}
	}
	
	dumpMemoryUsage(); //<-----HERE

	return retVal;
}
This will pollute the log with incremental updates (i.e. loaded A.png, it will dump A. Loaded B.png, it will dump AB. Loaded C.png, it will dump ABC, and so on). It may get so polluted so much there could be a performance detriment (e.g. a 7MB log file). We actually only need the last dump before it crashed. Since it's crashing at multiple places on each run, one or three of these dump could help (i.e. it would be very suspicious if around a crash a 4096x4096 RGBA_F16 texture gets loaded...)

The dump could reveal a lot of information. If you've got weird resolutions, a lot of waste, too many pixel formats, etc.
For example we had an application that created a PF_BYTE_LA texture, but because this doesn't exist in D3D11, it was being emulated via an RGBA8888 texture, which is twice the memory size. Things like that is something you'll likely see more than we can, since it's you're the one familiar with the code ("mmm... that doesn't look right").

We do provide a rough mean of "destroying" textures though, once you don't need it:
HlmsTextureManager::destroyTexture will release the texture slot. Once all the slots are freed the texture itself is destroyed. Note if datablocks are holding a reference to the texture (or any part of your code), it won't be destroyed until all the references are setNull() (since TexturePtr is reference counted).

Bare in mind Ogre 1.x & 2.0 only loaded textures until they were used for the first time (or you've explicitly called load), whereas 2.1 preloads the texture as soon as the material is parsed. This is a major difference not to be underestimated.

Last but not least, the problem could be that you just have too many assets. Supposedly the driver should page out the resources not in use (note: if you've a TextureArray with 30 entries, and only 1 entry is being used, then the whole TextureArray can't be paged out). That's where NVIDIA's driver comes in.
NVIDIA in particular has been a PITA when managing memory. I had to insert several workarounds because it was running out of memory; and these problems were model specific. Their driver is so complex it follows separate code paths depending on the model.

What might work is loading part of your assets, then render a few frames, then loading more assets, render more... since it could trick the driver into start paging out some resources that it sees aren't being used (while if you load everything in one go the driver may eventually see there's too much to wait until the next draw call, and flush its command buffer, causing it to upload absolutely everything to GPU RAM). Considering Debug & Release mode are giving you very different set of crashes, it suggests heuristics based on timing (i.e. MB/s being uploaded, frequency in which driver thread polls for more data) are being triggered. So loading, rendering some, loading more could actually work.
This is a cat-mouse chase where you try to figure what the driver is doing so you can workaround it, and the driver is trying to figure what you're doing so it can do "the most efficient thing" (and in this case, screwing up spectacularly).

Welcome to Game Development! This is what the Big Leagues, aka AAA devs, complain about. The reason DX12 & Vulkan appeared. Driver guys were like: "Oh! so you think we screwed up? There! manage entire memory residency yourself!!!"

But the first step is to take a look at the dump. You need to know your data and what's your engine actually doing before start blaming others. While driver could be an issue, all cards have their limit.

Yes, Textures are in an increasing need to refactor, but it's not going to be happening very soon (for instance, being able to page out the memory by ourselves to system RAM is a great idea).
SolarPortal wrote:Also just for a point of reference, my card can run Witcher3 at 20-25fps but never encounters an out of memory and shows the game in Med - High definition and the gpu is always maxed out and full vid mem usage.
You're comparing an optimized game, with IHV-backed support against an editor that is likely trying to load every texture in the asset folder.
I'm plenty sure they've had encountered out of memory exceptions during development, and their advantage is that when they suspect a driver screw up; they can dial the vendor and have them fix it for them because it's a high-profile game.

So far AMD and Intel have replied to my emails, AMD has even fixed bug reports reported from me. Intel's driver is pretty much "dumb": it does exactly as told (this is a good thing). NVIDIA has never replied my emails (except the time I was working for a client who couldn't be ignored), the driver does what it wants; and in fact AMD engineers have helped me understanding how to workaround some problems with NV. This is aimed at NV: when your main competitor is the one helping to fix your problems, you know you've fucked up. It's awkward. I am absolutely not surprised at all your driver crashes frequently following the release of a major title, despite how broken the game is claimed to be.
8 years ago NV was very open about their HW & SW.
I think I made a little catharsis just now.

For the time being, first provide the dump. That will shed some light.
User avatar
SolarPortal
OGRE Contributor
OGRE Contributor
Posts: 203
Joined: Sat Jul 16, 2011 8:29 pm
Location: UK
x 51
Contact:

Re: Problems loading textures and .dds file formats

Post by SolarPortal »

Thank you for the detailed response. It is all very clear now :D

We were not blaming ogre for being wrong and did realise that a card has limits and that they were being reached. However, i think it is safe to say we had an expectation on the way DX9 worked in which these things and crashes didn't happen. So to our knowledge why would it have been different now, but you have enlightened us with the newer ways the newer renderers and dreadful drivers are handling bits now.... lol :P

I can show you one dump that i did get from your code, but i can already guess what you will say. The only thing different is that i set the maxTexPerArray values to (see below ) as having many different formats creating empty arrays would be a catastrophe on memory and stopped as many crashes LOL :P ... especially with a limited resource....

Code: Select all

	deftexParams[Ogre::HlmsTextureManager::TEXTURE_TYPE_DIFFUSE].maxTexturesPerArray = 1;
	deftexParams[Ogre::HlmsTextureManager::TEXTURE_TYPE_NORMALS].maxTexturesPerArray = 1;
	deftexParams[Ogre::HlmsTextureManager::TEXTURE_TYPE_MONOCHROME].maxTexturesPerArray = 1;
So here is the Dump:

Code: Select all

20:39:11: Texture: loading Nobiax_Texture_Pack_specular_112.tga as Nobiax_Texture_Pack_specular_112.tga
20:39:11: ================================Start dump of HlmsTextureManager================================
20:39:11: |#|Type|Width|Height|Depth|Format|HW Gamma|Mipmaps|Size in bytes|Num. active textures|Total texture capacity|Texture Names
20:39:11: |0|DIFFUSE|1024|1024|1|PF_DXT3|Yes|0|1048576|1|1|mp_fire_02_2x2.dds
20:39:11: |1|DIFFUSE|400|400|1|PF_DXT5|Yes|0|160000|1|1|flare_alpha.dds
20:39:11: |2|DIFFUSE|128|128|1|PF_A8R8G8B8|Yes|7|87380|1|1|checkered_texture_Yellow.png
20:39:11: |3|DIFFUSE|512|512|1|PF_DXT1|Yes|9|174776|1|1|proto_blue.dds
20:39:11: |4|DIFFUSE|512|512|1|PF_A8R8G8B8|Yes|9|1398100|1|1|proto_blue.tga
20:39:11: |5|DIFFUSE|512|512|1|PF_A8R8G8B8|Yes|9|1398100|1|1|proto_gray_h.tga
20:39:11: |6|DIFFUSE|256|256|1|PF_A8R8G8B8|Yes|8|349524|1|1|Blank.png
20:39:11: |7|DIFFUSE|512|512|1|PF_A8R8G8B8|Yes|9|1398100|1|1|Rotation_Grid_00.png
20:39:11: |8|DIFFUSE|10|10|1|PF_A8R8G8B8|Yes|3|520|1|1|Light.png
20:39:11: |9|DIFFUSE|512|512|1|PF_DXT5|Yes|3|348160|1|1|MeshEditor_BlackGriddedFloor.dds
20:39:11: |10|DIFFUSE|512|512|1|PF_DXT5|Yes|9|349552|1|1|Editor_Default_SkyGrass.dds
20:39:11: |11|DIFFUSE|1024|1024|1|PF_DXT5|Yes|3|1392640|1|1|Editor_DefaultTree.dds
20:39:11: |12|DIFFUSE|512|512|1|PF_DXT1|Yes|0|131072|1|1|MaterialError.dds
20:39:11: |13|DIFFUSE|1024|1024|1|PF_DXT1|Yes|10|699064|1|1|Grass01_C.dds
20:39:11: |14|DIFFUSE|1237|1241|1|PF_A8R8G8B8|Yes|10|8183092|1|1|Target_target1.png
20:39:11: |15|DIFFUSE|256|256|1|PF_A8R8G8B8|Yes|8|349524|1|1|Target_wood01.png
20:39:11: |16|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|dffuse.tga
20:39:11: |17|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_00.tga
20:39:11: |18|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_01.tga
20:39:11: |19|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_02.tga
20:39:11: |20|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_03.tga
20:39:11: |21|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_04.tga
20:39:11: |22|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_05.tga
20:39:11: |23|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_06.tga
20:39:11: |24|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_07.tga
20:39:11: |25|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_08.tga
20:39:11: |26|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_09.tga
20:39:11: |27|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_10.tga
20:39:11: |28|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_11.tga
20:39:11: |29|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_12.tga
20:39:11: |30|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_13.tga
20:39:11: |31|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_14.tga
20:39:11: |32|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_15.tga
20:39:11: |33|DIFFUSE|2048|2048|1|PF_A8R8G8B8|Yes|11|22369620|1|1|Nobiax_Texture_Pack_diffus_16.tga
20:39:11: |34|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_17.tga
20:39:11: |35|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_18.tga
20:39:11: |36|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_19.tga
20:39:11: |37|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_20.tga
20:39:11: |38|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_21.tga
20:39:11: |39|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_22.tga
20:39:11: |40|DIFFUSE|2048|2048|1|PF_A8R8G8B8|Yes|11|22369620|1|1|Nobiax_Texture_Pack_diffus_23.tga
20:39:11: |41|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_24.tga
20:39:11: |42|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_25.tga
20:39:11: |43|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_26.tga
20:39:11: |44|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_27.tga
20:39:11: |45|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_28.tga
20:39:11: |46|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_29.tga
20:39:11: |47|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_30.tga
20:39:11: |48|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_31.tga
20:39:11: |49|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_32.tga
20:39:11: |50|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_33.tga
20:39:11: |51|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_34.tga
20:39:11: |52|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_35.tga
20:39:11: |53|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_36.tga
20:39:11: |54|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_37.tga
20:39:11: |55|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_38.tga
20:39:11: |56|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_39.tga
20:39:11: |57|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_41.tga
20:39:11: |58|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_42.tga
20:39:11: |59|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_43.tga
20:39:11: |60|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_44.tga
20:39:11: |61|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_45.tga
20:39:11: |62|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_46.tga
20:39:11: |63|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_47.tga
20:39:11: |64|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_48.tga
20:39:11: |65|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_49.tga
20:39:11: |66|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_50.tga
20:39:11: |67|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_51.tga
20:39:11: |68|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_52.tga
20:39:11: |69|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_53.tga
20:39:11: |70|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_54.tga
20:39:11: |71|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_55.tga
20:39:11: |72|DIFFUSE|1024|1024|1|PF_A8R8G8B8|Yes|10|5592404|1|1|Nobiax_Texture_Pack_diffus_56.tga
20:39:11: |0|MONOCHROME|600|600|1|PF_L8|No|9|479920|1|1|MRAMOR-bump.jpg
20:39:11: |1|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_00.tga
20:39:11: |2|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_02.tga
20:39:11: |3|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_04.tga
20:39:11: |4|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_06.tga
20:39:11: |5|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_08.tga
20:39:11: |6|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_10.tga
20:39:11: |7|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_12.tga
20:39:11: |8|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_14.tga
20:39:11: |9|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_16.tga
20:39:11: |10|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_18.tga
20:39:11: |11|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_20.tga
20:39:11: |12|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_22.tga
20:39:11: |13|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_24.tga
20:39:11: |14|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_26.tga
20:39:11: |15|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_28.tga
20:39:11: |16|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_30.tga
20:39:11: |17|MONOCHROME|2048|2048|1|PF_L8|No|11|5592405|1|1|Nobiax_Texture_Pack_specular_32.tga
20:39:11: |18|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_34.tga
20:39:11: |19|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_36.tga
20:39:11: |20|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_38.tga
20:39:11: |21|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_40.tga
20:39:11: |22|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_42.tga
20:39:11: |23|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_44.tga
20:39:11: |24|MONOCHROME|2048|2048|1|PF_L8|No|11|5592405|1|1|Nobiax_Texture_Pack_specular_46.tga
20:39:11: |25|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_48.tga
20:39:11: |26|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_50.tga
20:39:11: |27|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_52.tga
20:39:11: |28|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_54.tga
20:39:11: |29|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_56.tga
20:39:11: |30|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_58.tga
20:39:11: |31|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_60.tga
20:39:11: |32|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_62.tga
20:39:11: |33|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_64.tga
20:39:11: |34|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_66.tga
20:39:11: |35|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_68.tga
20:39:11: |36|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_70.tga
20:39:11: |37|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_72.tga
20:39:11: |38|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_74.tga
20:39:11: |39|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_76.tga
20:39:11: |40|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_78.tga
20:39:11: |41|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_82.tga
20:39:11: |42|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_84.tga
20:39:11: |43|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_86.tga
20:39:11: |44|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_88.tga
20:39:11: |45|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_90.tga
20:39:11: |46|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_92.tga
20:39:11: |47|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_94.tga
20:39:11: |48|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_96.tga
20:39:11: |49|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_98.tga
20:39:11: |50|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_100.tga
20:39:11: |51|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_102.tga
20:39:11: |52|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_104.tga
20:39:11: |53|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_106.tga
20:39:11: |54|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_108.tga
20:39:11: |55|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_110.tga
20:39:11: |56|MONOCHROME|1024|1024|1|PF_L8|No|10|1398101|1|1|Nobiax_Texture_Pack_specular_112.tga
20:39:11: |0|NORMALS|512|512|1|PF_R8G8_SNORM|No|9|699050|1|1|proto_gray_n.tga
20:39:11: |1|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|3|2785280|1|1|
20:39:11: |2|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|3|2785280|1|1|
20:39:11: |3|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|3|2785280|1|1|
20:39:11: |4|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|dirt_earth-n-moss_df__NORMAL.png
20:39:11: |5|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_00.tga
20:39:11: |6|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_02.tga
20:39:11: |7|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_04.tga
20:39:11: |8|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_06.tga
20:39:11: |9|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_08.tga
20:39:11: |10|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_10.tga
20:39:11: |11|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_12.tga
20:39:11: |12|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_14.tga
20:39:11: |13|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_16.tga
20:39:11: |14|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_18.tga
20:39:11: |15|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_20.tga
20:39:11: |16|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_22.tga
20:39:11: |17|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_24.tga
20:39:11: |18|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_26.tga
20:39:11: |19|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_28.tga
20:39:11: |20|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_30.tga
20:39:11: |21|NORMALS|2048|2048|1|PF_R8G8_SNORM|No|11|11184810|1|1|Nobiax_Texture_Pack_normal_32.tga
20:39:11: |22|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_34.tga
20:39:11: |23|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_36.tga
20:39:11: |24|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_38.tga
20:39:11: |25|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_40.tga
20:39:11: |26|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_42.tga
20:39:11: |27|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_44.tga
20:39:11: |28|NORMALS|128|128|1|PF_R8G8_SNORM|No|7|43690|1|1|Nobiax_Texture_Pack_normal_46.tga
20:39:11: |29|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_48.tga
20:39:11: |30|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_50.tga
20:39:11: |31|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_52.tga
20:39:11: |32|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_54.tga
20:39:11: |33|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_56.tga
20:39:11: |34|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_58.tga
20:39:11: |35|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_60.tga
20:39:11: |36|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_62.tga
20:39:11: |37|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_64.tga
20:39:11: |38|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_66.tga
20:39:11: |39|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_68.tga
20:39:11: |40|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_70.tga
20:39:11: |41|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_72.tga
20:39:11: |42|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_74.tga
20:39:11: |43|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_76.tga
20:39:11: |44|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_78.tga
20:39:11: |45|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_82.tga
20:39:11: |46|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_84.tga
20:39:11: |47|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_86.tga
20:39:11: |48|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_88.tga
20:39:12: |49|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_90.tga
20:39:12: |50|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_92.tga
20:39:12: |51|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_94.tga
20:39:12: |52|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_96.tga
20:39:12: |53|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_98.tga
20:39:12: |54|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_100.tga
20:39:12: |55|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_102.tga
20:39:12: |56|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_104.tga
20:39:12: |57|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_106.tga
20:39:12: |58|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_108.tga
20:39:12: |59|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_110.tga
20:39:12: |60|NORMALS|1024|1024|1|PF_R8G8_SNORM|No|10|2796202|1|1|Nobiax_Texture_Pack_normal_112.tga
20:39:12: |0|DETAIL|600|600|1|PF_A8R8G8B8|Yes|9|1919680|1|1|MRAMOR6X6.jpg
20:39:12: |Size in MBs per category:
20:39:12: |DIFFUSE|352.659
20:39:12: |MONOCHROME|83.1243
20:39:12: |NORMALS|166.01
20:39:12: |ENV_MAP|0
20:39:12: |DETAIL|1.83075
20:39:12: |DETAIL_NORMAL_MAP|0
20:39:12: |Total MBs used:|603.624
20:39:12: ================================End dump of HlmsTextureManager================================
20:39:12: WARNING: Texture instance 'HlmsTextureManager/189' was defined as manually loaded, but no manual loader was provided. This Resource will be lost if it has to be reloaded.
20:39:12: WARNING: Texture instance 'HlmsTextureManager/190' was defined as manually loaded, but no manual loader was provided. This Resource will be lost if it has to be reloaded.
20:39:12: WARNING: Texture instance 'HlmsTextureManager/191' was defined as manually loaded, but no manual loader was provided. This Resource will be lost if it has to be reloaded.
20:39:12: Unloading unused resources in resource group Scene
20:39:12: Finished unloading unused resources in resource group Scene
20:39:12: Unloading unused resources in resource group EditorThumbnails
20:39:12: Finished unloading unused resources in resource group EditorThumbnails
20:39:12: Added resource location 'E:/00_Skyline_SDK/Asset Library/Textures/Nobiax_Textures/Nobiax_Texture_Pack/Nobiax_Textures_pack_15/pattern_81/' of type 'FileSystem' to resource group 'Scene'
20:39:12: Texture: loading Nobiax_Texture_Pack_diffus_57.tga as Nobiax_Texture_Pack_diffus_57.tga
Pretty cool about AMD intereracting with developers and fixing things and i totally get what you mean with Nvidia. Crazy way of doing things. :shock:

Yes, the game comparison was probably a bit too far since a lot of time, money and resources have been spent on it but it shows nicely what our level of hardware should be able to achieve in the game engine.
What might work is loading part of your assets, then render a few frames, then loading more assets, render more... since it could trick the driver into start paging out some resources that it sees aren't being used (while if you load everything in one go the driver may eventually see there's too much to wait until the next draw call, and flush its command buffer, causing it to upload absolutely everything to GPU RAM). Considering Debug & Release mode are giving you very different set of crashes, it suggests heuristics based on timing (i.e. MB/s being uploaded, frequency in which driver thread polls for more data) are being triggered. So loading, rendering some, loading more could actually work.
I tried rendering around 104 frames each one, but it still only crashed a few down. Any more frames and the image taking process takes too long lol :P
Yes, Textures are in an increasing need to refactor, but it's not going to be happening very soon (for instance, being able to page out the memory by ourselves to system RAM is a great idea).
cool, i look forward to seeing this one day :)

All me and my colleague can say is that we feel for you having to deal with all these complaints when it really is the drivers at fault.

Ok with all this being said and very valid indeed, What are we going to do about this in our engine.

1) We are going to implement a complete unloading for datablock and textures that are no longer being used freeing up the memory for the next one.
2) When we detect a crappy texture format or incorrect sizes for games, we will auto optimize so the end user does not have to feel the pain of moving to a newer renderer :P

Once that is in place, there should not be as many problems but limits will still need to be measured.

Q) In c++, do you know of a good way of retrieving the video memory size so we could display it to be monitored.

A few things on our resource system:
We do not use a general ogre resource pipeline as we learned early on that too many assets loading takes too long to boot ( it used to take 1 min 30 secs to load the engine ) and way to much memory.
Because of this we wrote a system from scratch that loaded assets in when we drag them from the folder or on command rather than using initialiseAllResourceGroups() which only loaded the assets you used in your game.
Of course, this meant we had to write our own resource parsing system to find textures that need loaded for materials which need created for the meshes and entities and supporting many materials and custom materials also.
It is quite a beast but it added the flexibility of having access to literally thousands of folders and all sorts of assets and still only loaded what you add in, hence the asset manager.

There are a few base resources around 30mb of textures that are required for use with the editor and this did use the original resource system.

Thanks again :)

Edit: I have implemented a basic resource unload for all the images taken and datablocks and have successfully made it through the entire folder :) Happy! :)
Lead developer of the Skyline Game Engine: https://aurasoft-skyline.co.uk
al2950
OGRE Expert User
OGRE Expert User
Posts: 1227
Joined: Thu Dec 11, 2008 7:56 pm
Location: Bristol, UK
x 157

Re: Problems loading textures and .dds file formats

Post by al2950 »

FYI

My fix for HLMSTextureManager and DDS textures has been merged;
https://bitbucket.org/sinbad/ogre/commi ... 116424e905

Also I have updated the intel dds plugin so it can export signed and unsigned BC5 normal maps. However it is has not yet been merged;
https://github.com/GameTechDev/Intel-Te ... in/pull/13
User avatar
SolarPortal
OGRE Contributor
OGRE Contributor
Posts: 203
Joined: Sat Jul 16, 2011 8:29 pm
Location: UK
x 51
Contact:

Re: Problems loading textures and .dds file formats

Post by SolarPortal »

Thanks @al2950 :) I have applied the fix and am testing some larger levels. So far so good using DDS DXT1 on the L8 and Normals :)

When using *.tga, the video memory is not even maxed out, its at 700mb out of 1gb and still crashes and i think it crashes when put into the Monochrome L8 format and obviously normals.
I understand why it would crash due to previous discussions and what formats i should be using, but it would be nice if it didn't crash. Kinda strange bug :P
Lead developer of the Skyline Game Engine: https://aurasoft-skyline.co.uk
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5588
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1413
Contact:

Re: Problems loading textures and .dds file formats

Post by dark_sylinc »

SolarPortal wrote:When using *.tga, the video memory is not even maxed out, its at 700mb out of 1gb and still crashes and i think it crashes when put into the Monochrome L8 format and obviously normals.
Small reminder that textures aren't the only thing consuming memory. Ogre reserves 128MB for buffers (hardcoded in GL3PlusVaoManager::GL3PlusVaoManager and D3D11VaoManager::D3D11VaoManager see mDefaultPoolSize) and that also the OS needs its own chunk, RenderWindows need their own chunk, and memory fragmentation can also affect allocation success.
User avatar
SolarPortal
OGRE Contributor
OGRE Contributor
Posts: 203
Joined: Sat Jul 16, 2011 8:29 pm
Location: UK
x 51
Contact:

Re: Problems loading textures and .dds file formats

Post by SolarPortal »

Is that not already taken up in memory if it is reserved? i would think the ram not used(or whats left on the card) has no reservations and is what's usable.
Lead developer of the Skyline Game Engine: https://aurasoft-skyline.co.uk
User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5588
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1413
Contact:

Re: Problems loading textures and .dds file formats

Post by dark_sylinc »

SolarPortal wrote:Is that not already taken up in memory if it is reserved? i would think the ram not used(or whats left on the card) has no reservations and is what's usable.
If the 700MB were counted from only the textures (i.e. via dumpMemoryUsage), then no.
If the 700MB were counted using an external tool like GPU-Z then yes.

But remember that even what GPU-Z shows may not account some OS chunks, and fragmentation begins to show once you're left with less than 20% of total space. Also the OS may decide some space should not be used so it's available for emergencies (starting Windows Vista, GPUs are virtualized).

Same happens with regular CPU memory in 32-bit. The limit is 2GB (3/4GB with some hacks). But for those with the regular 2GB limit, an app may start crashing at random with out of memory exceptions once you pass 1.5GB of memory allocated by the process. Some crash at ~1.3GB, others crash at 1.9GB. A lot of factors weight in.
User avatar
SolarPortal
OGRE Contributor
OGRE Contributor
Posts: 203
Joined: Sat Jul 16, 2011 8:29 pm
Location: UK
x 51
Contact:

Re: Problems loading textures and .dds file formats

Post by SolarPortal »

yes, i was using GPU-Z for measuring.

The only reason i mention, is due to the .dds allowing greater than 950mb of 1024mb, whereas the .tga crashed around 700mb.
Thought it might have helped lol :P

Thanks for taking time to explain :)
Lead developer of the Skyline Game Engine: https://aurasoft-skyline.co.uk
Post Reply