I'm quite sure it's possible to make the browser handle the PLIO format,
and I would like to give it a try. Before I can start doing anything
related to that format, however, I need to do some simple experiments in
WebGL, as programming for WebGL looks a bit more complicated than the
OpenGL programming I've done till now. Fortunately, there are lots of
good tutorial stuff (and more) at <http://learningwebgl.com/blog/>.
On 05-04-11 15:49 , Alexander Burger wrote:
I thinks it depends on what you want the PicoLisp server to do, and
what you want the web client to do, and I don't know very much about
your z3dClient solution. Maybe it was a very "thin" client, leaving
most work to the server ...? My idea was to let the web client hold
Hmm, well. Yes and No.
The server does all the work of simulating the flight physics, and just
sends a position, a rotation matrix, and 3D-polygons (point data) of the
model structure (with sub-models relative to the parent model), like the
propeller, elevator, aileron and rudder. Each sub-model in turn has its
own rotation matrix.
The transmitted format is roughly described in "doc/model". It is used
for both clients (the standalone C-program "src/z3dClient.c", and the
applet in "java2/Z3dField.java" (now in a separate tarball
"picoJavaGUI.tgz")), and uses a subset of the PLIO format.
The server uses the 'z3d' shared object library (in "src/z3d.c") to
generate these data for both clients.
So the client gets only graphical data as polygons and colors, and is
supposed to build the scene from these. This is probably much easier in
OpenGL than in the current version, which explicitly implements a
Z-Buffer algorithm to calculate each pixel of the image.
the object models, and I thought I would start by getting the Fokker
plane up in the browser before I did any server/client communication
at all. That's why I was thinking of the JSON format. By "the
current S-EXPR format" I guess you mean the PicoLips code in
rcsim/fokker.l (and env.l) ...?
But then a converter from PLIO to JSON is needed, so I suspect that a
support only numbers (32-bit ints), and optionally a string, but no
lists. The current implementation simply skips that string (it was used
in another application for labels in the image).