webgl & stage3d drivers for 3D

[Aris Kostakos]

Greetings to the awesome group!

I'm an as3 developer working my way to new technologies to try and keep up with the times!

I'm currently working on a programming-free engine that allows you to make multiplayer online cross-platform strategy/puzzle games. My engine is currently written in as3 and targets flash and air but I want to port it to Haxe/OpenFL/awe6 since I see no downsides and a billion upsides:)

The reason I'm using awe6 is because my engine is already designed to be data-driven and would benefit greatly from IoC. Also, I require a level of abstraction that awe6 offers generously.

So far porting is going very smooth but when it comes to 3D although I've seen a few examples, there are no code snippets available to get started.

Before I start getting my hands dirty I made a habit of checking out what's out there already, so I'm looking for awe6 drivers that hook up an entity's context to pure Stage3D/openFL's opengl View, or preferably to away3D/three.js. Eventually I'll write my own but I though I'd post here first.

While I was thinking of implementing the drivers myself, the first question that popped in my mind was this. A 3d world is consisted of a scene, a camera, lights, etc. Would all these be considered entities? Should I use an Entity even for the scene, and do the platform specific things in it's context? I know I'll eventually make something that works but I want to use awe6 as it was meant to be used, not shit all over your amazing IoC framework :)


Thank you, and keep up the good work!

Aris Kostakos
www.gamepl.org (under construction, i just bought the domain)

[Aris Kostakos]

Hi again,

I think I need some help. I'm using the haxe-three.js externs to render some simple geometry using the webgl renderer.My target is still OpenFl since I want to take advantage of how seamlessly it renders 2d graphics in all platforms.

Now I don't want to remap to a custom driver package (mine) since I'll lose the openFl drivers. But I want some entities to use the default openfl context (flash.sprite) and some others to use a custom Context where I'll add things to my 3d scene, add a getter/setter for the z position, do rotate stuff and things like that. Is it possible to use the same Entity objects for both? I'm thinking I have to create two factories, one for normal Entities and another for 3D Entities where I'll inject the new 3D View Class to it? Is this a good practice?

What I'm trying to do is avoid adding the mesh externally to the scene since I like how the whole Entity->View->Context thing works..

I'll keep working.. If anyone has any code/examples, I'd loooooove to take a look:)

Thank you,
Aris Kostakos

[Rob Fell]

Hello Aris, and welcome to the group.

 

I'm not aware of any other published awe6 drivers yet - so anything I can do to help here please feel free to call on me.  The first choice for you is whether to extend OpenFL or roll something new.  From what I've read on developments of OpenFL's Stage3D porting it's likely to be a viable option soon.

 

https://groups.google.com/forum/#!topic/haxelang/IjcakFx9w8Q

 

For 3D games using awe6 I suggest the 3D system exists as a subsystem - so an Entity that proxies another 3D library.  Any aspect of that subsystem (camera, lights etc) can exist as their own proxy Entities.  It's neat to have those as factory methods of the 3D subsystem - e.g. engine3D.createLight( ... ) returns Light (implements IEntity).  Essentially any object you want others to know about (and interact with outside of that subsystem) makes sense to publicly implement IEntity.

 

Likewise you may not need to do anything too elaborate with Context or View.  So long as the 3D subsystem renders to its View's Context, all child Entities can operate more privately within that.  For example this might be a good route towards proxying three.js within the OpenFL driver?  There may be no need for a View3D at all (as all 3D related methods are private to the subsystem)?

 

An abstract Entity3D can be useful (and be sure to implement an interface for 3D transformations).  If going that route try extending from a physics base class first, then a physics base with 3D view, then specifics.  Use composition whenever it presents, either directly composing a subsystem's node, or wrapping that it a proxy Entity (if public exposure is required).

 

Sorry if I missed any other points - just shout.

[Aris Kostakos]

Hello Rob,

Thanks for the prompt reply. I really appreciate it.

Extending OpenFL would certainly be optimal but I don't think I'm up to the task right now. Until OpenFL is ready in that area I'll take the easier route and use three.js and away3d.

I would love to be able to proxy three.js within the OpenFL driver. But I'm trying to wrap my head around that. three.js creates it's own webgl renderer and renders that on a js.Document element. Meanwhile the open-fl driver's View Context is a flash.display.sprite. I really feel like I'm missing something here.
For Stage3D things are more clear to me cause I've worked a lot with away3d. If openfl's flash driver uses a context which is rendered as an actual flash sprite in the standard Display list of the flash's stage, it's impossible to display the 3d stuff there unless you use some kind of renderToBitmapData which would be super slow. stage3d things always render below stage, and everything happens in gpu and the textures are stored in gpu's memory directly. So this would have to be rendered separately. For now though, I'm mostly concerned with the html target.

Now this is were I'm comfused concerning my awe6 drivers. Let's say I do use three.js and away3d and keep the openFL drivers as well. If an Entity is supposed to be platform agnostic, and I don't want to create a new View3D, where to I put all the three.js and away3d code to create my actual scene,camera,etc? Also, where do I put the #if js  (create three.js scene),  #elseif flash (create away3d scene)  code? In your framework the only places where platform-specific code is allowed is Views and Contexts.

My other question is how the 3D subsystem would render to its View's Context like I said above. I don't mind if I use the OpenFL driver, or if I create a View3D and Context3D and do my own things from there. I just want to be able to have transparency, and be able to layer my 3d world above and below of other normal Entities with 2d Views seamlessly.

I'll take your advice on everything else, and indeed extend Entity for the 3D subsystem which will use a factory and create proxy Entities without Views for everything inside the 3d world. I'll also do the Entity3D class.

I hope this makes some sense. I am a bit confused, but everything gets more clear every second. I will keep exploring.

Thanks for the helping hand,

Aris

[Rob Fell]

 

Btw I agree with the approach of mixing best of breed's together (rather than rewriting).

 

If wanting to operate mostly within the Flash / OpenFL DisplayList paradigms ...

 

For JS have a dig through the OpenFL flash.display.Sprite - see where it ends up for the js / openfl-html5 target ... and whether that is then compatible with three.js' js.Document element ... a bit of "untyped" magic might weld one to the other?

 

For Flash yes renderToBitmapData is the easy option to weld to the existing DisplayList, and with that you'd have Away3D working with awe6 in minutes.  Yes performance is less, but I have used this approach at browser game resolution (e.g. 720x480 or less) and it's been fine (for desktop).

 

To join the two systems I'd abstract a "Subsystem3d" Entity.  Inside that would be the compiler conditional and the composition of either Subsystem3d3dThreeJs vs Subsystem3dAway3d - so the concrete is hidden from any system that consumes the subsystem.

 

All of the above would work with the existing awe6 drivers.

 

Or if needing to go beyond then a new driver would be needed (or 2 might be cleaner and avoid conditional compilation in the driver?).  Or 3 and add Mihail's Java Gameplay3D implementation to the mix?  Such a driver suite would probably have some kind of surface primitive as Context, and therefore need to handle it's own scene graph responsibilities (as defined by awe6.core.interfaces.IView).  Probably not too hard, but would be heading away from the pack - so I'd favour the flash DisplayList route.

[Aris Kostakos]

I did a lot of looking around. Here's my findings..

the js/openfl-html5 target ultimately creates a canvas element for every flash.display.Sprite...I think. I couldn't find it in the code but if I run your openfl template app and click "Inspect Element" from Firefox I see that the .js creates a bunch of canvases. Which made me worried to be honest. Is this ideal? Wouldn't it be faster to have a single canvas and use something else to display the items in it? Is OpenFl html5 target really efficient? I sure hope it is....

Here's a test:

http://www.gamepl.org/demos/test1/

Your template app is at the top, and behind it is the webGl canvas. Some things I noticed... Even if the canvas DOM for the webgl is at the bottom, and even if I increase it's z-index from Firefox to whatever, it's still displayed below the 2d stuff.. So I wonder if it's similar to the flash's stage & Stage3D case. Also, There's no transparency in that demo because openFl creates an extra canvas called RootNode by default somewhere, which has white background. With Inspect Element you can delete that node at runtime with firefox/chrome and then you get to see the webgl behind your template app   (the RED color means it's WEBGL, because that's the background color of the webgl canvas).

Also, FlashDevelop insists on creating the default .html with background color==#FFFFFF for the body and the jeash div styles. I had to delete it that manually to get the transparency I wanted. If you happen to know anyway to avoid this, and the RootNode thing it'd be great. But I'll give it a looksie next.

Since I'm getting similar behavior with flash's problem (stage3D MUST be behind normal stages), I'll embrace it rather than fight it.

In away3d it wasn't really a problem. You'll almost never want 3d shown on top of 2d graphics. I want to use the flash-target for mobile AIR so renderToBitmap is not an option. It's better to render 2d stuff in Stage3d with a framework like starling, but I don't want to get carried away (also would need to find some webgl solution for 2d sprites as well). So......

For 2d, I'm sticking with OpenFl. Then for 3d, I'll set the limitation of having them below 2d stuff. Then I'll create the subsystem3d Entity class exactly like you said. The target specific concretes will then call up three.js and away3d, so the concretes Entities won't have a View or a Context either.

Then I'll use all your IoC goodness to create and manage the proxy entities inside my subsystem3d (their logic, behaviors and create them with a data driven approach). What do you think?

[Alvaro Castaneda]

y

ou can have three.js stuff rendered with a transparent back and have it on top of anything you want, just set the clear color property like this

setClearColor: (0x000000, 0),

and don't forget to set the canvas you pass to the webglrenderer as transparent also and you should be able to move it using the z-index

hope that helps

--
You received this message because you are subscribed to the Google Groups "awe6" group.
To unsubscribe from this group and stop receiving emails from it, send an email to awe6+uns...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Aris Kostakos]

hi varomix,

I just had some luck with this myself. instead of increasing the z-index of the webgl canvas, i set the jeash div's z-index to -1, and the jeash div (2d layer) disappeared! I added some padding to the webgl canvas, and there it was, behind it.

I'll try to make the webgl background transparent now like u said. The webgl canvas z-index still doesn't do anything (i think it's 0, whatever I do). I create the canvas at runtime from javascript, but its background color is set at the default:"transparent".

Either way, it's nice this worked but z-ordering between 2d and 3d objects will still be a huge pain (not to mention each 3d entity will now need to be in a separate canvas if I want to place a 2d object between them), so I'm sticking to my plan...  3d at the bottom, 2d at the top.

[Alvaro Castaneda]

if you want to mix 2d and 3d you might want to use 3d sprites in three.js that way you can control them in 3d space 

example 

http://stemkoski.github.io/Three.js/Sprites.html

[Aris Kostakos]

Thanks, but I meant 2d being displayed on the screen.

[Rob Fell]

Hi, did you make any further progress with this?  I'm considering making a full port of a 3D Flash (awe6) game to Three.js + OpenFL Html5.

 

I'd want Three,js webgl canvas underneath the OpenFL canvas as per your demo.  I notice if "Root_MovieClip" is removed via inspector things get close to what we need.  Did you find a way of doing all this in an easy approach?  Any and all tips appreciated.

[Aris Kostakos]

Hi Rob,

Unfortunately, this is as far I've taken this myself. After I saw that it works ok I moved on with porting my existing as3 code to haxe and have been doing since. After I'm done with that (a few more days) I'll get back to it. I imagine I will extend the awe6 drivers in the same way you've done for 2d to include 3d for different platforms (and js will fall to three.js, flash will fall to away3D). The three.js externs are already available on git, and the away3d externs I'll make myself to support the latest version.

Like we talked earlier, the 3d will be using it's own display list (three.js's or away3d's), so it will be completely independent from awe6 entities' view and context. I haven't really given it any more thought since I moved to other things but I'll be working again on it soon. I'll keep you updated. Maybe we could work together on this so we can add three.js native support functionality to awe6.

Cheers,
Aris

[Rob Fell]

I spent yesterday chasing down all related libs and comparing.  Once again I put myself off Unity3D, but I lingered on Turbulenz.  Yes Three.js and Away3D rock in their respective spaces, a Haxe bridge to both is a solid plan.

 

That said I took another look at Nicolas' H3D ... and saw very recent activity on the WebGL implementation.  I think this is a really exciting route: Swf/Stage3D (for now) + Html5/WebGL (for next year).

 

Such a library with hxsl shaders + common api + 2D displaylist + extendable backend ticks ALL my boxes.  Although both Three.js and Away3D are more featured, they are features I likely won't need in my workflow, and as they are fast moving libs expanding all the time the bridge will need continous revision (and new externs etc).

 

What are your thoughts on a H3D route?

[Aris Kostakos]

I think the engine you choose very much depends on what exactly you want to do. If you want to make a game that plays with webgl only and make it quick, then some game engine like turbulenz would do the trick.

Unity3D is another beast entirely. It's sophisticated and featured enough to compete with the big boys (UDK/Unreal3, CryEngine, etc..) but none of them will offer an html5+webgl port anytime soon. Frankly I can see why, since they probably use massive c++ coded libraries to support those high-end illumination techniques, advanced shadowing, IK animation, AI, Networking and all those other game engine goodies. I'm not even sure if u can write all this in .js and not have your browser explode on you. Like you said though, this is perfectly fine since the hardcore player will be willing to download your game, and leave all the other browser-games for the slightly more casual gamers.

I remember looking at H3D but I think i only found examples about his flash/stage3d port. If a solution already exists that provides a common api for both webgl/stage3d with sufficient features, yes I'd use it in an instance. I think OpenFl will eventually make the step as well, but so far I haven't found anything ready to go. Which is why I decided to make my own.

My other issue is that if H3D did give you some basic functionality, and it's still open source so that if you need a feature and it's not there (let's say, post-processing shaders for example), I don't think I'm up to the task of writing that myself in webGL. WebGl/OpenGl, Agal/Glsl is too low level for me.

So, in my case, because I want to be able to export to both webgl and stage3d, using the three.js/away3d 3d graphic engines seems like the only viable option for now. It shouldn't be hard to do either the bindings, or create a common api that talks to either target, just like openFl does for 2d. As for the engines themselves changing frequently, I intend to only 'upgrade' to their latest versions when absolutely necessary. Right now the three.js externs I found work for three.js revision 57. I'm keeping a local copy of that js file in my project, and will do the same for the away3d swc files that I will create my externs for. They're both pretty powerful already, so I don't see a need to support feature versions anytime soon.

However, if I only cared about a specific platform, or a few bunch of them, I'd probably not get into the whole hassle of writing the externs or use haxe/openfl at all. I'd find a nice game engine and code away..

[loudoweb]

Hey,

The next version of the flash 3d library Minko (v3, alpha in September, beta in December) will be in C++ and will export in stage3d with FlasCC and webGl with emscripten.

Here are some informations : http://minko.io/2013/08/26/announcing-minko-3-with-webgl-support/

An haxe port may be very interesting. 3 features are very cool : mk files (x0.1 the weight of a collada), shaders you can write in as3, and Minko Studio that is a great tool.

Loudo