Comments on: my thoughts on google’s 3d experiment http://www.0xdeadbeef.com/weblog/2009/04/my-thoughts-on-googles-3d-experiment/ I wuv you. Tue, 09 Mar 2010 08:03:52 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Eugene Lazutkin http://www.0xdeadbeef.com/weblog/2009/04/my-thoughts-on-googles-3d-experiment/comment-page-1/#comment-187573 Eugene Lazutkin Mon, 04 May 2009 06:17:26 +0000 http://www.0xdeadbeef.com/weblog/?p=1223#comment-187573 @fooburger: I think you got it right: while a markup language can be used to represent a scene graph (and many other things), not every given markup is suitable for that. @fooburger: I think you got it right: while a markup language can be used to represent a scene graph (and many other things), not every given markup is suitable for that.

]]> By: fooburger http://www.0xdeadbeef.com/weblog/2009/04/my-thoughts-on-googles-3d-experiment/comment-page-1/#comment-187566 fooburger Mon, 04 May 2009 04:18:00 +0000 http://www.0xdeadbeef.com/weblog/?p=1223#comment-187566 Not sure what this means: "A markup language (examples: SVG, HTML) != a universal scene graph." Markup languages can represent anything and everything. If there is some other representation capable of representing a 'universal scene graph', then it can certainly be represented in a markup language. Maybe SVG and HTML aren't it, but... Not sure what this means: “A markup language (examples: SVG, HTML) != a universal scene graph.”

Markup languages can represent anything and everything. If there is some other representation capable of representing a ‘universal scene graph’, then it can certainly be represented in a markup language. Maybe SVG and HTML aren’t it, but…

]]> By: WebDevGeekly » Blog Archive » Episode 11 http://www.0xdeadbeef.com/weblog/2009/04/my-thoughts-on-googles-3d-experiment/comment-page-1/#comment-187499 WebDevGeekly » Blog Archive » Episode 11 Sun, 03 May 2009 00:55:01 +0000 http://www.0xdeadbeef.com/weblog/?p=1223#comment-187499 [...] Google Releases O3D * Announcement http://code.google.com/apis/o3d/ * Alex Russell loves it http://alex.dojotoolkit.org/2009/04/an-now-for-something-entireoooh-shiny/ * Chris Blizzard on the differences between O3D and the open 3D work being done in Firefox http://www.0xdeadbeef.com/weblog/?p=1223 [...] [...] Google Releases O3D * Announcement http://code.google.com/apis/o3d/ * Alex Russell loves it http://alex.dojotoolkit.org/2009/04/an-now-for-something-entireoooh-shiny/ * Chris Blizzard on the differences between O3D and the open 3D work being done in Firefox http://www.0xdeadbeef.com/weblog/?p=1223 [...]

]]> By: Google plugs PC power into cloud computing « Web Development Bangladesh http://www.0xdeadbeef.com/weblog/2009/04/my-thoughts-on-googles-3d-experiment/comment-page-1/#comment-187178 Google plugs PC power into cloud computing « Web Development Bangladesh Wed, 29 Apr 2009 01:26:58 +0000 http://www.0xdeadbeef.com/weblog/?p=1223#comment-187178 [...] evangelist Chris Blizzard suggested in a blog post that the suddenly accelerating JavaScript performance means a lot of higher-level work needed for [...] [...] evangelist Chris Blizzard suggested in a blog post that the suddenly accelerating JavaScript performance means a lot of higher-level work needed for [...]

]]> By: Google and Mozilla 3D Round-up | Guilda Blog http://www.0xdeadbeef.com/weblog/2009/04/my-thoughts-on-googles-3d-experiment/comment-page-1/#comment-187122 Google and Mozilla 3D Round-up | Guilda Blog Tue, 28 Apr 2009 05:26:57 +0000 http://www.0xdeadbeef.com/weblog/?p=1223#comment-187122 [...] should the web go? Mozilla’s Chris Blizzard compares the debate to Canvas vs. SVG: Canvas is a very simple API, much like what we’ve proposed to Khronos for 3D support. It’s [...] [...] should the web go? Mozilla’s Chris Blizzard compares the debate to Canvas vs. SVG: Canvas is a very simple API, much like what we’ve proposed to Khronos for 3D support. It’s [...]

]]> By: Freetracking.org » Google plugs PC power into cloud computing http://www.0xdeadbeef.com/weblog/2009/04/my-thoughts-on-googles-3d-experiment/comment-page-1/#comment-187067 Freetracking.org » Google plugs PC power into cloud computing Mon, 27 Apr 2009 20:45:42 +0000 http://www.0xdeadbeef.com/weblog/?p=1223#comment-187067 [...] evangelist Chris Blizzard suggested in a blog post that the suddenly accelerating JavaScript performance means a lot of higher-level work needed for [...] [...] evangelist Chris Blizzard suggested in a blog post that the suddenly accelerating JavaScript performance means a lot of higher-level work needed for [...]

]]> By: Ajaxian » Google and Mozilla 3D Round-up http://www.0xdeadbeef.com/weblog/2009/04/my-thoughts-on-googles-3d-experiment/comment-page-1/#comment-187017 Ajaxian » Google and Mozilla 3D Round-up Mon, 27 Apr 2009 12:00:52 +0000 http://www.0xdeadbeef.com/weblog/?p=1223#comment-187017 [...] should the web go? Mozilla’s Chris Blizzard compares the debate to Canvas vs. SVG: Canvas is a very simple API, much like what we’ve proposed to Khronos for 3D support. It’s [...] [...] should the web go? Mozilla’s Chris Blizzard compares the debate to Canvas vs. SVG: Canvas is a very simple API, much like what we’ve proposed to Khronos for 3D support. It’s [...]

]]> By: The Cheap Computer Geek » Blog Archive » Google plugs PC power into cloud computing http://www.0xdeadbeef.com/weblog/2009/04/my-thoughts-on-googles-3d-experiment/comment-page-1/#comment-187012 The Cheap Computer Geek » Blog Archive » Google plugs PC power into cloud computing Mon, 27 Apr 2009 11:17:45 +0000 http://www.0xdeadbeef.com/weblog/?p=1223#comment-187012 [...] evangelist Chris Blizzard suggested in a blog post that the suddenly accelerating JavaScript performance means a lot of higher-level work needed for [...] [...] evangelist Chris Blizzard suggested in a blog post that the suddenly accelerating JavaScript performance means a lot of higher-level work needed for [...]

]]> By: Eugene Lazutkin http://www.0xdeadbeef.com/weblog/2009/04/my-thoughts-on-googles-3d-experiment/comment-page-1/#comment-186914 Eugene Lazutkin Fri, 24 Apr 2009 19:17:45 +0000 http://www.0xdeadbeef.com/weblog/?p=1223#comment-186914 First of all thank you for very thought-out and well-versed opinion on the current state of 3D in browsers. Your observations on SVG and Canvas are right on the money too (disclaimer: I work on dojox.gfx and work with SVG/Canvas/VML/Silverlight on the regular basis). But I want to clarify the retained mode vs. the immediate mode. I think that the problem is not stated properly. It is more about scene graphs and where to keep them: on the JS side, or on the browser side (e.g., in C/C++) and corresponding flexibility vs. performance trade-offs. 1) Different tasks (regenerating a picture, processing events, animating objects, and so on) may require different scene graphs. They can be traversed differently (e.g., in different order), organized differently (e.g., using a spacial index vs. a linked list), or processed differently (e.g., all invisible shapes/vertices are removed ahead of time). 2) A markup language (examples: SVG, HTML) != a universal scene graph. It can be used to derive it (to some degree), but it is not the same. The same consideration goes for storage formats. Being a pragmatist I think that we do need scene graphs that are close-to-the-metal outside of JS, but their construction, and their behavior should be simple and well defined. It should not be a black box. If this problem is solved for Canvas/Canvas3D there is no stopping us (client-side developers) from exploding the market of rich/desktop applications. First of all thank you for very thought-out and well-versed opinion on the current state of 3D in browsers. Your observations on SVG and Canvas are right on the money too (disclaimer: I work on dojox.gfx and work with SVG/Canvas/VML/Silverlight on the regular basis).

But I want to clarify the retained mode vs. the immediate mode. I think that the problem is not stated properly. It is more about scene graphs and where to keep them: on the JS side, or on the browser side (e.g., in C/C++) and corresponding flexibility vs. performance trade-offs.

1) Different tasks (regenerating a picture, processing events, animating objects, and so on) may require different scene graphs. They can be traversed differently (e.g., in different order), organized differently (e.g., using a spacial index vs. a linked list), or processed differently (e.g., all invisible shapes/vertices are removed ahead of time).

2) A markup language (examples: SVG, HTML) != a universal scene graph. It can be used to derive it (to some degree), but it is not the same. The same consideration goes for storage formats.

Being a pragmatist I think that we do need scene graphs that are close-to-the-metal outside of JS, but their construction, and their behavior should be simple and well defined. It should not be a black box. If this problem is solved for Canvas/Canvas3D there is no stopping us (client-side developers) from exploding the market of rich/desktop applications.

]]> By: Mark Finkle’s Weblog » Day Dreaming about Web Storage http://www.0xdeadbeef.com/weblog/2009/04/my-thoughts-on-googles-3d-experiment/comment-page-1/#comment-186906 Mark Finkle’s Weblog » Day Dreaming about Web Storage Fri, 24 Apr 2009 15:19:52 +0000 http://www.0xdeadbeef.com/weblog/?p=1223#comment-186906 [...] Chris Blizzard’s post discussing Google’s O3D & Mozilla’s Canvas3D is great comparison of high-level vs. [...] [...] Chris Blizzard’s post discussing Google’s O3D & Mozilla’s Canvas3D is great comparison of high-level vs. [...]

]]>