pouët.net

Web GL

category: code [glöplog]
My idea with the MIME didn't really work, and for good reasons I believe :). I checked Ransom's code, very neat runs perfectly fine on FF 3.7.a1pre although I had to disable "script is unresponsive" thingy.
added on the 2009-12-17 08:02:08 by decipher decipher
@iq :
i didnt know San Angeles Observation use shaders for rendering his geometric shapes. (why not use basic polygons ? take less place when defining them with 3d formula ?). also why is there not source for this prod?
added on the 2009-12-23 00:09:48 by Tigrou Tigrou
Well, it's javascript, so I suppose a right click -> view source would be possible :)
added on the 2009-12-23 02:42:54 by stijn stijn
WebGL sucks, bring me the RealGL !

(still seeking for the universally agreed VM/bytecode spec. Java was/is nice but way too HL, IMHO. Garbage Collection my a§5) ;^)
added on the 2009-12-23 02:56:00 by xyz xyz
Tigrou, San Angeles Observation doen'st use any shaders at all. Its port to WebGL does, as you can't render without shaders in WebGL (there is no fixed function pipeline, finally).

As for the source, what stijn said...?
added on the 2009-12-23 05:44:43 by iq iq
so next one, how do we sync with audio in webgl? flash with liveconnect maybe? i don't suppose embed/object tags have getPlaybackPositionInMilliseconds()...
added on the 2009-12-23 08:51:21 by skrebbel skrebbel
@skrebbel, yep probably using flash or silverlight is the only way to get a proper control over the sound (and even being able to generate the sound on the fly), but not being able to package the whole thing in a tiny single html file is not going to facilitate WebGL adoption for intros....
added on the 2009-12-23 10:15:51 by xoofx xoofx
i don't think packaging matters much in this context. who cares about the size on the web - you can't even see what size things are. so at least i don't.

to me what matters much more is that you can click a link and watch a demo. no 250 megabytes streaming, no plugin installation, just the demo and that's it. i think that's going to be pretty cool.

and allow for awesome demotools.
added on the 2009-12-23 11:25:50 by skrebbel skrebbel
@skrebbel HTML5's audio object (which is supported by those browsers that support webGL) has a .currentTime attribute, but its resolution is in seconds, which I imagine isn't precise enough... might be worth sending a mail to the HTML5 mailing list about, I suppose there's a use case for more precise timing other than demos
added on the 2009-12-23 12:21:42 by stijn stijn
stjin: the weak type of the returned value might be a floating-point type hence supplying the necessary precision :). of course it won't be grand but it's still not integer.
added on the 2009-12-23 12:25:09 by decipher decipher
stijn and decipher made me run a little test, and in minefield, it seems to have pretty bad precision. here's the first second of an ogg in an audio tag, displayed with setInterval running at 1 millisecond (and the browser clearly not managing that speed, but ok):

Code: 0 0 0 0 0 0 0.2929999828338623 0.2929999828338623 0.2929999828338623 0.2929999828338623 0.2929999828338623 0.33899998664855957 0.33899998664855957 0.33899998664855957 0.33899998664855957 0.38599997758865356 0.38599997758865356 0.38599997758865356 0.38599997758865356 0.43199998140335083 0.43199998140335083 0.43199998140335083 0.43199998140335083 0.4699999988079071 0.4699999988079071 0.4699999988079071 0.4699999988079071 0.515999972820282 0.515999972820282 0.515999972820282 0.515999972820282 0.562999963760376 0.562999963760376 0.562999963760376 0.562999963760376 0.562999963760376 0.6089999675750732 0.6089999675750732 0.6089999675750732 0.6089999675750732 0.656000018119812 0.656000018119812 0.656000018119812 0.656000018119812 0.703000009059906 0.703000009059906 0.703000009059906 0.703000009059906 0.7559999823570251 0.7559999823570251 0.7559999823570251 0.7559999823570251 0.7559999823570251 0.8009999990463257 0.8009999990463257 0.8009999990463257 0.847000002861023 0.847000002861023 0.847000002861023 0.847000002861023 0.8939999938011169 0.8939999938011169 0.8939999938011169 0.8939999938011169 0.8939999938011169 0.9359999895095825 0.9359999895095825 0.9359999895095825 0.9819999933242798 0.9819999933242798 0.9819999933242798 0.9819999933242798


means in minefield, it's roughly 0.05s precision, aka 20hz, which is waay too little. too bad. i also wonder about the big gap in the beginning.

i guess the browser vendors would be the people to write, instead of the HTML5 folks, though. who knows someone at mozilla?
added on the 2009-12-23 13:11:05 by skrebbel skrebbel
for those who care, i uploaded the script to http://skrebbel.neuvostoliitto.nl/sync/. i'd be interested to hear how other browsers perform (i don't have those installed now). btw better wait a bit after opening the page so that the tune can buffer a bit.

tune is the excellent keith303 - she felt like, btw
added on the 2009-12-23 13:19:27 by skrebbel skrebbel
FWIW, I've had the same resolution issues with the Flash-based SoundManager 2. As far as I can see right now, the best answer is to forget about syncing and use (new Date).getTime() instead...
added on the 2009-12-23 13:19:28 by gasman gasman
gasman, to me, that means no demo in browser. first, you *want* to sync on audio (buffering, cpu full stuttering, whatever) and second i honestly kind of doubt the date getTime is much more precise.. is it?
added on the 2009-12-23 13:20:37 by skrebbel skrebbel
skrebbel: exact same output on Firefox 3.7a1pre (2009-12-22 build). This is not fun :/. Maybe one can write to Mozilla developer's maillist?
added on the 2009-12-23 13:26:47 by decipher decipher
getTime does seem to have millisecond precision - at least, when I used it on Antisocial it fixed the 'frame rate stuck at 10fps' issue.

Maybe the real answer is to use both of them, then - use date.getTime as the primary time source, but keep comparing against audio.currentTime and resync against that when it falls outside a certain tolerance. Ugh.
added on the 2009-12-23 13:30:26 by gasman gasman
skrebbel: http://pastebin.com/m6942085c

looks really weird, although maybe my minefield is doing more samples than yours?
added on the 2009-12-23 13:31:35 by jaw jaw
skrebbel, it's ok if you combine it with getTime and then linear-interpolate the diff you get to the next sampling point.

same issue with fmod.. time is not granular enough, so I did this and then a sanity check every 0.1 seconds to fix the synch.
added on the 2009-12-23 13:35:13 by jaw jaw
hmm. sounds hacky, but i see how it could work, yes :-)
let's hack that up at some point.

i still dislike it though - i reckon it might be good enough for simple scene switches at the next part of the music, but i have the idea that if you really want to heavily sync to the drum section of the soundtrack, and there is one sound-stutter or so, the sanity check may get back close to it, but not spot-on.

but hey, if they can do it with Date, they should be able to do it with the sound! right? :-)
added on the 2009-12-23 13:41:30 by skrebbel skrebbel
same reason is why you shouldnt use fmod btw :-D
added on the 2009-12-23 13:41:52 by skrebbel skrebbel
this is mainly an issue in the first second or so, then you can almost ignore it unless you have issues with sampling rate of the sound or something.. assuming that the time reporting from the sound file is correct of course :)
added on the 2009-12-23 14:09:32 by jaw jaw
Quote:
to me what matters much more is that you can click a link and watch a demo. no 250 megabytes streaming, no plugin installation, just the demo and that's it. i think that's going to be pretty cool.

... and next step would be to add a [shader][/shader] tag to pouet thus allowing to insert mini intro/demo in all bbs post, oneliner and... (why not) in avatars (as a small 16x16 intro)
added on the 2009-12-23 14:17:09 by Tigrou Tigrou
skrebbel: will you be making the javascript port of the GNU Rocket client-stub, then? :)
added on the 2009-12-23 14:57:37 by kusma kusma
if you port the network protocol to HTTP, sure!
added on the 2009-12-23 16:10:24 by skrebbel skrebbel
In ShaderToy I'm using HTTPRequest to download the preset descriptions in xml, and the shaders in txt. So sending http with text, xml or simply binary data is very easy in JavaScript, apparently :)

added on the 2009-12-23 20:09:51 by iq iq

login