Realistic Camera Demo

229 views
Skip to first unread message

f-chr...@xymatic.com

unread,
Jun 17, 2013, 5:09:23 PM6/17/13
to webgl-d...@googlegroups.com
Hello everyone,

I just wanted to post this WebGL demo, featuring a physically based camera which includes techniques like bokeh depth of field, glare, lens flares, film grain, dynamic color grading and more. It uses some other cool techniques such as physically based shading, deferred rendering, HBAO and variance shadow mapping. Just in case you want to check it out: http://delight-engine.com/camera/client/

Any feedback is highly appreciated!

Cheers,
Frederik

Mark Callow

unread,
Jun 17, 2013, 10:38:42 PM6/17/13
to webgl-d...@googlegroups.com, f-chr...@xymatic.com

On 2013/06/18 6:09, f-chr...@xymatic.com wrote:
I just wanted to post this WebGL demo, featuring a physically based camera which includes techniques like bokeh depth of field, glare, lens flares, film grain, dynamic color grading and more. It uses some other cool techniques such as physically based shading, deferred rendering, HBAO and variance shadow mapping. Just in case you want to check it out: http://delight-engine.com/camera/client/

This DoS'ed Firefox 22 on Windows XP. I didn't even get the usual script-has-been-running-too-long message. Eventually the click on the tab's X button make it through but for 2 or 3 minutes I couldn't do anything it FF and even the system was sluggish.

Not a good advertisement for WebGL I'm afraid.

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.

Xavier Ho

unread,
Jun 18, 2013, 4:03:16 AM6/18/13
to webgl-d...@googlegroups.com, f-chr...@xymatic.com

Seeing that his email address contains 'chromium', maybe Firefox wasn't tested properly.

I'll definitely have a look when I get home and let you know if I have the same issue.

Xav

– Sent from Earth

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

Xavier Ho

unread,
Jun 18, 2013, 6:39:09 AM6/18/13
to webgl-d...@googlegroups.com, f-chr...@xymatic.com
I'm on Windows 7, AMD HD5970.

Google Chrome failed software assertion: "Sorry, your Browser and/or hardware does not support the following WebGL extensions: textureFloat" (27.0.1453.110 m.)

Firefox runs fine, v 21.0.  Great demo.

Xav

f-chr...@xymatic.com

unread,
Jun 18, 2013, 9:14:11 AM6/18/13
to webgl-d...@googlegroups.com, f-chr...@xymatic.com
Hi,

we did in fact test both browsers quite extensively. The only "problem" with FF being that on some platforms the WEBGL_depth_texture extension is not supported, yet, which results in 3 more depth passes to be rendered. This in turn ups the VRAM usage quite a bit depending on the resolution used to view the demo. As a matter of fact, the VRAM usage of the demo in "ultra" quality, that is full scale (floating point) framebuffers and quite a lot of passes, plus rather hi-res cubemaps and textures for the geometry, is very high in total (~1gb). Overstepping the VRAM bounds tends to have a somewhat unpleasant effect on the browser and depending on the OS even the whole system. We are also using texture compression where it is feasible and try to pack as much data as possible into one framebuffer attachment and reuse it in subsequent passes, but there may be still _some_ room to optimize.

As already discussed on other occasions, it would be rather good to be able to query the amount of VRAM available in WebGL; but since this is not the case yet, I am afraid we are stuck with this problem. Nonetheless: I personally think it is a good thing to push WebGL to do pretty complex things, and then try to address the issues that arise of such usage; this will just make the WebGL standard better. And high-quality demos that try to go towards native quality are pretty important as advertisement for WebGL IMHO.

Thanks for testing and the feedback!

Cheers,
Frederik

Martin Gradwell

unread,
Jun 18, 2013, 9:14:16 AM6/18/13
to webgl-d...@googlegroups.com
This worked on my Ubuntu 13.10 preview machine with both Firefox (22.0) and Chrome. That machine has an old Nvidia GeForce 8400 GS.

It didn't work on my Vista machine, but that is perhaps to be expected since that machine has an even older 7100 GS.

I can confirm that when the program works it is visually impressive and a good advertisement for WebGL.

Incidentally, I note that for Xavier Ho the program worked fine on Firefox but not on Chrome. I've noticed that with a couple of programs recently. For instance the WebGL port of the Elevated 3D terrain demo (http://301.untergrund.net/elevated.html) used to work on my Vista box using Chrome but doesn't any more. It still works on FireFox. What's up with that? Does anyone know?

Martin Gradwell

Kenneth Russell

unread,
Jun 24, 2013, 9:44:18 AM6/24/13
to webgl-d...@googlegroups.com
Great demo. It's exciting to see work like this pushing boundaries,
and leading-edge lighting being done in WebGL.

Worked well on a MacBook Pro Retina Display with GeForce GT 650M
(29.0.1546.0 (Official Build 208092) canary). "Ultra" quality was very
slow. Given the problems with it bringing machines to their knees, I'd
suggest that you change the default setting to "medium".

Exhausting VRAM causes problems on many OSs and graphics drivers. Some
investigation has been done into the behavior when VRAM is exhausted
on multiple operating systems. Adding either static or dynamic VRAM
queries to the API would introduce various portability problems. I
think the best and most robust solution would be for your application
to measure its run-time performance and dynamically scale down the
quality if it can't meet its frame rate target.

-Ken

Niklas Voss

unread,
Jun 24, 2013, 5:05:36 PM6/24/13
to webgl-d...@googlegroups.com
Looks great! On medium I had a decent framerate on my early 2011 Macbook Pro (ATI Graphics), but only about 10fps on ultra, but anyway great work!
Reply all
Reply to author
Forward
0 new messages