Live data from Hacker News

WebGL water scene

c1.goote.ch

111–115 of 115 posts

Re: WebGL water scene

#111

Earlier quoted context omitted.

Because it runs in any browser, even mobile ones and requires basically 0 time for compilation and no plugins as opposed to unity, unreal or other engines.

On mobile, though, it's total!y non interactive. I can see a guy in a boat and that's it. It's like quakelive, except you can play quakelive against loads of people, not just stare at the title screen.

In the original old version there is a joystick for controlling the boat: labs.gooengine.com/pearl-boy/

Re: WebGL water scene

#112

Earlier quoted context omitted.

I wrote a bunch of ThreeJS and I see code I wrote in your Goo Engine. You also have the ThreeJS license in your license: https://github.com/GooTechnologies/goojs/blob/master/COPYING...

"GooCreate's renderer is based upon ThreeJS". With that I thought you meant that our tool (Goo Create) was built on three.js which it is not. Yes a subset of a few files in the engine contains some code from other open source libraries. Mostly it is a derivative of my previous open source (Java) engines Ardor3D/jMonkeyEngine and new code.

" a subset of a few files in the engine contains some code from other open source libraries"

The code that is ThreeJS derived includes most of the 3D engine classes including:

The main Renderer class (!). As well as the Texture, Camera, RenderTarget, ShaderLib, ShaderBuilder, EventTarget classes. Also the majority of the stuff in the /math, /lights, /pass directories.

GooEngine's renderer (not game engine) was clearly forked from ThreeJS some time ago and diverged (significantly in some places and for the better) but the lineage is clear.

Re: WebGL water scene

#113
post #76

Earlier quoted context omitted.

I have been forced to take the battery out as a way to kill webgl pages on my mobile devices, due to the way they hogged the CPU. Nice idea, execution is still lacking on mobile.

Just like you have to kill any native app for mobile, even though a native app is obviously much more efficient. I think you are missing the point a bit... it is not about making the most performant or visually impressive thing out there. It is about how easy it is to make something that looks good, performs acceptably and runs pretty much everywhere with basically zero effort in terms of porting.

Except your description only applies to desktop class machines.

I am not missing the point, as 99% of the WebGL demos I see being thrown around don't run out of the box on mobile devices that most people have, as you imply.

Re: WebGL water scene

#114

Earlier quoted context omitted.

"GooCreate's renderer is based upon ThreeJS". With that I thought you meant that our tool (Goo Create) was built on three.js which it is not. Yes a subset of a few files in the engine contains some code from other open source libraries. Mostly it is a derivative of my previous open source (Java) engines Ardor3D/jMonkeyEngine and new code.

" a subset of a few files in the engine contains some code from other open source libraries" The code that is ThreeJS derived includes most of the 3D engine classes including: The main Renderer class (!). As well as the Texture, Camera, RenderTarget, ShaderLib, ShaderBuilder, EventTarget classes. Also the majority of the stuff in the /math, /lights, /pass directories. GooEngine's renderer (not game engine) was clearl…

You are right Ben! The rendeder contains a bunch! (Still a subset of the engine like i said)

Hail open source! :)

Re: WebGL water scene

#115

Earlier quoted context omitted.

you really think the water in the boat is not intentional?

.. yes Or maybe not intentional, but too hard to fix. I imagine if the water in the boat was intentional, it'd have totally different looking characteristics (a puddle looks totally different from water in a deep ocean, even if it's the same material). It'd be a pain not to get it in the boat. There's a few ways I can think of to address it, but none of them would be easy: 1.) dynamically tessellate all the water geo…

The easiest way I can think of would be to render the boat first, then render an invisible depth-only polygon at the top of the boat (that, together with the boat hull, encloses the displaced water volume), and then render the water. This doesn't add much complexity. You already have to draw the water in a pass after the boat because the water is translucent when the view angle is steep enough.
Post reply on HN