You guys should more prominently make note of that on your website. I already crossed it off as another proprietary unreal/unity and moved on until I luckily read this comment.
The audio is really choppy on Google Chrome 46.0.2490.86 m and a little warbly although not choppy on FireFox 35.0. Otherwise, still a pretty nifty demo.
Check out the forum at forum.goocreate.com and let us know what you think. We are looking for ways to improve the platform to make it easier for people to use and more open too.
Hey, I have a quick UI suggestion that might help with on-boarding:
In the create new UI, the name field needs to be more obvious. Since the template thumbnails command so much immediate attention, it took me a minute to figure out what was wrong when I was trying to create a canvas and the blue button at the bottom was disabled.
Indeed. We are in the process of adopting more of a google docs flow to document creation. This would mean having the templates right in your dashboard and then getting sent directly into the scene when selecting a template. You can always give a name to your scene at a later time. Thank you for the feedback :)
One thing that i've seen a couple of times now with these types of demos is that the animation is pretty smooth, but the music / sound is stuttering and noisy. Anyone has that as well? I'm using Chrome on a pretty beefy (16GB) MacBook Pro.
Audio very badly stutters here under Firefox on a reasonable spec Win 8.1 PC - 3.6GHz i3-4160 dual core, GTX 970, 16GB RAM. Not an award winning spec system, but for single threaded maximised games (most) it's more than decent. ;)
O.o This is exactly what I needed to keep me going in the final stretch of this computer graphics course I am taking. Final in 2 days, was starting to feel study-fatigue, but am now reinvigorated!
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.
Except, that technically speaking what we are viewing at has been available on desktop for years. There is nothing cutting-edge about this demo, except that it's in a different shell.
I just don't quite understand why everyone is getting so excited about individual demos.
I don't think you can ever expect the same level of quality and performance that you get with a native program that gets specifically compiled for a certain platform, and sometimes written specifically for it. With WebGL it is just JS, and with GooCreate you can make really cool scenes that can include interactivity (with state machine and no coding or with custom scripts) and then just press publish and have it available for millions of people... no need to compile for several minutes for each different platform and no need for huge downloads.
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.
"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.
Looks very nice apart from some minor details like water going through the boat. And runs very smoothly on my old Linux laptop with a built-in graphics card.
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 geometry on the outskirts of the boat not to intersect (slow and complicated!)
2.) do some sort of stencil rendering to ensure the interior of the boat doesn't render the water (similar to how stencil shadows work). Also complicated!
3.) Render the hull of the boat only to the depth buffer (no colors rendered), and use multiple passes to make sure the water doesn't clip into the boat.
There's probably quite a few other ways I haven't thought of, but it's definitely not an easy problem.
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.
The water in the boat doesn't look like water in the bottom of a boat should look. It's clearly just the surrounding showing through and would be work to fix.
A way to fix this would be to render the boat and the water separately then merge the two images, but that feature may not be available on the engine that they're using for this simulation (goocreate.com)
Choppy for me with a Nvidia GTS 450 (proprietary drivers) on Fedora 23. Every part of the massively long pipeline from HTML to DVI has to be perfect to get smooth playback. It seems we are some way away from reaching that yet.
Smooth on my Intel (HD Graphics 5500 / Broadwell, 2015) graphics. Nvidia's GTS 450 is 5 years old, so I don't think "we are some ways away" is necessarily true, but it is of course still very wasteful.
There is a vimeo channel but hasn't been updated with cool videos in a while. We need to fill up the youtube and vimeo channels for sure. https://vimeo.com/gootechnologies
Very few "WebGL" sites do any 3D. Mostly, they're just doing pans, zooms, canned 2D animations, and layers. I've been looking at galleries of WebGL sites. Other than demos, very few do anything you couldn't do in Flash.
3D in the browser has been here before, in VRML 97, Web3D, and Shockwave Flash. It's never caught on. The technology is great, but nobody cares.
There's now Web3D in the browser using WebGL.[1] (Web3D is just VRML 97 with XML syntax.) Nobody uses this.
Well, you can do full 3D modeling, editing, animation as well cloud rendering in the browser using http://clara.io -- it is like Blender/3DS Max in the browser. We've got +140K users, +400K scenes (100K of which are public.) People do use this stuff.
Yep, no collisions. The demo was made some 2-3 years ago and it surfaced here on HN yesterday for some reason. Back then we didn't have physics support in the Goo Engine. Now we have Cannon.js fully integrated into it (in fact the creator of Cannon.js works with us and has been tweaking it to work well with Goo Create and the Goo Engine).
I agree with your point, but I doubt your statistic..I think it's probably the other way around. That is, probably 99% of the world's web browsing population is not actively listening to music.
I'm surprised it still runs :)
The character uses more joints than some mobiles can handle (those with a vertex uniform limit of 128).