Khronos News and BabylonJS Fame

[Wingnut]

https://www.khronos.org/news/press/khronos-finalizes-gltf-1.0-specification

 

A great announcement, and a couple of our local heroes getting quoted!  YAY!  Good stuff!

[dbawel]

I heard from Wikipedia on my return home from Thailand last week, and I expect the Wikipedia page for the Babylon.js framework to be approved within a week or two. We now have only 88 articles ahead of us before the review of the article I wrote.  We started with over 2000 articles ahead of us - so it appears we're real close.

 

Although it's still a huge struggle to publish the first article on any subject (in English especially) to Wikipedia, so I might have a couple revisions, but I should know if they request any revisions soon, and expect the pages to be officially posted in December for everyone on the net to read. I'll post a topic to let everyone know as soon as I hear from the review teams. 

 

Cross you're fingers, as this process has been more difficult than learning BJS.

 

 

By the way, Autodesk just announced their support and that they are writing new applications to natively run in HTML5 and WebGL.  My development partner was at the announcement last evening which was held at a node.js user forum in NY.  Although I believe they are first utilizing three.js (as they are ignorant to the power of BJS - in my opinion.)  But this is still great news as you can expect a HUGE growth in support of HTML5 and Javascript frameworks in the next year.  Which will be great for BabylonJS as well.

 

Here is the link to their presentaion slides:

https://prezi.com/xrosk3cq2mut/nyc-nodejs-meetup/?utm_campaign=share&utm_medium=copy

[Wingnut]

Thanks DB!  Good work on the wiki.  (and good to see you again, in general)

 

I would have gone to Thailand with you in the drop of a hat, you know? 

 

Anyway, it might behoove us to take a look at the webCL thing, too.  https://www.khronos.org/webcl/

 

THAT should make our physics engines speed-up quite a nice amount.  Yum!  

 

Anyone watch "Highway Thru Hell"?  It's about semi trucks who get in trouble on a snowy section of hilly highway in Canada, and the huge wreckers and folks who need to pull those trucks out of ditches or flip them upright.  And its about snow plowing and snow blowing and avalanches and and and... sigh.   Someday!  (After I can get a couple quadrillion physics-active "snow cubes" scattered everywhere so we have something to plow and get stuck-in.)    (drool)  Nearing fluid dynamics.

 

Anyone play SpinTires?  They got some pretty good mud in there.  How'd they do that? 

[RaananW]

There is no browser support for WebCL and no plans to support it by any major browser. 

personally, I find it rather sad. Would have been great...

[reddozen]

Nokia has a FireFox plugin for openCL support. May be worth someone poking around with it to see what kind of advnatages may be there... The larger babylon gets the more sway our projects will have to get the browser devs to impliment it natively... Just a thought. A lot of people thought webGL would go nowhere as "just another VRML" thing.

 

Edit:
Looks like AMD made a compilable version of Chrome with openCL support too.

[JCPalmer]

I have seen a demo of OpenCL driving OpenGL about 5 years ago.  As a demo, it was impressive for the time, but in a game API you can have a lot data going both ways (not just a mouse pointer as the demo did), creating great complexity for running animations at the same time.  New, external (to OpenCL) data will have to go in, kernels will have to run, then the cpu will have to pull out the data, update the new state of js objects, send data backup to gpu usual.

 

Also, you are not adding another gpu, just moving where the processing happens.  There will be competition for gpu memory, gpu time.  The javascript thread does not have to be idle while the kernel runs, but it may be dependent on the output, before it can really do anything.

 

OpenCL kernels are like OpenGL shaders.  They do not perform branching without great cost. Shaders or "Cuda cores" do not each have the ability to run their own instruction, program counters.  Each core in the work group runs the same instruction.  This can make it tough to write parallel code.  They are not the same as cpu cores, which do not all need to run the same instruction.  They are more like SIMD on steroids.

 

Not saying this cannot be done, but utilizing truly extra cpu cores might be just as good.  Sorry, for being the dick, but lunch is rarely free.

[gryff]

"and a couple of our local heroes getting quoted!"

 

Well a real blast from the past for me Wingy.

 

Two other names - Tony Parisi and Don Bruztman - bring back memories.

 

Parisi was one of the original developers of VRML back in the mid 90s. I believe he was the original creator of a VRML viewer - WorldView - which he sold to Microsoft. He followed that up with Flux and Flux Studio - which eventually became Vivaty that was designed to compete with Second Life. He sold that to Microsoft - again. (Maybe with BJS Microsoft will finally commit themselves to 3D on the web.  ). Last I heard about Parisi he had published a couple of books - one using 3JS.

 

Brutzman was a participant on a VRML mailing list I subscribed to, and was the driving force for VRML to develop into X3D. He was in the US military (Navy or Marines?) and they were using VRML to develop "capture the flag" games - I assume for virtual military teaching. There used to be lots of military 3D VRML models available on the internet.

 

 

cheers, gryff