RenderTexture & Multiple Starling Instances

[vaudevillian]

Hi there,

I got this really strange behavior with RenderTexture in combination with multiple stage3d instances (starling > away3d > starling). Whenever I use a custom RenderTexture, the Image doesnt show the RenderTexture, but instead some kind of a "screenshot" of the whole first starling instance. This isnt always the case. Some Images indeed manage to draw the correct RenderTexture. For convenience issues, I just draw a simple white Quad into the RenderTexture.

Using a common Texture.as instead works totally fine. It's only in combination with RenderTexture.

Either the wrong images are drawn into the RenderTexture, or the DisplayList uses the wrong Texture. As far as I understood the code correclty, neither case appears. I followed the trail throughout the code, but I dont have any clue at all. Also, I cant imagine how this "screenshot" even works. Can anyone help me debugging it?

Cheers,

Dominik

[PrimaryFeather]

Hm ... as a first step, have you tested it with the very latest head revision? I made some changes recently that effect what happens when you're using multiple Starling instances.

[vaudevillian]

Unfortunately, that made no difference.

Here is a screenshot: http://postimg.org/image/k6lmkhryj/ As you can see, sometimes the simple white Quad is working, sometimes it draws the aforementioned "screenshot of the first starling instance".

[PrimaryFeather]

I see, thanks for the update! Do you think you could you try to reproduce the issue in a sample project? This would be a huge help for me in finding and fixing the problem.

[vaudevillian]

Hey,

no problem. I tried and succeeded in reproducing the issue in a simple project. As a base I used Away3D's "Interoperation Starling & Away3D", adding the RenderTexture to the second starling instance. When you start the project you should the problem right away.

Here is the link: https://github.com/vaudevillian/RenderTextureBug/

I hope I didnt miss anything.

[PrimaryFeather]

Thanks a lot for taking the time to create the sample! I'll look into it as soon as time permits, and will get back to you when I've got more information.

[PrimaryFeather]

Okay, I found the problem - but I'm still looking for an elegant way to solve it on my side. :wink:

However, I've got a question: in the sample you sent me, you're using the RenderTexture from within the constructor of your "root" class; is that also the case in your actual project? (I guess not.)

In any case, as a quick fix, you can add the following code right after your call to renderTexture.draw(...):

Starling.context.setRenderToBackBuffer();

Does that fix the problem?

[vaudevillian]

Unfortunately, not entirely. In some cases it works just fine: the correct images are being rendered.

Other cases though arent drawn at all now. Before, there was this "screenshot", now its just empty. Sometimes it 'works' when I replace the texture-to-draw with a simple white Quad, then I can see the Quad. But there are also cases where even a simple white Quad isnt being drawn.

Does this help you in any way? I tried to find out more useable stuff, but unfortunately, I failed.

[PrimaryFeather]

One issue you might encounter: when drawing to the RenderTexture from a callback outside the Starling event + render loop, there might be problems.

That's because Starling tries to remember the current render target (and all other important stage3D settings) so that it doesn't have to set them multiple times. Now, when it's called outside its controlled environment, maybe with Away3D just having done some rendering, that information might be false. That's also why manually calling setRenderToBackBuffer helped in the demo you created.

Thus, avoid calls to setTimeout, setInterval or listening to native MouseEvents; instead, use Starling.current.delayCall / repeatCall and Starling's events. Check your callstack whenever you do a renderTexture.draw and check where it originates.

Furthermore, add the setRenderToBackBuffer() call before switching to Away3D. Away3D expects the render target to be the back buffer. (Otherwise, we wouldn't have had that problem.)

[vaudevillian]

Thanks for the fast response! I will need some time to check this out thoroughly. As soon as I get a result, I will reply.

[vaudevillian]

Just wanted to add: I switched the project and wont work on this issue anymore, hence I won't get to verify Daniels last post. Yet the stated problem sounded very familiar, I think getting to draw the rendertextures in the "right moment" was the main problem.

[PrimaryFeather]

Thanks a lot for the update, @vaudevillian, I appreciate it!

It's very likely that the issue originated in the reasons described above. So I'll close this issue for now — if anybody else runs into a related issue, feel free to open it up again.