Shawn,
I, and the rest of the Java 3D team, thank you for sticking up
for our interests.
As a large company, Sun is sensitive to engineers getting into
flame fights on public mail aliases. I am constantly reminding
my engineers to ignore criticism of their code and remain focused
on the product and customers.
We have even discussed creating a phony Yahoo account to allow
the team to freely vent.
On an unrelated note, I know Michael Schulman has commissioned
your company to develop a Siggraph demo. We are about to start
development of Java 3D 1.3 and performance enhancements are a big
part. The plan is to first implement our list of performance improvements
that we are already aware of, then focus on the Java 3D Siggraph
demos. We will probably be doing a special build of Java 3D 1.3 to
run in the booth at Siggraph.
Do you have a timeframe that your demo would be to the point that it
would make sense for my team to analyze it? The idea would be to
make suggestions to your team and to add performance improvements to
Java 3D to get the best demo at Siggraph. We would want the demo to
the point that most of your planned tuning was done.
Thanks again
Rob Posadas
Manager, 3d Graphics Software
Sun Microsystems
[EMAIL PROTECTED]
(650) 786-7873
>
> John's example expresses my earlier point exactly.
>
> Z-buffer resolution is not a Java3D issue.
>
> It is a Real-Time 3D graphics issue.
> It is true for D3D, OpenGL, Glide, console APIs and any other H/W
> accelerated 3D graphics system as well as any APIs that sit on H/W APIs
> like Java3D.
>
> Z-buffer, Z-sorting, Matrix operations, Scene Graph traversal, RT3D
> primitives (tris, strips), lights, Normal, etc.
>
> These are all the kinds of things we have to teach our student BEFORE
> they even start coding OpenGL, Direct3D or Java3D...
>
> The perception is that Java3D has these strange, unique issues. But it
> is RT3D that has them, not Java3D. And the Java3D team can not be
> expected to teach everyone concepts of RT3D. They can give references
> to help direct people, but that can come off as dodging the issue.
>
> Personally, I feel it is not the Java3D teams job to educate us about
> RT3D or Scene Graphs because both are well documented elsewhere. They
> need only to explain things that are truly unique to Java3D and continue
> building and improving the API.
>
> --
> ___________________________________________________________
>
> Shawn Kendall Full Sail Real World Education
> Course Director 3300 University BLVD
> Real Time 3D for Gaming Winter Park FL 32792
> [EMAIL PROTECTED] http://www.fullsail.com
> ___________________________________________________________
>
> John Wright wrote:
>
> > (setting a new more appropriate subject line)
> >
> > Excellent point Julian, perhaps Sun should document that Java 3D is
> > "young" so that newbies don't expect a mature product? (with mature
> > documentation)
> >
> > I'm not sure that's fair though to call Java 3D "young". Java 3D has
> > been around for about two years going on three now, correct? I skipped
> > Java 3D 1.1.x completely to give it time to mature. The performance and
> > abilities of Java 3D 1.2.1 don't seem "young" to me.
> >
> > More accurately I believe Java 3D should be described as "complex".
> > (Some of) The documentation problems could be blamed on the fact that
> > Java 3D is not easy to explain.
> >
> > It seems to me that more effort is needed in documenting fundamental
> > design decisions and concepts. As an example I'd take "Z-Buffer" -
> > Front/Back Clipping. Some of the Sun Engineers (Doug) have taken their
> > time to explain some of how this works (I've posted the detail of one of
> > these explanations on my website). Shouldn't a discussion of this be in
> > the tutorial? I'd like to see not just technical explanations of how
> > this works but also advice on how to work around the issues. A common
> > situation would be a virtual world in which the viewer should be able to
> > see objects up to at least 300 meters away, yet the front clipping
> > shouldn't be such that every time the viewer gets close to something
> > they see through it. I think several of us are creating such worlds.
> > And I believe we are goofing around with all kinds of "tricks" to avoid
> > the problems. Could we have an official list of "tricks" (techniques)
> > to deal with such issues?
> >
> > Personally I'm not "complaining" but I'd like to suggest more effort
> > (time) be spent on documentation rather than features. My priorities
> > would be:
> > 1) Reliable operation
> > 2) Documentation
> > 3) Performance and new features (very low priority for me)
> >
> > - John Wright
> > Starfire Research
> >
> > Julian Gomez wrote:
> >
> >> on 2/27/01 12:56, John Wright at [EMAIL PROTECTED] wrote:
> >>
> >>> forthright with you. It's not surprising though as Java 3D "feels" just
> >>> as you described... it's an aquired skill... you either bash your own
> >>> way through it or pray you have a more experienced person to help show
> >>> you the ropes.
> >>
> >> I would venture that all 3-D APIs, going back to E&S, have been through
this
> >> phase when they were still young.
> >> --
> >> Julian E Gomez, Ph.D. ** Java 3D New Technology Development
> >> Sun Microsystems, Inc. ** +1 650.786.2824
> >> former Principal Engineer, Apple Computer QuickDraw 3-D
> >>
> >> ===========================================================================
> >> 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".
