You can try the exemple BINGO it is not too bad to undrestand the begining
or you can search for youbuildtVR.zip.

good work .....
-----Message d'origine-----
De : Andreas Jerke <[EMAIL PROTECTED]>
� : [EMAIL PROTECTED] <[EMAIL PROTECTED]>
Date : jeudi 5 septembre 2002 00:14
Objet : Re: [JAVA3D] Client-server model of J3D


>Hi Zoran,
>
>I think you don't want to write a tool which performs all rendering
>on the server side. I think you only need a server, which will notify
>all clients every time one client moves an object etc.
>The server side is simple, just a type of chat server.
>On the client side you need to create a socket. Your behavior
>will send a message over the net which contains object id and the new
>position (rotation, scale etc) every time the object changes.
>Every client has got its own SceneGraph, but this SceneGraph is always
>up to date with the SceneGraph of all other clients.
>Perhaps I could post some code snippets in 3-4 weeks.
>
>
>-----Original Message-----
>From: Discussion list for Java 3D API
>[mailto:[EMAIL PROTECTED]] On Behalf Of Zoran Krunic
>Sent: Samstag, 31. August 2002 23:19
>To: [EMAIL PROTECTED]
>Subject: [JAVA3D] Client-server model of J3D
>
>
>
>    Hi there!
>
>    I would like to know if there is any experience/documentation about
>splitting
>    the J3D application into the server and client-side. I would like to
>run the main
>    processing/scene-graph updating engine, that also includes the
>database
>    access, on the main WEB server, while only the rendering of the
>updated frames
>    is done at the client ( in the applet). Is there a way to do that ?
>Does it require
>    customizing the J3D source? This could also lead to multi-user
>sharing of the
>    same database, kind of like multiplayer game, although in this case
>it is not a
>    game, but rather database-related software. Currently (the raw
>prototype) of the
>    software does all of the scene updates in the behavior code,
>including the pick-related
>    actions. As those get more complicated, the frame rate would drop,
>unless done in the
>    background. There is no problem with waiting few frames for main
>action to post
>    the results on the screen, but the resources needed to do so may not
>be easily
>    available on the client. Also the amount of data coming from the
>database would stay
>    at the server side and update the scene there rather than travel
>across the WEB to the
>    client to update the frames. Finally shared viewing of the scene
>would be much easier
>    synchronized this way.
>
>    Thanks in advance for any help!
>
>    Zoran
>
>===========================================================================
>To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
>of the message "signoff JAVA3D-INTEREST".  For general help, send email to
>[EMAIL PROTECTED] and include in the body of the message "help".
>

===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff JAVA3D-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".

Reply via email to