Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WebGL texture hijacking issue with OpenFL #78

Open
Matan opened this issue Dec 14, 2015 · 3 comments
Open

WebGL texture hijacking issue with OpenFL #78

Matan opened this issue Dec 14, 2015 · 3 comments

Comments

@Matan
Copy link

Matan commented Dec 14, 2015

Hi,

I've come across an issue where a Babylon texture will simply hijack the last loaded/rendered OpenFL texture.

I've modified the openfl sample project to illustrate the issue:
Matan@44035b7

Compile with:
openfl build project_openfl.xml html5 -debug

Edit the project_openfl.xml between 'dom' and 'webgl' to see the difference:
https://github.com/Matan/BabylonHx/blob/master/project_openfl.xml#L13-L14

When compiled with 'dom', everything works as expected. However, when compiled with 'webgl' the ground texture goes black end renders the FPS counter on it.

In my actual project I'm prototyping, it seems to just render the last known image buffer. I can't jump into the GL internals now, was hoping someone would have a quick fix.

Thanks,
Matan

@vujadin
Copy link
Owner

vujadin commented Dec 14, 2015

As far as I know, if you compile with 'dom' flag it will create another canvas on top of the first one which it will use for 2D rendering (possibly will use context2d for this, not sure though...), while with 'webgl' it will create single canvas and render both 3D and 2D through webgl. The problem is that BHx leaves GL context in a state that OpenFL doesn't like and its not only about the texture(s), depending on the effects used in 3D scene you'll get all kinds of strange stuff in your final render.
So the solution to this problem I guess is to return GL context to the state OpenFL expects it to be.
This bug was reported so many times but I really have no time to mess with this. Any help would be great :)

@Matan
Copy link
Author

Matan commented Dec 15, 2015

Hi, thanks for the explanation. And thanks for building this great library. :) Unfortunately I'm also a bit too busy to jump in and see what I can do.

What I'd like to try is to have 2 canvas objects, one for OpenFL and one for Babylon. Then approach Babylon as a 'purejs' compile. Obviously this has some downsides, but no more so than the "Flash with Stage3D" approach. Thus, 2D layer at the top and 3D layer at the bottom. Could work. :)

Thanks again!

@jobs-git
Copy link

Hi! I would like help, how could we return a GL context that OpenFL expects it to be?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants