Hello there! i am finding a really big issue in my side when you are dealing with many textures in gamma, and load them in stride, as far as i know, somehow all the textures loaded in a filetexture node pass to be a part of the /lib/Db in the installation folder of gamma, that means if you start to load textures not optimized for stride , they are loaded in the db using a lot of space in your hard drive, instead to create a db in every project folder, as usually game engines does, someone noticed this ? after a load of many 4k images you can find your vvvv gamma folder size increase, and whats more, when you close your session, the files keep there making a big bunch of data you would never use for other project. Is there any thought about this issue,?
Also it happens when you export the app, is there any way to say to clear the db when your app closes?
I found is remarkable and crucial when you work in big projects with many textures. furthermore, seems the Db keeps stride compiled textures in that folder , so when you move that document to other computer, stride would need to recompile again all this textures and consume time and data in that. Ideally the thing would be to create a db folder in every document folder, and get rid of the textures the program doesnt use, or to have an option when you export apps to say to clear DB when the app closes
any thoughts?
yes, this is what we are aiming at, every document/app will of course get their own asset storage that you can manage via a proper UX.
but we have only one db folder for now, since we couldn’t spent so much time on implementing it properly and delay the release by some months. this will improve in future.
it is correct that the asset manager puts the textures there, it has the advantage that the next time you load the same 4k texture it loads much, much faster. if you have many huge texture or an image stack, you can use the new image player with the texture reader, which doesn’t use this cache at the moment. but you have to optimize your images for loading on your own, and it doesn’t generate mipmaps yet.
Thanks tonfilm for the answer, in my case im dealing with the megascans importer , i succeed to export the first prerealese of the tool, but i encounter the db problem, when i go across the megascans materials, the Db folder increase so much the size and since is like a browser ideally would be when you close the app to flush this cache to avoid big size app folder. it is possible to patch something that delete this folder each time the app is closed?
for temporaray textures or browsing images you can use TextureReader and the MipMap node triggered once in a cache region, this will not use the asset data base.
this is not possible, because the app doesn’t know which images are needed on the next start and which are temporary. but you can delete the content of the folder by hand, i think.
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.