Andy,
Well, I'm not too surprised to hear that your Canvas3D approach didn't work
out... Though it was a valiant effort!
Java 3D appearances are properties of their parent Shape3D - and an
appearance can be shared between multiple Shape3Ds.
As far as I know, the GraphicsContext3D.setAppearance call is provided to
allow "immediate mode" rendering support in Java 3D. Shape3D's, when
rendering, will not call this method, so there will not be anything for you
to intercept or modify.
Forgetting all about Java 3D, how would you implement what you are trying to
do in OpenGL?
1. get a paint request from the window
2. see which drawing mode (wireframe etc) the window is in
3. set up the drawing mode using graphics API calls
4. execute display lists for scene
5. clean-up
This would all have to be synchronized as OpenGL gets pretty unhappy if
multi-threaded rendering calls are made, and a new paint request from
another window could come in while you where processing the original paint
request.
So, one approach would be to shift to immediate mode and essentially
replicate the steps above in Java 3D, instead of a window you are
essentially rendering into a View. You could always use mixed mode and use a
scenegraph for elements that were constant in all Views (maybe the axes or
something).
Alternatively, you need to store and synchronize different copies of your
data structures. This will be hard if your scene is very dynamic or very
large. Essentially treat your application as client/server (like a
multiplayer game) and say that View 1 is rendering in wireframe, View 2 is
rendering in Gouraud and View 3 is rendering in Flat shading... Except all
three Views are all on the same machine.
This is quite a lot of work, and could be overkill, but it will allow you
great flexibility in what you choose to display in each View. You could
implement LOD type behavior on a per-View basis (which is what Java 3D
should have done anyway), i.e. View 1 displays a Sphere will 32 faces, while
View 2 displays it with 32,000 faces.
Drawbacks are coding and synchronization overhead, and memory commitment.
Done right though, you could design it such that the different Views would
not *have* to be on a single machine, and you'd have a nice generalizable
distributed visualization framework...
I guess you get what you pay for!
Sincerely,
Daniel Selman
[EMAIL PROTECTED]
http://www.tornadolabs.com
-----Original Message-----
From: Discussion list for Java 3D API
[mailto:[EMAIL PROTECTED]]On Behalf Of Andy Wilkinson
Sent: 14 December 1999 06:55
To: [EMAIL PROTECTED]
Subject: [JAVA3D] Customising Canvas3D - part 2
Folks,
Sorry, but i should have read the JavaDoc more carefully - the
getGraphicsContext3D() method on Canvas3D is final so my original plan
definitely won't work as far as I can tell.
I'd still be very greatful for any suggestions of how else it might be
achieved.
One thought that occurs to me is that it was mentioned on this list that
Java3D 1.2 would see a lot of the final methods being made non-final, can
anyone tell me if this is the case with the current beta/alpha release and
if it involves the methods I am interested in.
Thanks again,
Andy
===========================================================================
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".
