From car...@ Mon Mar 1 01:54:14 2010 From: car...@ (Carl van Heezik) Date: Mon, 1 Mar 2010 10:54:14 +0100 Subject: [Public WebGL] A Declarative node set for WebGL? In-Reply-To: <45774A4F67BB4C15BFAEA718C7E7BE2F@LenBullardPro> References: <45774A4F67BB4C15BFAEA718C7E7BE2F@LenBullardPro> Message-ID: <099BBCC9-66B4-4490-B365-7C594AC1AADD@microcan.nl> A declarative node set for WebGL is not a bad idea but it should NOT be part of the WebGL spec. From the Khronos website WebGL is a cross-platform, royalty-free web standard for a low-level 3D graphics API based on OpenGL ES 2.0, exposed through the HTML5 Canvas element as Document Object Model interfaces. Please define WebGL as a close to the hardware as possible. Keep the WebGL specification lean so it can run on devices with limited resources. There is a reason why different scene graphs / graphics file formats exist. There is simply no one fits all solution. People have different taste, some like Red others Green or Blue. Even if the red coat fits they prefer the blue coat because of their taste. Scene graphs will come and go and the some will survive because everybody is using them. We have seen in the past that just putting a label on it saying that its a standard doesn't help. If its good it will be used if its bad it will not survive. WebGL will be a success if it works well and is running on millions of devices with appealing applications. In my opinion this will be the case. (I am still a little worried about the speed of javascript, smart use of the GPU will probably help). Best regards, Carl van Heezik Op 27 feb 2010, om 04:34 heeft Len Bullard het volgende geschreven: It's a namespace. The DOM can handle that. It really shouldn't matter what scene graph or encoding is layered on top of WebGL. It's the responsibility of the builder and author to use it efficiently. IMO, HTML is exactly the venue to discover it. HTML isn't exactly a light nugget itself but if namespaced-based integration using the DOM is the basis for blending the markup, then it has to work in HTML. What is more important to interacting with WebGL, HTML or the DOM? Is the WebGL developers concept of the DOM defined by the infoset specification? What limits does HTML place on the WebGL use of the DOM? As far as standardization goes, it goes according to the standards work. Some last. Some don't. As long as it is doing a job for someone, it has its own reason to be there. What Chris seems to be proposing if I understand this is a special set of WebGL element types that are more closely bound to WebGL than any existing scene graph markup or alternative. Where are there examples of the element types proposed? Thanks! len -----Original Message----- From: owner-public_webgl...@ [mailto:owner-public_webgl...@] On Behalf Of Thatcher Ulrich Sent: Thursday, February 25, 2010 11:40 PM To: Len Bullard Cc: Chris Marrin; public webgl Subject: Re: [Public WebGL] A Declarative node set for WebGL? My 2 cents: A 3d scene graph layered on top of WebGL (and/or other rendering backends) in the form of a library: sure, the more the merrier -- WebGL should try to be functional enough to make this work well. A 3d scene graph standardized into HTML: premature. Despite many attempts over the decades, there does not exist a one-size-fits-all scene graph that is small enough to be a good standard. Maybe someday there will be, but HTML standardization is not the venue to discover it. One thing I *would* like to see is a good way to reflect an HTML DOM subtree into a WebGL texture. I think this would enable practically all of the worthwhile use cases of DOM in 3D. If a dominant scene graph library emerges out of that, then think about standardizing it. -T ----------------------------------------------------------- You are currently subscribe to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma...@ Mon Mar 1 14:11:39 2010 From: cma...@ (Chris Marrin) Date: Mon, 01 Mar 2010 14:11:39 -0800 Subject: [Public WebGL] Proposal for depth and stencil FBO attachments In-Reply-To: <921bb11002261129o4b594e98v117c3fec8ff1f76a@mail.gmail.com> References: <921bb11002251128m66df4d80rab6cd127481edbbf@mail.gmail.com> <97AE520D-CF63-4CCA-9A1E-00EF7B291FE4@apple.com> <921bb11002251954y210844a4r906cac4e35582034@mail.gmail.com> <33072142-40DF-4D4A-BD80-F1FB7B48C6E5@apple.com> <921bb11002261129o4b594e98v117c3fec8ff1f76a@mail.gmail.com> Message-ID: <2A53AB74-3D72-4DF5-BE7F-5F0340246C5E@apple.com> On Feb 26, 2010, at 11:29 AM, Kenneth Russell wrote: >> ...Ok, then I agree that we should come up with semantics that can be emulated on all three styles of rendering libraries (OpenGL, GL ES, and D3D). But do we need to get rid of the stencil enums? Can't we just say that you can have one and only one of { depth, stencil, depth_stencil }? In other words, remove your rule 3 and change rule 4 to include STENCIL_ATTACHMENT. Again, I have no problem with getting rid of bare stencils in the spec, but only if there is no other way. There will be some implementations that will be able to optimize memory usage better if they know the author just wants a stencil buffer. > > Yes, we could forbid attaching independent depth and stencil > renderbuffers at the same time, and leave in separate stencil. Even if > we take out separate stencil renderbuffers, we will still have to > change the semantics of framebufferRenderbuffer to return an early > INVALID_OPERATION if an attempt is made to set up another attachment > (depth, stencil, depth+stencil) while any of the others is bound. The > reason is that we can not pass through the call to > glFramebufferRenderbuffer(EXT) immediately and there is no good point > to make the call lazily, so we can not simply return the status as > FRAMEBUFFER_INCOMPLETE_UNSUPPORTED from checkFramebufferStatus. > > If this sounds acceptable I'll write it up and send it out for review. Yes, please write it up and let's see how it feels. ----- ~Chris cmarrin...@ ----------------------------------------------------------- You are currently subscribe to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: From cal...@ Tue Mar 2 00:45:49 2010 From: cal...@ (Mark Callow) Date: Tue, 02 Mar 2010 17:45:49 +0900 Subject: [Public WebGL] A Declarative node set for WebGL? In-Reply-To: <099BBCC9-66B4-4490-B365-7C594AC1AADD@microcan.nl> References: <45774A4F67BB4C15BFAEA718C7E7BE2F@LenBullardPro> <099BBCC9-66B4-4490-B365-7C594AC1AADD@microcan.nl> Message-ID: <4B8CD03D.2090301@hicorp.co.jp> Most of the objections raised to Chris's proposal are based on the notion that it is a scene graph. The only part of the proposal that is graph-based is the Group element. All the other elements are declarative wrappers for OpenGL ES elements. You can set the transform part of the Group element to Identity and do whatever you want to position your objects. You can even ignore the Group element and write your own Javascript magic to create your favoured organization of the other elements. I don't think we should throw out the entire proposal because people's hackles are raised by a one element of it. Regards -Mark On 01/03/2010 18:54, Carl van Heezik wrote: > A declarative node set for WebGL is not a bad idea but it should NOT > be part of the WebGL spec. > > *From the Khronos website* > WebGL is a cross-platform, royalty-free web standard for a low-level > 3D graphics API based on OpenGL ES 2.0, > exposed through the HTML5 > Canvas element > as Document Object Model interfaces. > > Please define WebGL as a close to the hardware as possible. Keep the > WebGL specification lean so it can run on > devices with limited resources. There is a reason why different scene > graphs / graphics file formats exist. There is > simply no one fits all solution. People have different taste, some > like Red others Green or Blue. Even if the red coat > fits they prefer the blue coat because of their taste. > > Scene graphs will come and go and the some will survive because > everybody is using them. We have seen in the > past that just putting a label on it saying that its a standard > doesn't help. If its good it will be used if its bad it will > not survive. WebGL will be a success if it works well and is running > on millions of devices with appealing applications. > In my opinion this will be the case. (I am still a little worried > about the speed of javascript, smart use of the GPU will > probably help). > > Best regards, > Carl van Heezik > > > > Op 27 feb 2010, om 04:34 heeft Len Bullard het volgende geschreven: > > It's a namespace. The DOM can handle that. > > It really shouldn't matter what scene graph or encoding is layered on > top of > WebGL. It's the responsibility of the builder and author to use it > efficiently. > > IMO, HTML is exactly the venue to discover it. HTML isn't exactly a light > nugget itself but if namespaced-based integration using the DOM is the > basis > for blending the markup, then it has to work in HTML. > > What is more important to interacting with WebGL, HTML or the DOM? Is the > WebGL developers concept of the DOM defined by the infoset specification? > What limits does HTML place on the WebGL use of the DOM? > > As far as standardization goes, it goes according to the standards work. > Some last. Some don't. As long as it is doing a job for someone, it has > its own reason to be there. > > What Chris seems to be proposing if I understand this is a special set of > WebGL element types that are more closely bound to WebGL than any existing > scene graph markup or alternative. Where are there examples of the > element > types proposed? > > Thanks! > > len > > -----Original Message----- > From: owner-public_webgl...@ > > [mailto:owner-public_webgl...@] > On Behalf Of Thatcher Ulrich > Sent: Thursday, February 25, 2010 11:40 PM > To: Len Bullard > Cc: Chris Marrin; public webgl > Subject: Re: [Public WebGL] A Declarative node set for WebGL? > > > > My 2 cents: > > A 3d scene graph layered on top of WebGL (and/or other rendering > backends) in the form of a library: sure, the more the merrier -- > WebGL should try to be functional enough to make this work well. > > A 3d scene graph standardized into HTML: premature. Despite many > attempts over the decades, there does not exist a one-size-fits-all > scene graph that is small enough to be a good standard. Maybe someday > there will be, but HTML standardization is not the venue to discover > it. > > One thing I *would* like to see is a good way to reflect an HTML DOM > subtree into a WebGL texture. I think this would enable practically > all of the worthwhile use cases of DOM in 3D. If a dominant scene > graph library emerges out of that, then think about standardizing it. > > -T > > > > > ----------------------------------------------------------- > You are currently subscribe to public_webgl...@ > . > To unsubscribe, send an email to majordomo...@ > with > the following command in the body of your email: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: callow_mark.vcf Type: text/x-vcard Size: 398 bytes Desc: not available URL: From vla...@ Tue Mar 2 11:20:59 2010 From: vla...@ (Vladimir Vukicevic) Date: Tue, 02 Mar 2010 11:20:59 -0800 Subject: [Public WebGL] webgl canvas compositing into webpage. In-Reply-To: References: <4B833D1D.5050108@hicorp.co.jp> Message-ID: <4B8D651B.3020805@mozilla.com> On 2/23/2010 2:38 PM, Chris Marrin wrote: > On Feb 22, 2010, at 6:27 PM, Mark Callow wrote: > > >> CLAMP_TO_BORDER is not supported on OGL ES. Therefore WebGL needs to >> specified CLAMP_TO_EDGE or you won't be able to implement on top of true >> OpenGL ES. >> > > The spec doesn't require OpenGL, or even an OpenGL-like renderer be used to do page compositing. So GLES constraints are not the issue here. But I agree with Gregg that consistency is important. So maybe we should add some non-normative text that describes the desired behavior of a page compositor? > > Gregg can you come up with some words about that? Hmm, it doesn't seem like this belongs in the WebGL spec -- how compositing of the