On Wed, 4 Sep 2002, Zoran Krunic wrote: > Thanks! Does it mean that all of the elements in Scene Graph have to be > serializable ?
In order to move data between server and client via RMI, it must be Serializable. The Java3D scene graph classes are not Serializable, so VisAD uses its own Serializable substitute classes for selected Java3D classes. > ----- Original Message ----- > From: "Bill Hibbard" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, September 04, 2002 1:58 AM > Subject: Re: [JAVA3D] Client-server model of J3D > > > > There is something a bit like this in VisAD, for using clusters of > > processors as the server and a user's workstation as the client. > > Each processor in the cluster computes part of the scene graph and > > sends it to the client using VisAD's Serializable stand-ins for > > selected Java3D classes. On the client, these are converted to the > > Java3D classes and merged into a scene graph. This is all in the > > visad.cluster package of VisAD, available at: > > > > http://www.ssec.wisc.edu/~billh/visad.html > > > > Cheers, > > Bill Hibbard > > > > > > On Sat, 31 Aug 2002, Zoran Krunic wrote: > > > > > > > > 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". > =========================================================================== 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".
