Realistic camera model demo | Hacker News Reader

Realistic camera model demo

delight-engine.com

46 pointstbolse23 comments

It's quite impressive for an HTML5 demo, but it always annoys me to have to add that qualifier.

The lens flares were impressive and the dust on the lens was nice, but the aliased lines were not. The blur seemed to be made of small squares, which was quite off-putting, and the materials all felt quite flat. Is there any sub-surface scattering, or similar?

Again, it's cool as a demo in a "Hah, check out what we made HTML5 and some JS do!" way but it just reinforces to me that this isn't something I'd want to take to production.

That's true, but the Web platform has its perks, and the demos are trending closer to native. It's about the promise, not the readiness.

It does have benefits, but also downsides. If this is just for fun, then awesome, that's one of the great reasons to hack about with something. If they're looking to sell it or get people to actually use this in production, then I can't see a good reason to. You'll lose the performance, features and tooling available with other modern game engines. Maybe useful if you want to do a little product demo.

I think you haven't considered technology development/innovation cycles. Of course just looking at what is archievable today, we will have a lack of performance, features and tooling, but thats not how technology adoption and performance increases work. There are several factors that will enable web-technologies to outpace native solutions. These factors are not inevitable technologic. One thing that will drive technology adoption is market potential/volume: imagine developing a product once and being able to ship it to any device e.g. customer that has a browser. Well, thats a massive market compared to just one smartphone OS for example. Additionally: think about the time and cost that go into developing cross-platform engines - is this approach able to compete on a long run? Imagine having a release cycle that always instantly pushes out the newest version of your product to all users in realtime - no update processes on client-side. The entry barrier into web-based products comparatively vanishes: no downloads, no install, no plugins...

...not yet talking about new business models that might be/are possible in a web-ecosystem...

"Of course just looking at what is archievable today, we will have a lack of performance, features and tooling, but thats not how technology adoption and performance increases work"

Well yes, but that's what I mean when I say I wouldn't want to take it to production. Maybe in the future, but it's not ready yet. I think it has some way to go before it's viable, and a long way to go before it competes with the likes of Source, Unreal and Unity.

" imagine developing a product once and being able to ship it to any device"

Always a worrying promise, as you need to write one product that works on multiple, slightly different setups. Browser Y supports the CSS selectors you're using, but there's a rendering issue on Browser Z 2.9.0.1 - 2.9.1.3. Browser X renders it correctly but doesn't yet support hardware acceleration so it doesn't run so well.

It's also not the only cross platform option there is, and I'm not sure trying to target vastly different devices with the exact same code is a great idea. Why would we expect to be able to write a game for a phone with a touchscreen that also works on a desktop with a keyboard and mouse? Why is it better to have one product with internal switches "if mobile..." rather than two with shared code? You've now got a lot of regression testing to make sure you're not affecting the desktop experience when you update something that 'should only change the mobile bits'.

"Additionally: think about the time and cost that go into developing cross-platform engines - is this approach able to compete on a long run?"

It depends on the quality of what each side can offer, and the difficulty in adding to it. A cross-platform game engine can add support for a new feature of graphics cards and be ready quickly rather than having to draft an addition to a spec which you hope the browser manufacturers implement similarly, then watching until the market penetration of the version of the browsers you want reaches the right level.

"The entry barrier into web-based products comparatively vanishes: no downloads"

No downloads? So why did it take so long for me to load the demo? I'd like to know how I can get your product over the internet without downloading it.

"Imagine having a release cycle that always instantly pushes out the newest version of your product to all users in realtime - no update processes on client-side"

Imagine having to load large parts of a game online every time you want to play it, rather than just opening a program. Also, realtime updates? Sounds awful. Fix one JS file and watch the fun as some people load an older cached version, others a new one, others loading in that file on level three after loading the older assets on level two. Something that was loaded 5 minutes ago is now trying to call a function on an object that's been renamed in the latest push. Not being able to load level 4 because the server is under strain...

As I say, it's got positives and negatives.

You have a point, but at the same time, would you have been able to try this demo if it were an .exe?

There are plenty of cross platform game engines, like Unity [1] and Unreal [2]. I'm sure there are many others, but those are ones I already know about that have an impressive list of features.

[1] http://unity3d.com/

[2] http://www.unrealengine.com/

of course - run it in a VM - I do it every day

How well does hardware-accelerated OpenGL work in your VM?

way faster than in the browser

Or it could have been made with a cross-platform game engine like Unity or Unreal (possibly Source?).

The only issue I'm seeing with it is that shutter speed doesn't actually increase exposure time. You can see this in the flames. The flames do not become longer, and the ember's flame lines do not trail more when going up at 1/1000 shutter speed and 1/4. There should be some visible blur on them.

Otherwise, it's kinda neat :)

There is a lot going on in this demo, and I really appreciate the camera parameter selection, the dust on the lens (cf Tour 2), and depth of field rendering.

I do have one feature request: click-to-autofocus. Maybe I missed something, but focusing is pretty tough with the sliders.

Great work on the demo!

There's a checkbox :)

This is a brilliant demo. Very well done!

Let me clarify: I would like to click to set the autofocus target (similar to phone cameras).

Sorry for the confusion.

Yup, pretty nice, indeed. I found an "autofocus" switchbutton in the "Camera Parameter" GUI folder. Then it automatically pulls the focus. But yeah, click-to-autofocus would be nice!

I agree, this is really well done! Did you try the camera parameter autofocus checkbox?

Also, a great tutorial for the relationship between shutter speed aperture and available light.

Very interesting demo. I would suggest inverting the click to drag direction. Almost every other drag to pan interaction, from google maps to touch devices, uses the opposite mode. Very jarring and counterintuitive.

Wow, speechless, can't wait to see some games built with new 3D web engines.

EDIT

There's some weird bugs in Chrome on Ubuntu, for instance the youtube video on the start page doesn't seem to play properly.

Great demo. One thought: the whitening of the surfaces as the exposure time gets too long or the aperture too wide doesn't look quite right to me.

fyi, the default view is blurry because of how the camera is focused. To sharpen the view in camera settings increase the focal length of the lens.

Awesome demo, btw.

Ray tracing is the way forward.

Reply on news.ycombinator.com