John Wright wrote:
>
> 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.
I have no problems with this at all. That's why I run the j3d.org site.
I'm presonally happy to spend time answering these simple, general 3D
questions within the limits of my own time. What I am much more
concerned about is the detail of J3D specific things - Simple abstract
architecture. Then documentation on the particular implementation
things, like the Collision detection algorithms used etc.
> 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.
Statement of fact and surprise and to some extent digust from the
perspective of a professional software developer who takes pride in the
term "engineer". I come from a world where it is possible to write 100K
LoC program in 8 weeks for a tender, have it fully documented and then
go virtually unchanged into a live military environment (mission
critical) - that was just the Java portion, not including VRML, Lotus
Notes and SQL/OrclForms code. I think a smaller and simpler system like
J3D should be able to do the same over a 3 year time period. I believe
it is just plain laziness to do otherwise.
Having said that, it is a problem endemic to Sun's coding in general.
Have a look at the core JDK implementation. Image handling and
networking both suffer badly from this. Other teams within Sun are able
to do better jobs with similar staff numbers so I can't believe there is
any excuse for the J3D team to not do so.
Honestly, as someone who is coding up the collision handler for example
how long does it take to write up a one page summary of the algorithm as
they are writing the code. One hour, maybe two at the most. If each
developer did this, it takes no time at all. Self maintaining
documentation is easy and comes from the top down. If the lead developer
does not insist on it, then how is it going to happen in a general
sense?
> 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)
I agree. Documentation doesn't take long to do - 2 weeks most at max
with people that understand the code. That is not going to hamper
progress on new features. As soon as 1.2.1FCS is out, spend 2 weeks
doing some documentation then hit 1.3/1.4.
--
Justin Couch Author, Java Hacker
http://www.vlc.com.au/~justin/ Java 3D FAQ Maintainer
http://www.j3d.org/ J3D.org The Java 3D Community Site
-------------------------------------------------------------------
"Humanism is dead. Animals think, feel; so do machines now.
Neither man nor woman is the measure of all things. Every organism
processes data according to its domain, its environment; you, with
all your brains, would be useless in a mouse's universe..."
- Greg Bear, Slant
-------------------------------------------------------------------
===========================================================================
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".
