The going in assumtion is that backwards compatibility is preserved.
Doug Twilleager
Java 3D Team
Sun Microsystems
>Delivered-To: [EMAIL PROTECTED]
>MIME-Version: 1.0
>Subject: Re: [JAVA3D] Next generation java3d ?
>To: [EMAIL PROTECTED]
>
>Will any effort be made to maintain compatibility with applications
>developed with Java3d 1.3 and below? If not compatibility, then can we be
>assured that Sun is committed to the Scenegraph API in general and that the
>basic node hierarchy and node types will remain intact?
>
>-----Original Message-----
>From: Doug Twilleager [mailto:[EMAIL PROTECTED]]
>Sent: Monday, June 04, 2001 2:40 PM
>To: [EMAIL PROTECTED]
>Subject: Re: [JAVA3D] Next generation java3d ?
>
>
>The topic of how Java 3D 1.4 will evolve, and what it will eventually
>look like is not simple. Since Java 3D 1.4 is going though the major
>specification request process, the look of Java 3D 1.4 going into
>the expert group may not look the same once the expert group releases
>the specification into public review. In terms of extensibility, we
>are looking at supporting a number of the things you mention below.
>
>If you are at JavaOne this week, and you want more information on 1.4,
>come to the BOF on Wednesday evening. I will be presenting on the topic.
>Also make sure to come to the Java 3D 1.3 session on Wednesday afternoon.
>
>Doug Twilleager
>Java 3D Team
>Sun Microsystems
>
>
>>Delivered-To: [EMAIL PROTECTED]
>>X-Accept-Language: pl,en
>>MIME-Version: 1.0
>>Content-Transfer-Encoding: 7bit
>>Subject: [JAVA3D] Next generation java3d ?
>>To: [EMAIL PROTECTED]
>>
>>I'm wondering if there are any, even vague, ideas about how java3d 1.4
>>will look like. It targets extensibility, access to low level structures
>>etc. Things like vertex or pixel shaders are actually quite easy - I
>>worry about pluggable occlusion schemes, access to display lists etc.
>>
>>Would it be possible to expose lower level api and then implement
>>current java3d on top of it ? Possibly making some internals public,
>>like visibility system - allowing people to substitute single parts of
>>java3d engine with their own classes.
>>
>>At some point I was wondering if java3d retained mode was pure-java on
>>top of immediate mode. It is not true (especially performance wise), but
>>this would be kind of thing I now talk about - just with explicit
>>pluggable components for visibility system, material management,
>>collisions etc. Maybe making java3d internal message system public would
>>be a workable compromise ?
>>
>>How such things would affect performance ? Maybe nio.Buffers would help
>>a bit to cross java/native barier ? Especially for all these stencil/etc
>>stuff ?
>>
>>Artur
>>
>>===========================================================================
>>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".
===========================================================================
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".
