Hello Koen,
On 2:59 PM, Koen Deforche wrote:
> Hey Diego,
>
> 2010/3/18 Diego Cantor-Rivera <[email protected]>:
>
>> Hello Koen,
>>
>> As Daniel also suggested, I think it is worth to explore API's like
>> SceneJS (www.scenejs.org) and GLGE (www.glge.org) which work on top of
>> WebGL. Otherwise, programming is just tedious.
>>
> Definitely, although this is an implementation concern. I am more
> worried about defining a good interface that allows enough flexibility
> for the future and can be rendered efficiently (caching as much as
> possible JavaScript for particular objects at the client).
>
Agreed.
>
>> I agree that exploring the scene interactively should be local to the
>> client-side. However there should be a method to "push" new information
>> into the scene as result of a server-side process. For instance if you
>> are in a game and a new player enters the game you should be able to
>> "see" it. (makes sense?)
>>
>> I think this kind of live update could be done with ajax(?)
>>
> For sure, we would integrate this just as any other widget, allowing
> it to be updated (using AJAX).
>
Cool.
> Some of the scenarios I would like to enable:
> - moving around the scene using a server-side API; should not require
> resending the scene.
>
Would this be equivalent to move the camera with server-side commands?
> - moving around the scene using client-side changes (this will be
> something special)
>
This is given in WebGL as long as there aren't new objects coming into
the scene (server updates)
> - animation: defining a JavaScript function that allows animation;
>
This should be also sraight forward. For instance you could interpolate
camera locations and create a spline (very much like in Blender). Again,
with the client-side API.
> - modifying the scene by adding/removing or moving around objects;
> should not require resending the entire scene, only the changes
>
Agreed. This is "Second Life" style.
> This is why I would like an approach where we have an object-model
> server-side although WebGL does not have that. And objects should then
> map to JavaScript functions that represent the object.
>
You are right. WebGL is procedural. GLGE is object based
(http://www.glge.org/api-docs/?url=/symbols/GLGE.Mesh.html&url=/index.html)
. These objects could be mapped to C++ objects or encapsulated depending
on the level of granularity that you want to give to the API.
> All in all, I think this is really an exciting addition, and I hope
> WebGL will find good adoption across browsers (although it looks like
> IE9 is already not going to support it ... and even worse, MS is
> expressing strong views against it for some reason). At least, I hope
> that MS will provide an alternative (perhaps based on DirectX) that we
> could then target for IE browsers.
>
No wonder, Microsoft never abides to standards that are not proposed by
them.
> Regards,
> koen
>
>
>
Also, what would be a good starting point to start playing with WebGL in
Wt? Maybe the JavascriptExample project? or maybe the PaintExample?
I am thinking of something very quick to implement just to have a proof
of concept. From there I will move onto architectural details.
Cheers,
Diego
--
Diego Cantor-Rivera
Ph.D.Student in Biomedical Engineering, University of Western Ontario
Imaging Research Laboratories, Robarts Research Institute
P.O. Box 5015, 100 Perth Drive, London, ON, Canada N6A 5K8
email: dcantor <at>imaging.robarts.ca
Visit me at: http://bit.ly/dcantor/ <http://bit.ly/dcantor>
------------------------------------------------------------------------------
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
_______________________________________________
witty-interest mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/witty-interest
