Shawn, ok I'll agree that it isn't Sun's job to educate us about real
time 3D in general. In a perfect world we'd all realize that
clipping/z-buffer is not a unique issue to Java 3D. In reality though I
think Java may be many people's first exposure to 3D (Java 3D makes it
easier to consider programming 3D than to consider learning OpenGL or
DirectX).
I'd be happy myself being given a reference to go check out (after all
Sun's engineers should be experts and they should be familiar with the
best references to point us to). Perhaps I chose a bad example, but I
see a lot of the "issues" being brought up as stemming from the fact
that the Java 3D demos contain little "real world" applications and once
you get beyond doing "Hello World" each developer will hit these
questions and issues.
It's like being lured into a calm, beautiful pool without warning that
there are sharks lurking under the water. We may be naive (and that is
our fault) but good customer service comes from addressing your
customer's needs not dismissing their problems as not your
responsibility.
Sun's engineers have been fantastically helpful in answering our
questions. I feel they'd be more effective though if they provided the
information up front so the questions weren't asked (repeatedly) in the
first place. j3d.org addresses some of this, but I feel a better place
would be in the tutorial and the API documentation (after all those of
us trying to maintain j3d.org are on the outside looking in).
I think we have over emphasized this discussion, but Justin's comments
like "Sun doesn't know what it's own code is doing" and "it's amazing it
works at all" were inflammatory. I don't think Justin was intending to
"flame" Sun (in fact he might have been complimenting Sun's Engineers in
his own outspoken, no holds barred manner). I think Justin was trying
to recommend to Sun the same thought that I feel - take a step back,
slow down, document and organize before proceeding with adding more
features. So I'll repeat my suggested priorities:
1) Bug Fixes (reliable code)
2) Documentation
3) Performance tuning & new features (low priority)
And again I'd like to compliment Sun's Java 3D engineers on providing
first rate customer service! Too many companies treat customers like
annoyances. Doug, Uma, Kelvin, Paul, Charmaine and company all give me
the impression that they really care about us.
- John Wright
Starfire Research
Shawn Kendall wrote:
>
> 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".
