> 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).