4 ms·

Written both. Not sure why it needs to be deferred rendering specifically lol. A forward renderer (or a light deferred, or tiled deferred, or forward plus, etc)

Written both. Not sure why it needs to be deferred rendering specifically lol. A forward renderer (or a light deferred, or tiled deferred, or forward plus, etc) would easily prove the same point. The precompiled logic thing is nonsense. This happens on the fly in games too. Shaders get compiled on the device, assets streamed in from disk or the network. Game behavior is typically scripted and patched, etc. Narrow selection of hardware? 10 years ago? Wrong. I work on a game engine that fully supports a 10 year old machine, and most state of the art engines can degrade to that level too. Goofy image formats? Please. DXT1-6, BC1-7, crunched assets, raw DDS, etc. We deal with tons of different formats, lossy and otherwise. Texture arrays, cubemaps, etc too. Malformed XML documents are trivial with a good lexer and we need tons of validation too on our side. Many games patch themselves. The game can scale to a mobile device believe or not. It just doesn't make sense to. Throttling draw calls or streaming only the lowest mip levels is trivial for a good engine. The web is absolutely 100% less efficient than a commercial game engine and does far far less. The flip side is that the barrier to entry is way lower as well. It takes less experience to write a web app than it takes to author a game. I would argue that authoring a web renderer is easier than authoring a state of the art game renderer too, although there are certainly complexities there. The DOM scene graph compared to a game scene graph? Come on, is there even a comparison? I could dump a scene graph for you which is totally dynamically generated in real time that dwarfs the most complicated web page you could find. I mean, heck, we use BVHs, KD trees, octrees, and more to represent our scene graphs. You think the DOM has even a fraction of that complexity? Too quote you, "seriously, just stop for a second and use your head."

angersock 11y ago
I'll stick with my precompiled logic assertion. How many AAA games ship with a fully dynamic language like JS? Of those, how many then expose low-level APIs to those languages instead of just an operating environment suitable only for scripting? At any point, do those games allow trivial fetching of new code from the network from an unspecified source, parsing and executing that code in or out of a sandbox? As for "goofy image formats"--I'm going to be somewhat surprised if you aren't doing a preprocessing step to normalize your textures and images into either an atlas or at least some standard format (with texture compression or whatnot). I know that across the entire space of game engines there are bajillions of formats, but again, when you're building a custom engine for a game, I'm willing to bet that you can pick your battles in ways that browsers simply can't. The "malformed XML" isn't a simple matter of just "Oh, a missing closing tag!". It's "quirks" mode. It's supporting weird old behavior, bug-for-bug, across browser versions (thank you Microsoft). "The web is absolutely 100% less efficient than a commercial game engine and does far far less." See, from a performance standpoint, I wouldn't hesitate to agree that the web engines are less efficient. Similarly, I wouldn't claim that a gas turbine is less efficient than piston engine. However, piston engines are a lot more common because they're more flexible, easier to make, and can put up with a lot more nonsense. You lost me, though, when you said that the web does "far far less" than the specialized work a game engine does. "Come on, is there even a comparison?" Look at the spec: http://www.w3.org/TR/html5/rendering.html#rendering http://www.w3.org/TR/html5/rendering.html#rendering You're absolutely right--there's no comparison. Show me a modern game engine whose rendering pipeline is one tenth as complicated or well-specified! Sure, bang around about your scene-management structures for visibility tests. I'm sure that'll impress your friend at GDC who similarly rediscovering techniques already mined out twenty years ago--better than thirty in the case of octress. At the end of the day, game engines (from a display standpoint), are just rendering lots of triangles, with optional intermediary targets clever shading tricks. There may be some animation, there may be some physics, but all of that is relatively straightforward in implementation compared with the downright byzantine rules for, say, CSS: http://www.w3.org/TR/css-2010/ http://www.w3.org/TR/css-2010/ I'm not saying that game engines aren't impressive feats of engineering--they are in no way, however, near as complicated from anything other than a technical perspective when compared with a modern web browser.
- banachtarski 11y ago
  Preprocessing sure. But the different formats are necessary. Depending on the data in the texture, the compression algorithm may alter the data in a way that behaves better or worse (for example, textures representing normals vs material vs albedo). Before I discuss rendering with you, can you first disclose your experience with game engines or rendering? It's sort of pointless to go into that discussion unless you understand how things have changed in the last 5-10 years or so. edit: Forgot to mention that shipping with a scripting engine is sort of easy. It's just a matter of whether it's exposed to the customer or not. Tons of games (even decade old ones) have shipped with turing complete editors for modding or making custom levels or what have you. I've written a custom VM for a homebrew project that can do precisely this.
  - angersock 11y ago
    Sure. Started out with some school projects that were beautiful object-oriented single-thread vistor-pattern for rendering in fixed-function OpenGL. This predictably led to terrible performance. At the end of school, friend and I decided to extract that code and try to build a real engine around it. Upgraded to thread-safe rendering in OpenGL, one thread handling rendering and windowing tasks, other threads game logic and submitting draw requests, and ultimately other threads handling resource loading onto the GPU (though that came later towards the end). Upgraded that to actually use the programmable pipeline, and finally added support for FBOs and uniforms and buffers and everything so we could actually start on deferred rendering as outlined in Engel's blog and other places. Never did transparency, but if I remember correctly the goal was to probably do something like screen-door+deferred. For the life of me I can't remember the paper we were looking at. Eventual goal was to do full deferred lighting and PBR, but by that point I'd moved over to web development. Every time I went back to that codebase, clean and organized as it was, it was just such a pain in the ass to do anything compared to splatting some JS and Three onto the screen and being done with it. Concurrent with that, I was doing 3D CAD software development in Java with Ardor3D. So, big annoying retained-mode scenegraph with all the BVH nonsense you could ever want, and a bunch of legacy files for things that, when one rendered a building all at once, would kill the graphics card. And don't even get me started on trying to sort out order-independent transparency for that...one of my great failures. By contrast, nowadays I do multiple web workers with websockets to provide 30-60 fps display of waveform data on just bare 2D canvases, with Angular wrapping the components. EDIT: I'm aware of the scripting thing. Note that, until perhaps FarCry, it was pretty well held that scripting languages were "too slow" for most games, nevermind the success of such things as JIT Quake 1 bytecode, or the stuff in Out Of This World, or what have you. Even UnrealScript was considered godawful dog slow and to be avoided if possible, and was finally shown the door. But, in the end, scripting was discovered not to be the super worst thing ever. I think Eve finally hammered that point home to everyone. The scripting languages we have now have come a long way in terms of ease of embedding, with a possible exception for Lua, which has been easy as hell for a while now. Then again, I don't think that many scripting languages have the sheer size of interface with native code that, say, JS in the browser does.
fla 11y ago
I don't think you can compare them. The web feels clunky but if you think about it, it's the ultimate sandbox. Hey, it even supports scriptable accelerated 3d graphics :) So yeah, two different things for two different purpose. They are both state of the art and pushing limits.
jameshart 11y ago
"The web is absolutely 100% less efficient than a commercial game engine and does far far less" I think you underestimate how much work web browsers are doing. The browser rendering engine lays out and renders thousands of character glyphs out of arbitrary vector typefaces (they might even have been downloaded over the network at runtime) at subpixel resolution, compositing over arbitrary backgrounds, keeping track of their precise location on the screen so you can, for example, select a chunk of text and copy it. That's the equivalent level to the pixel-level shenanigans in a game engine. HTML and CSS descriptions of a webpage, with all its embedded images, are the equivalent of a complete description of a level's geometry and textures being loaded into a game. And most games, let's be honest, spend a lot of time displaying a 'Loading please wait' graphic while they pull all of that content into RAM and prepare it for rendering.
- banachtarski 11y ago
  In graphics, everything is done at subpixel resolution. We also have to handle text and the aliasing that occurs not just from screen resolution downsampling but projective aliasing as well for text that is not camera facing or text that is wrapped on a surface. Keeping track of text on a screen is, to put it simply, not hard. There's a lot more state to a level's geometry and textures than just position. Momentum, for one thing, but tint, wind, pathing, any other behaviors, key frames, etc. Some of the meshes get skinned or dynamically deformed if its cloth or hair. Some meshes get generated on the fly. Still others move according to a script or analytic equation like particle quads. Not to mention audio that may be keyed per item and the physics tick. The loading is sometimes more than just pulling stuff from RAM. Decompression, shader compilation, and more. Maybe textures are created dynamically or the level is randomly generated (terrain, creatures, and all). Usually, loading is full threaded and all reading happens asynchronously. Depending on whether you're on a console or not, different optimizations happen since the disk drives have different buffered reading characteristics. I've read plenty of stuff on web browser tech and architecture, particularly because I've been following the Servo project with some interest. I'm not saying it isn't a lot of work (it's a lot of work, like anything worth doing), but I do think it's easier than you're making it out to be.
deaddodo 11y ago
> Goofy image formats? Please. DXT1-6, BC1-7, crunched assets, raw DDS, etc. We deal with tons of different formats, lossy and otherwise. Texture arrays, cubemaps, etc too. Malformed XML documents are trivial with a good lexer and we need tons of validation too on our side. Many games patch themselves. This is the crux of why you're wrong. You get to /choose/ which formats you use and support. You can completely avoid any and all of those, if you like, just by limited your asset support. The web? It has to support all of it's cruft, at all times. It's not optional.
- banachtarski 11y ago
  Gosh, and that's ... hard? Image processing and compression is the easiest type of problem to solve. The algorithms are well documented and available. Also, for your benefit, the formats listed all have different usages, and encode the different channels with varying precisions. They also have different compression artifacts and perform better or worse using different samplers.
  - deleted 11y ago
    [deleted]

angersock 11y ago

I'll stick with my precompiled logic assertion. How many AAA games ship with a fully dynamic language like JS? Of those, how many then expose low-level APIs to those languages instead of just an operating environment suitable only for scripting? At any point, do those games allow trivial fetching of new code from the network from an unspecified source, parsing and executing that code in or out of a sandbox? As for "goofy image formats"--I'm going to be somewhat surprised if you aren't doing a preprocessing step to normalize your textures and images into either an atlas or at least some standard format (with texture compression or whatnot). I know that across the entire space of game engines there are bajillions of formats, but again, when you're building a custom engine for a game, I'm willing to bet that you can pick your battles in ways that browsers simply can't. The "malformed XML" isn't a simple matter of just "Oh, a missing closing tag!". It's "quirks" mode. It's supporting weird old behavior, bug-for-bug, across browser versions (thank you Microsoft). "The web is absolutely 100% less efficient than a commercial game engine and does far far less." See, from a performance standpoint, I wouldn't hesitate to agree that the web engines are less efficient. Similarly, I wouldn't claim that a gas turbine is less efficient than piston engine. However, piston engines are a lot more common because they're more flexible, easier to make, and can put up with a lot more nonsense. You lost me, though, when you said that the web does "far far less" than the specialized work a game engine does. "Come on, is there even a comparison?" Look at the spec: http://www.w3.org/TR/html5/rendering.html#rendering http://www.w3.org/TR/html5/rendering.html#rendering You're absolutely right--there's no comparison. Show me a modern game engine whose rendering pipeline is one tenth as complicated or well-specified! Sure, bang around about your scene-management structures for visibility tests. I'm sure that'll impress your friend at GDC who similarly rediscovering techniques already mined out twenty years ago--better than thirty in the case of octress. At the end of the day, game engines (from a display standpoint), are just rendering lots of triangles, with optional intermediary targets clever shading tricks. There may be some animation, there may be some physics, but all of that is relatively straightforward in implementation compared with the downright byzantine rules for, say, CSS: http://www.w3.org/TR/css-2010/ http://www.w3.org/TR/css-2010/ I'm not saying that game engines aren't impressive feats of engineering--they are in no way, however, near as complicated from anything other than a technical perspective when compared with a modern web browser.

banachtarski 11y ago
Preprocessing sure. But the different formats are necessary. Depending on the data in the texture, the compression algorithm may alter the data in a way that behaves better or worse (for example, textures representing normals vs material vs albedo). Before I discuss rendering with you, can you first disclose your experience with game engines or rendering? It's sort of pointless to go into that discussion unless you understand how things have changed in the last 5-10 years or so. edit: Forgot to mention that shipping with a scripting engine is sort of easy. It's just a matter of whether it's exposed to the customer or not. Tons of games (even decade old ones) have shipped with turing complete editors for modding or making custom levels or what have you. I've written a custom VM for a homebrew project that can do precisely this.
- angersock 11y ago
  Sure. Started out with some school projects that were beautiful object-oriented single-thread vistor-pattern for rendering in fixed-function OpenGL. This predictably led to terrible performance. At the end of school, friend and I decided to extract that code and try to build a real engine around it. Upgraded to thread-safe rendering in OpenGL, one thread handling rendering and windowing tasks, other threads game logic and submitting draw requests, and ultimately other threads handling resource loading onto the GPU (though that came later towards the end). Upgraded that to actually use the programmable pipeline, and finally added support for FBOs and uniforms and buffers and everything so we could actually start on deferred rendering as outlined in Engel's blog and other places. Never did transparency, but if I remember correctly the goal was to probably do something like screen-door+deferred. For the life of me I can't remember the paper we were looking at. Eventual goal was to do full deferred lighting and PBR, but by that point I'd moved over to web development. Every time I went back to that codebase, clean and organized as it was, it was just such a pain in the ass to do anything compared to splatting some JS and Three onto the screen and being done with it. Concurrent with that, I was doing 3D CAD software development in Java with Ardor3D. So, big annoying retained-mode scenegraph with all the BVH nonsense you could ever want, and a bunch of legacy files for things that, when one rendered a building all at once, would kill the graphics card. And don't even get me started on trying to sort out order-independent transparency for that...one of my great failures. By contrast, nowadays I do multiple web workers with websockets to provide 30-60 fps display of waveform data on just bare 2D canvases, with Angular wrapping the components. EDIT: I'm aware of the scripting thing. Note that, until perhaps FarCry, it was pretty well held that scripting languages were "too slow" for most games, nevermind the success of such things as JIT Quake 1 bytecode, or the stuff in Out Of This World, or what have you. Even UnrealScript was considered godawful dog slow and to be avoided if possible, and was finally shown the door. But, in the end, scripting was discovered not to be the super worst thing ever. I think Eve finally hammered that point home to everyone. The scripting languages we have now have come a long way in terms of ease of embedding, with a possible exception for Lua, which has been easy as hell for a while now. Then again, I don't think that many scripting languages have the sheer size of interface with native code that, say, JS in the browser does.

fla 11y ago

I don't think you can compare them. The web feels clunky but if you think about it, it's the ultimate sandbox. Hey, it even supports scriptable accelerated 3d graphics :) So yeah, two different things for two different purpose. They are both state of the art and pushing limits.

jameshart 11y ago

"The web is absolutely 100% less efficient than a commercial game engine and does far far less" I think you underestimate how much work web browsers are doing. The browser rendering engine lays out and renders thousands of character glyphs out of arbitrary vector typefaces (they might even have been downloaded over the network at runtime) at subpixel resolution, compositing over arbitrary backgrounds, keeping track of their precise location on the screen so you can, for example, select a chunk of text and copy it. That's the equivalent level to the pixel-level shenanigans in a game engine. HTML and CSS descriptions of a webpage, with all its embedded images, are the equivalent of a complete description of a level's geometry and textures being loaded into a game. And most games, let's be honest, spend a lot of time displaying a 'Loading please wait' graphic while they pull all of that content into RAM and prepare it for rendering.

banachtarski 11y ago
In graphics, everything is done at subpixel resolution. We also have to handle text and the aliasing that occurs not just from screen resolution downsampling but projective aliasing as well for text that is not camera facing or text that is wrapped on a surface. Keeping track of text on a screen is, to put it simply, not hard. There's a lot more state to a level's geometry and textures than just position. Momentum, for one thing, but tint, wind, pathing, any other behaviors, key frames, etc. Some of the meshes get skinned or dynamically deformed if its cloth or hair. Some meshes get generated on the fly. Still others move according to a script or analytic equation like particle quads. Not to mention audio that may be keyed per item and the physics tick. The loading is sometimes more than just pulling stuff from RAM. Decompression, shader compilation, and more. Maybe textures are created dynamically or the level is randomly generated (terrain, creatures, and all). Usually, loading is full threaded and all reading happens asynchronously. Depending on whether you're on a console or not, different optimizations happen since the disk drives have different buffered reading characteristics. I've read plenty of stuff on web browser tech and architecture, particularly because I've been following the Servo project with some interest. I'm not saying it isn't a lot of work (it's a lot of work, like anything worth doing), but I do think it's easier than you're making it out to be.

deaddodo 11y ago

> Goofy image formats? Please. DXT1-6, BC1-7, crunched assets, raw DDS, etc. We deal with tons of different formats, lossy and otherwise. Texture arrays, cubemaps, etc too. Malformed XML documents are trivial with a good lexer and we need tons of validation too on our side. Many games patch themselves. This is the crux of why you're wrong. You get to /choose/ which formats you use and support. You can completely avoid any and all of those, if you like, just by limited your asset support. The web? It has to support all of it's cruft, at all times. It's not optional.

banachtarski 11y ago
Gosh, and that's ... hard? Image processing and compression is the easiest type of problem to solve. The algorithms are well documented and available. Also, for your benefit, the formats listed all have different usages, and encode the different channels with varying precisions. They also have different compression artifacts and perform better or worse using different samplers.
- deleted 11y ago
  [deleted]