[SOLVED] Per-instance texture update bug

[ulf.schroeter]

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

[steve3d]

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.

[ulf.schroeter]

don't think so, in case of material inheritance overriding textures should create per-instance material textures.

[steve3d]

But that would take huge amount of video memory if there are lots of inherited materials

[ulf.schroeter]

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

[ivan.cuevas]

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.

[ulf.schroeter]

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)

[manguste]

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.

[ulf.schroeter]

any update on this issue? promised us promised....

[frustum]

I'm still thinking how to implement this elegantly.

[ulf.schroeter]

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 ?

[frustum]

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.

[ulf.schroeter]

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 ?

[frustum]

Per-instance material textures have the same texture name and from the engine point of view they are one the same texture.

[frustum]

Fixed.

[frustum]

[ulf.schroeter]

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.

[manguste]

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.
  

[ulf.schroeter]

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

[ian.yin]

Hello everyone.

Will textures used in post process also have this feature?

[frustum]

Yep. You can do it in the same way.