This is a good example!
Yes it is true that z-buffering as a concept is the same throughout all 3d
hardware technologies and interfaces. But working with z-buffer in Java3d
is not the same as working with it in openGl. Indirectly it is the same,
but it is hard to apply your 3d graphics programming knowledge to a
scenegraph architecture. In raw opengl, you send commands to the card, and
you can do all sorts of trickery with stencil buffers, z-buffers, etc. You
can write out objects in the "background" at one clip, clear the zbuffer,
change the clip and render your "near" objects. These types of techniques
are used to get that nice 20km view in asheron's call. Its a little more
involved in java3d because its not so synchronous. You have to use ordered
groups, clip nodes, clip nodes with influencing bounds, rendering
attributes, etc. Its just a different way of doing things.
I agree its not necessary to teach 3d fundementals. Java3d is a scene graph
3d graphics API. If you know scenegraph architectures and you know opengl,
then you might find it easy picking up Java3d, but most people are missing
one of those two skills.
I can only point to the questions people come up with here. Yes there are
some very simple questions. But a lot are not what I call "ignorant"
questions. Its obvious most of the time that the person has spent a hundred
hours or more reading docs, trying the example programs and are now for the
first time attempting to do something "new". And they immediately hit a
wall. I wish I had a suggestion or a solution. But until someone does, it
looks to me that Java3d will continue to be used by the few people with the
right skills, knowledge and perseverence to master it.
Dave Yazel
-----Original Message-----
From: Shawn Kendall [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 28, 2001 11:53 AM
To: [EMAIL PROTECTED]
Subject: Re: [JAVA3D] Java 3D Impressions & Documentation
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".
