ulf.schroeter Posted May 19, 2012 Share Posted May 19, 2012 Problem Dynamic per-instance texture updates via material.setImageTextureImage() do not work correctly as already stated in this post (at least under D3D9) Updates of per-instance texture images affect base material texture instead of per-instance material version, so all instances will be affected by texture update The attached test case shows the problem. All 3 cubes have inherited material instances assigned and should show simultaneously animated red-white, green-white and blue-white checkerboard texture, but instead all instances just show blue-white (last image color update per frame) texture. Also inital call to material.setImageTextureImage() causes log error output Direct3D9 error: invalid call D3D9Texture::create(): can't update RGBA8 8x8 2D texture Link to comment
steve3d Posted May 21, 2012 Share Posted May 21, 2012 I think it should work this way, a texture only have one instance in video memory, change this texture of course should affect all materials references this texture. Link to comment
ulf.schroeter Posted May 21, 2012 Author Share Posted May 21, 2012 don't think so, in case of material inheritance overriding textures should create per-instance material textures. Link to comment
steve3d Posted May 21, 2012 Share Posted May 21, 2012 But that would take huge amount of video memory if there are lots of inherited materials Link to comment
ulf.schroeter Posted May 21, 2012 Author Share Posted May 21, 2012 material inheritance is the way to reduce redundant texture usage as it allows reuse of shared textures while providing the ability to override individual textures. It's the core concept of Unigine material system. But of course it has to work under all circumstances, also for dynamic texture updates, but at the moment it does not -> bug Link to comment
ivan.cuevas Posted May 21, 2012 Share Posted May 21, 2012 Your are right Ulf, but I agree with steve3d. In my opinion texture inheritance can produce a huge memory foot print in the app. As far as I see textures in Unigine architecture are static resources in the same way as meshes, scripts or material libraries. Link to comment
ulf.schroeter Posted May 21, 2012 Author Share Posted May 21, 2012 Well, it's a bug report on existing Unigine material inheritance functionality and it would be great if the Unigine crew could fix it as we need this capability working as expected in our project. @Ivan: texture updates/render-to-texture is a must-have features for all kinds of procedural effects. BTW every material you inherit from Unigine base material (e.g. mesh_base) already uses texture inheritance for every material you define, so I am a little bit curious about mentioned memory footprint concers. Also Unigine texture/mesh/mask streaming approach handles actual resource memory footprint dynamically based on resource usage (meaning texture/mesh/mask resources will be un-/reloaded from/to memory automatically) Link to comment
manguste Posted May 24, 2012 Share Posted May 24, 2012 Frustum promised to fix it. Though right now he's busy with other planned development issues, so as soon as he has a free minute he'll leap straight to this. Link to comment
ulf.schroeter Posted July 6, 2012 Author Share Posted July 6, 2012 any update on this issue? promised us promised.... Link to comment
frustum Posted July 9, 2012 Share Posted July 9, 2012 I'm still thinking how to implement this elegantly. Link to comment
ulf.schroeter Posted July 9, 2012 Author Share Posted July 9, 2012 hm, seems to be a harder problem than expected. I just thought that each inherited material instance will simply get its own texture instance copy which can than be manipulated independently of the material base texture. Isn't this exactly the way how material inheritance already works when defined in a material library ? What am I missing here ? Link to comment
frustum Posted July 10, 2012 Share Posted July 10, 2012 The current texture streaming system is based on filesystem files. This system can get access to the file source when this information is required (new visible object or video mode change). Textures are located in the video memory only. Moreover engine performs file name to GPU texture mapping internally. On other hand we should keep an Image in the system memory and remove file name to texture mapping for dynamic textures. Dynamic textures requires an additional Texture handling scheme. Link to comment
ulf.schroeter Posted July 10, 2012 Author Share Posted July 10, 2012 ok, I see, restoring of a dynamic texture is indeed a little bit more complicated than expected and will require A. CPU-side image storage or B. some form of application script callback for dynamic on-demand texture image recreation...but what about the first problem, that an updates of per-instance texture images affect base material texture instead of per-instance material version. Isn't this a different issue ? Link to comment
frustum Posted July 10, 2012 Share Posted July 10, 2012 Per-instance material textures have the same texture name and from the engine point of view they are one the same texture. Link to comment
ulf.schroeter Posted August 22, 2012 Author Share Posted August 22, 2012 Great Frustum ! How have you solved the dynamic texture issue ? Will they be kept in system memory now ? BTW maybe the provided test case might also be a good candidate for the samples as it shows the handling of multiple dynamic texture instances. The current one only shows one dynamic texture instance. Link to comment
manguste Posted August 23, 2012 Share Posted August 23, 2012 Ulf, I'll answer instead of Frustum so he can have time to implement something useful :) BTW maybe the provided test case might also be a good candidate for the samples as it shows the handling of multiple dynamic texture instances. Good idea, we'll add it into SDK. How have you solved the dynamic texture issue ? Will they be kept in system memory now ? No, textures are still kept in the video memory and images in the system one. There's a new class TextureImage that stores both Image and Texture instances. A new dynamic flag is passed as an argument for setImageTextureImage(). If it is equal to one 1, a filesystem texture name is cleared and TextureImage instance with overriden texture is created. Link to comment
ulf.schroeter Posted November 6, 2012 Author Share Posted November 6, 2012 Updated the original bug test code so it now demonstrates new UNIGINE material per-instance dynamic texture update feature. Maybe helpful starting point for others, simply extract zip to data folder and launch it via provided .bat file DynamicTextureUpdatec.zip Link to comment
ian.yin Posted October 22, 2013 Share Posted October 22, 2013 Hello everyone. Will textures used in post process also have this feature? Link to comment
frustum Posted November 1, 2013 Share Posted November 1, 2013 Yep. You can do it in the same way. Link to comment
Recommended Posts