New emscripten GL demo

[Floh]

Strange, my previous post didn't show up. Apologies if double post.

Here's an early preview of Nebula3 running on emscripten: 

http://dl.dropbox.com/u/17094030/emscdemo/emsctest.html

There's no input handling yet, that's what I'll work on next.

-Floh.

[Alon Zakai]

Looks great!

- azakai

[Floh]

I have updated the demo with input handling, and you can add now more dragons (press Up key to add dragons, Down key to remove dragons, mouse-button + dragging to move camera, Space key to reset camera).

Link: http://n3emscripten.appspot.com/

You can check how performance holds up against the Native Client version here (this has a few more dynamic lights, but this shouldn't make much of a difference):

https://chrome.google.com/webstore/search/nebula3

Considering that each dragon evaluates its own animation on the CPU I think the performance of the JS version is pretty good :)

emscripten optimization flags are:

-O2 --llvm-opts 3 --llvm-lto 0 

I had to disable the LTO optimzation pass since I got strange crashes. Haven't looked at those in detail yet though.

-Floh.

[Alon Zakai]

Yes, performance does look pretty good :)

Out of curiosity, does Nebula3 have an option to do animation on the GPU too?

About LLVM LTO, we have seen some bugs there and filed them. It seems
LLVM's LTO code is less tested for some reason. If you find a concrete
bug we should tell them.

- azakai

[Floh]

N3 can't evaluate the animation on the GPU yet, although it definitely would take a lot of pressure off the JS engine. Only the actual vertex skinning is performed in the vertex shader.

The joint skeleton is animated on the CPU, and the joint palette is uploaded to a vertex shader variable.

Evaluating the animation on the GPU could actually work by adding a separate animation evaluation "rendering pass" in front of everything else, this would evaluate animations (sampling and mixing) in the fragment shader, by reading from float textures with the source animation data, and writing resulting joint matrices to a float render target texture with 1 line per character.

Then when the actual character is rendered, vertex shader texture fetch would be required to read the joint matrices from the previously generated texture. Optionally the joint texture could be read with the CPU and written to vertex shader registers, but reading data back with the CPU would probably be very slow, especially in WebGL...

Maybe I'll play around with that idea later...

Cheers,

-Floh.

[Mark Callow]

On 2012/10/22 2:24, Floh wrote:

I have updated the demo with input handling, and you can add now more dragons (press Up key to add dragons, Down key to remove dragons, mouse-button + dragging to move camera, Space key to reset camera).

Link: http://n3emscripten.appspot.com/

The dragons look nice.

2 problems with full-screen mode:

1. The drawing buffer is not resized so content is zoomed up to the full screen size and looks awful due to the aliasing. Need to handle the resize event and set canvas.{width,height} = canvas.client{Width,Height} * window.devicePixelRatio.
2. No input.
   

Regards

    -Mark

--

注意：この電子メールには、株式会社エイチアイの機密情報が含まれている場合が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情報の使用を固く禁じております。エラー、手違いでこのメールを受け取られましたら削除を行い配信者にご連絡をお願いいたし ます.

NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.

[Floh]

Yes I still need to make fullscreen work. Since this is a deferred renderer, I also need to reallocate all the offscreen render targets. And fullscreem mode seems to behave differently between Chrome and Firefox. 

-Floh.

[Alon Zakai]

Yes, fullscreen in chrome is still buggy last I checked - the spec
says to stretch the fullscreened element to fill the screen and chrome
does not do that.

That's also why going to fullscreen does not send a resize event - the
canvas size does not actually change. To keep things simple in the
BananaBread demo we only run the game in fullscreen anyhow, and set
the canvas size to the full screen (if you select "hi res"). Another
option is to use a callback when fullscreen mode is entered or left
(Module.onFullScreen with argument on or off). Both approaches should
be fine in both chrome and firefox, assuming you change resolution to
the screen's resolution.

- azakai