Page MenuHome

Video Texture (bge.texture) ImageRender / ImageMirror broken
Closed, ResolvedPublic


On all Blender versions (I think) higher than 2.61.4 r43747, the ImageRender and ImageMirror from the video texture module did not work any more.

Last test on Blender 2.61.4 r44098, ImageRender and ImageMirror still not working.

Windows XP 32 Bit.

Event Timeline

strange, I recall Benoit fixing ImageRender.
ImageMirror I'm using in a project and seems to be working fine.

confirmed that this file render black - OSX svn > 2.62rc

I have uploaded a the mirror example which I used for testing.

interesting, the bug is actually that video texture seems to be buggy at frame 1.
change your sensors to a delay sensor with delay one and they both work

Confirmed .
With the delay sensor it is working.

This bug is caused by the canvas display area being initialized on render frame 1, which happens after logic frame 1.
Fixed by initializing the area at canvas creation.

Fixed in revision 44225

Thank you for fixing this bug.
But I think you have forgotten to fix the blenderplayer.

In fact I fixed the blenderplayer, but as I'm testing it, I realize that the logic doesn't work at all: I seems that the logic bricks are not loaded with the file. I will check that asap

I'm going to reopen this until the player is fixed.

As it seems the player now works correctly: the blend file works well in the player. Can you verify that before I close the ticket?

I am sorry. The both files that I uploaded before was only to show the first bug that you have fixed. With this files you can't see the Blenderplayer bug.
I uploaded a new file .

Working with Blender

Working with Blenderplayer if a always sensor has pulse mode is on.
Not working with Blenderplayer if a always sensor has pulse mode is off.
Working with Blenderplayer if a delaysensor has a delay of 1 and pulse mode is off.

Not working Blenderplayer if the player is started with the start button in the standalone player panel.
It seams to be a path problem. I made all paths relative, but If I start the player with these button the paths will change back to absolute on Blender 2.64a.
Blender 2.94.9 r52796 don't change the texture phat but in the console I get the same error.
Path cant be made relative "D:\.....\Blender Files\RealtimeTextureSwitching\Happy.png"

The problem in the player is different than the original ImageRender problem: in the player, the image textures are only initialized in the GPU on the first render frame, which happens after the first logic frame, so that the texture created by VideoTexture in the first frame are deleted and overwritten by the GPU.

To work around this problem, VideoTexture can force a GPU load before swapping the texture id. This works for simple image texture, not necessarily with more complex images (sequence, movies,..) because they can have multiple buffers and VideoTexture has no way to tell which buffer the GPU will need. I don't think this is an issue though: these complex images will in any case interfere badly with VideoTexture, they should not be used as base for swapping a new Texture.

Note that the problem does not exist when using materials (texture.materialID(obj, 'MA...')) because the game engine initializes the materials during conversion.

I did not commit the patch yet because Blender is RC phase. The patch is available here:

With your patch the player is now working with my test file.

But there are two new memory leaks now .
ImBuf_struct len: 2304 02AD3418
imb_addrectImBuf len: 16384 06810020

The memory leak is actually not the fault of VideoTexture: if you manually close (delete) the texture before quitting the game you will see that there is no leak.

The fact is that the player does not automatically clean the logic object when leaving the game. This is a different problem that should be reported separately.

Yes I know, but the funny thing is that without the patch the memory will automatically cleaned.

I have made a bug report [#32708] two month ago and I think that is the same issue.

Benoit, can your patch be committed?

Yes the patch can be committed. It's a reasonable solution to the problem.
The memory leak should be addressed separately.

Has this been committed to Trunk yet?

Benoit Bolsee (ben2610) closed this task as Resolved.May 29 2014, 9:59 AM

Closed by commit rB05db026d8ab3.

I committed Benoit's patch, the second commit that is then removed is just the merge with my branch (I was still testing git).