I appreciate the brutal honesty. If I am wasting my time I would like to know, but I have also put a good bit of time into this already and don't want to throw it out on a whim, so I have a few more questions for you if you don't mind.

WebGL and JS are not modern 3D hardware. They are, in many ways, worse than PS1.

Why is WebGL worse than PS1? I have thrown a good bit at my GPU using WebGL and have had no problems. From multiple animations with ~60bones, to large triangle counts. I could send 1025X1025 terrain with no LoD to my GPU and it would chug it down without being my bottleneck. Why do you think that WebGL is worse than PS1 GPU?

Occam's razor - why isn't anyone making anything with them. Because, beyond hype and single-effect demos, they are useless for real world problems. And even then, if one were to put enough effort in them, the range they need to cover is incredible - from integrated graphics cards running on atoms to water cooled overclocked i7 running multiple 6970s.
[/quote]

I agree here, but the engine would essentially be platform independent (not browser independent however) so couldn't one just pick some processor cap and everyone under it is out of luck?

In WebGL and JS, there is none of that. It's a virtual machine. If HTML5 local storage is ever implemented, you will have 5 MB of disk, some 200MB of memory total and serial IO, which drives everything, from GPU to loading to any other external stuff that you have no control over.
[/quote]

Not being able to access the HD definitely does suck, but PS1/N64 didn't have built in HD's either. Of course they could stream things from disk/cartridge, but content can to some extent be streamed from a server these days as well. Also, my engine is already using up 400MB of DRAM, so why is there a 200MB cap?

I know that anything modern is out of the picture, but I think there is still some market for browser games. Zynga is proof of that, they turned silly 2D games into a (they were going to have a 1 billion dollar IPO the last I heard) successful business. I'm sure a lot of us wouldn't mind paying a dollar to play Ocarina of Time, or any other great nostalgic games.

Do you believe that even PS1 quality games are not possible with JS/WebGL?

Why is WebGL worse than PS1? I have thrown a good bit at my GPU using WebGL and have had no problems. From multiple animations with ~60bones, to large triangle counts. I could send 1025X1025 terrain with no LoD to my GPU and it would chug it down without being my bottleneck.

That is not WebGL, it's your graphic card driver. Run the same thing on less than top notch hardware and you'll get one of the following:
- Isn't supported and doesn't work (blank screen)
- Doesn't produce expected results
- Is slow, inaccurate, produces artefacts (due to driver emulation, non-optimal code paths, shader fallbacks)
- Crashes

What we're talking here is shader code, it has nothing to do with JavaScript, browsers or even Web/OpenGL. It's what your particular graphic card driver does to convert shader code onto GPU.

Same for large triangle counts. Once they are in GPU memory, things are great, since it has nothing to do with GL or JS anymore. But you rely on driver being able to handle everything before. Google didn't even realize what a mess it is, they cried loudly when they realized it and simply decided that they aren't capable of providing consistent support.

But WebGL is not "graphics", it's IO. Like file. You write something to it and maybe read from it. But it's completely external, so as long as this goes one way it's easy and fast. It's also asynchronous, so you cannot rely on it for interactive parts.

Why do you think that WebGL is worse than PS1 GPU?[/quote]
In PS1 programmers had access to everything, registers, flags, timing interrupts. They pushed that to limit. Under WebGL you don't know anything - it needs to work even without GPU. You can send an opaque text string and hope something works. How, why, where, when - questions that cannot be answered. And again, once you send something to OGL it's a done deal, you lose all control and it will or will not happen at some point in the future.

I agree here, but the engine would essentially be platform independent (not browser independent however) so couldn't one just pick some processor cap and everyone under it is out of luck?[/quote]
Google gave up on trying to provide that. Do you think maybe their programmers aren't good enough for it? Sure, they only have several billion dollars in budget and 30,000 of world's best programmers with a very heavy hand to pressure just about everyone into supporting them.

It's a pipe dream. Real world isn't cooperating.

Not being able to access the HD definitely does suck, but PS1/N64 didn't have built in HD's either. Of course they could stream things from disk/cartridge, but content can to some extent be streamed from a server these days as well. Also, my engine is already using up 400MB of DRAM, so why is there a 200MB cap?[/quote]200MB might be generous. 20-60 would be more realistic. Because same browser needs to run on Android phone as well. On a GPU which can render about 10k triangle per scene. While on battery saving mode.

Now consider that a single high-quality texture takes several megabytes and you need 40 of them. They cannot be stored, so each time you launch an app it must be downloaded. Via 3g. On a 1 gig/month plan.

This is why WebGL as universal abstraction is flawed.

Zynga is proof of that, they turned silly 2D games[/quote]
They use Flash for pragmatic reasons:
- everyone has it (nobody can run WebGL, even browsers that do support it often need to enable it manually)
- it has strong performance guarantees (it either works or Flash isn't supported on that device - remember that *everyone* had Flash, so it always worked), there is rarely a case where some machine would be too slow, unless application is careless.
- it's a sprite pushing machine. One of most trivial methods of rendering graphics available since 80s. WebGL needs to do things that are "next-gen" today.

I'm sure a lot of us wouldn't mind paying a dollar to play Ocarina of Time, or any other great nostalgic games.[/quote]
Yes, you would. This is why Zynga is worth that much.

They never, ever, even for a second tried to be next-gen. Software isn't even part of their business. To make such advances, risk must be taken out of the equation. They deliver fun, not graphics, not next-gen, not technology, not algorithms, not software, but fun-in-a-can. They are making the type of games because it earns them most money: min(cost of development) and max(customer preference).

Do you believe that even PS1 quality games are not possible with JS/WebGL?[/quote]
Of course it's possible. Anything is possible. If nothing else, you write your own WebGL implementation and require custom browser. But this isn't the real question: "I want as many internet users to have access to what I make in simplest possible way"

Is it cost effective?

Consider the cost of writing 3 separate applications (iOS, Windows, Android). Would WebGL+JS cost more or less?

Right now, given the real state of affairs, WebGL isn't capable (aka, cannot be done, no matter the effort) delivering to 95% of above users (they simply cannot run it).

Thanks for all of the info, you have been really helpful.

I would still like to venture into 3D browser games, but JS is painfully slow, even for basic game engine computations. So what should I do now? Java Applets? If Javascript is 100x slower than C but Java is 10x slower, then its still a pretty big gain. I'm not sure how JOGL compares to WebGL? Are there better methods for making a 3D browser engine? Is it hopeless and I should focus on something else?

I would still like to venture into 3D browser games

Unless it's HTML/JS, it won't run "on web", but client-side plugins that can present themselves in browser. Or same as desktop app, it just crams itself into browser.

, but JS is painfully slow, even for basic game engine computations. So what should I do now? Java Applets? If Javascript is 100x slower than C but Java is 10x slower, then its still a pretty big gain[/quote]
First - why are you writing an engine? And secondly, why do you insist on writing it in environment where everyone gave up, including Google?

Want 3D, use UDK.

AAA high-fidelity graphics are demanding. Of developers, hardware, budgets, ... You'll notice that for last 5-10 years there were no new indie engines. There is some basic 3D here and there, but the rest is 2D. The sheer effort needed to develop something like this under ideal conditions is prohibitive. AAA publishers are having trouble funding such work and even then just for consoles, PC is simply too expensive.

The computational performance is just one of parameters. How fast or not fast one runtime is is merely one parameter and rarely a relevant one. I gave examples above, each of performance problems can and has been addressed and solved in the past. If you cannot crunch 1 million polygons you reduce resolution to 1000. Simple and needs to be done anyway if building an actual game, not just tech demo. It will be one of thousands of compromises made during development.

Are there better methods for making a 3D browser engine?[/quote]

How many 3D browser engines have you heard of so far? How many of those use WebGL? How many of those were used in commercial products? (0/0/0). Runescape and Minecraft run on JVM, which is standalone, Unity is a standalone plugin - none have anything to do with Web or Browsers, they can just be conveniently launched from them.

Applets can, for example, be put into a web page, but there is nothing browser or web about them. The modern alternative is Unity. But so far, none of the proposed solutions managed to get around the basic premise - nobody is really asking for 3D inside a web page.

I was making a 3D engine for the learning experience and a resume builder. It also seemed like a nice bonus that a 3D browser engine wouldn't be expected to compete with all of the crazy 3D engines out there and thus I could make relevant games on a very low budget.

If I made a 3D engine in c++ it would be completely worthless as there are many opensource engines that do more than I would ever be able to do alone. At least with browser stuff I was venturing into something new where there aren't a ton of engines out there and it had a chance of being relevant. I'm just trying to make something relevant without having to be a multimillion dollar corporation.

On a side note: is CopperLicht just tricking people into wasting their money on a 3D javascript engine? Is it completely worthless?

You're wasting your time if you think you'll be able to implement anything more graphically complex than, say, Star Fox on the Super Nintendo. Even though JavaScript performance has improved, it's not nearly fast enough to render a complex scene with WebGL and a mildly complex physics simulation. Iteration in JavaScript is slow, slow, slow. Did I mention iteration in JavaScript is slow? So is array access. Oh, and function calls. You will be both amazed, perplexed, and maybe even disgusted when you get a 2x or more performance increase in your code simply by manually inlining one method call and caching members of objects in local variables instead of accessing them through the the object itself.

JavaScript is a dynamic language. Because objects boil down to basically a Map<String, AnythingUnderTheSun>, accessing members of objects is almost always slow. Some naive C++ programmers concern themselves over the minuscule performance cost of the v-table, which is a simple indirection using integer math at the native-code level. It costs almost nothing. I won't even guess what's involved in accessing a member of a JavaScript object, but I'm sure it involves lots of hashes.

On a side note: is CopperLicht just tricking people into wasting their money on a 3D javascript engine? Is it completely worthless?

No and no.

Reading through their web page, features and demos, they are refreshingly realistic. Engines often overhype what they can do. There is also no talk of next-gen or similar.

It says clearly from the start that they use WebGL and JS. These are well-known and quite open stacks with clearly defined capabilities.

The ability to render large scenes is also true. Most working in graphics are familiar with the difference between just rendering a large scene or interacting with it. As long as scene is static a lot is possible, it's interactivity and fidelity (diverse textures, geometry, shading, lightning, collision) that is an issue.

Animation and skinning is a problem very well suited for GPU. Interactive and responsive animation however is a whole different thing. Having GPU render hundreds or thousands of skinned and animated characters might be more of an question of available memory, but having those same characters interact with environment is next to impossible.

Similar for physics (which isn't even included or advertised), but it's well understood that anything beyond rudimentary physics isn't viable on current web stack. It even says simple physics, rather than a full rigid body physics engine.

I think you just misunderstood what was presented.

For what it's worth, their demos worked on first try for me, which is a quick test that many WebGL demos fail, meaning the engine might be worth a second look, even if just to simplify the initial setup.

Your expectations are unrealistic.

Your post made me laugh smr =)

Your expectations are unrealistic.

I'm not sure what this is in reference to. Is this in reference to me wanting to provide something useful?

If JS can't compete with a 33MHz processor I think I will slit my wrists >_>
Obviously I have loads more DRAM, VRAM and a modern GPU to help pick up some slack, plus whatever I can compute server side and send across the wire. Making some interesting 3D browser games may be entirely possible still.

I currently handle projects using WebGL, so I have a bit of experience.

There are a few things you must understand. First of all, you need to understand who is the intended audience for WebGL. Obviously, since it is being implemented in the browser for the web experience, it is people who are browsing the web. Now, where are people browsing the web? Their computers, their phones, their laptops, their netbooks, their tablets, their TVs, their consoles, their wristwatches etc. etc. you get the picture. In order for WebGL to exist on "almost any platform ever," it is going to have to make some sacrifices, on top of those it already must make because of its web delivery mechanism (streaming/downloading art content, javascript, etc). A PC may give you more juice, but you are still limited by design decisions made to accommodate smartphones (see why WebGL was based on OpenGL 2.0 ES rather than the latest OpenGL desktop API).

The second thing you must understand (and this builds off the first) is that people have certain expectations when it comes to content delivery. People who use smart phones expect games and applications to be limited in nature. Browser based games, such as Flash games, are usually casual, limited scope games. However, you are discussing an attempt to replicate the AAA desktop gaming experience in the browser, and the AAA desktop gaming experience comes with a large set of expectations. Most of these simply cannot be met given the sandbox/limitations of the WebGL/JavaScript platform. Outside of playing old games for nostalgic purposes, people expect their PC/console video games to provide a better graphical experience than those presented by the PlayStation 1 (and even the PS 2 now), with a rich, detailed simulation. While Final Fantasy VII is definitely one of my favorite games, I don't want to load up a brand new AAA video game and see character models with giant blocks for hands and feet, and no facial detail outside of hand drawn googly-eyes. This is why, even though the iPhone is capable of certain amounts of 3D rendering, almost all of the smart phone games use primarily hand-drawn 2D graphics with only a tiny smattering of 3D detail (such as a few foreground objects or maybe a basic terrain). In fact, the most popular games are simple physics games with almost no obvious 3D elements, such as Angry Birds, Siege Hero, Fragger, etc. This is the WebGL target, not AAA content. A modern game can have anywhere from 2 to 16 GIGABYTES of game content alone, which would need to be streamed/downloaded to the user to get started.

Finally, people expect web content to be available to them anywhere they can access the web (think of the outcry over the lack of Flash on iPhones and other web content delivery mechanisms), so the expectations of a person developing a browser based application using WebGL must bear this in mind. A person attempting to load up a AAA WebGL title on their home PC is going to have a significantly different experience than someone running it on their netbook, but they usually expect a homogenous web experience.

But, if you keep these things in mind, there are definitely some uses for WebGL and places where it can be a helpful tool. I don't, however, see it supplanting native apps as the next generation of game delivery, outside of possibly replacing Flash for browser based casual gaming.

Thanks for the helpful posts guys. I can't say that I'm not a bit sad to see my project coming to an end, but I knew there was a low chance of it working and I gained a lot of game engine experience that is language independent.

As stated a few posts above, I'm not sure what the best use of my time is. I definitely want to pursue a career in game programming and it seemed like the best thing to do for that was to implement a small scale 3D engine. I didn't really want to just plug together a bunch of opensource middleware as I wouldn't learn anything doing that.

What should I do? I'm a bit lost now as I've spent the last 4 months working on this (and I've learned a lot!). When I started this I barely knew anything about the details of 3D games, now I've written my own shader code, my own collada parser, setup GPU accelerated skin-and-bone animation, sphere/AABB/OBB bounding volumes and intersection tests, generating pick rays, ray/BV intersections, frustum/BV intersections, a terrain engine with GeoMipMap LoD, an orbiting camera, and the list goes on.

I want to keep improving my skills, but it's hard to be motivated when you know the code you are writing could be pulled out of 10 different opensource engines.