Justin and everyone,
I don't think the problem is restricted to applets, distributing
applications over the web is not very practical either.
Say, for instance, I have a shareware application, which I want people to
try via the web. If I were to use C++ or visual basic, I could create a
small executable which could be quickly downloaded and run by the potential
user. The reason the EXE can be small is that the libraries (mfc an vb DLLs)
have already been installed and loaded when windows was installed.
In contrast the Java2 JVM and Java3D are unlikely to have been installed on
most PCs.
Therefore Java and Java3D is only suitable for:
1) prototyping not intended for distribution.
2) High end programs that people will buy on CD ROM (not likely due to
performance issues).
3) You have such a killer application that people will put up with a long
download and installation procedure.
4) Internal company applications where you control the environment.
As I said, I really like the Java3D development environment, but one has to
be realistic about the limitations.
Martin
http://www.martinb.com
----- Original Message -----
From: Justin Couch <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: 11 November 1999 00:13
Subject: Re: [JAVA3D] Request for information
> Martin Baker wrote:
>
> > There does not seem to be a way to distribute applications to end users
unless
> > they are prepared to spend a lot of time downloading and installing
Java2 then
> > Java3D then the application.
> >
> > Better support from browsers might help (is IE likely to support Java3D
at some
> > date?). But what about big applications that need to read and write
local files?
> > I don't think most users would be prepared to do the big downloads and
installations
> > required just to try out a program.
>
> True, but I really think that focusing J3D for the applet environment is
> not really worthwhile pursuing. There are many reasons for this,
> probably the biggest is the download problem you mention here. Let me
> explain a little more:
>
> If you have a look at the current state of Java on the web - what do you
> see? Mainly banner ads or various ticker type applets. Apart from
> Shout3D (F@$*ing amazing piece of work that is!), very, very rarely do
> you see sites that use Java as the main core of their interactions. I
> more regularly run across Flash/Shockwave sites than I do Java. The
> biggest problem is the distribution. Not only do the current browsers
> implement JDK 1.1 very poorly, they haven't even begun to look at 1.2 -
> and we've almost got 1.3 delivered now. Quite simply, all the really
> good stuff will never be available because people have to go through all
> the troubles of downloading, installing and tweaking the Java Plugin,
> just to view a stock ticker. It is probably a chicken and egg situation,
> but I think everything fell over way back at the start of the 4.x series
> of the big two browsers. Failing to having an immediate JDK 1.2
> implementation for the users effectively killed the Java-in-an-applet
> market. Since then, anything to do with the applet market is just
> wishful thinking.
>
> Trying to establish J3D in this market place is just a waste of dollars
> that could be better spent elsewhere (like a few more programmers :). It
> will never take off unless there is some distortion of space/time that
> we weren't expecting.
>
> Now, why would one want to put 3D in a web page? In most of the markets
> that I've seen, it is principally for displaying an object (shop-front)
> or the seating position (think Ticketmaster style sites here). In both
> of these, it only uses a few very fundamental parts of the API. Sound,
> collision, generalised behaviours etc are for all intents and purposes
> useless. These sorts of application environments are much better off
> being fulfilled by Shockwave3D/VRML/X3D style APIs. Lighter, much more
> widely used (less pissing off of audience because they've probably
> already got a viewer installed) and simpler to author in.
>
> IMHO, the focusing of getting J3D to run nicely in a browser environment
> is not a battle that is worth fighting. I feel it is far better to
> conceed defeat here and focus on where it can make a difference - the
> desktop application level. Here, in combination with Swing, it has a
> real chance of actually doing anything worthwhile. We've done it, and
> generally speaking, the end result has been worthwhile. Regardless of
> what API/language you use, there will be bugs. Its just a matter of
> having enough reserve of experience to call on to help you out.
>
> I have quite a lot more thoughts on this, but I'm starting to drift
> off-topic now....
>
> > Also, 3D programs are quite heavy users of CPU power, and the JVM
interpretation
> > must hit performance, and with new microprocessors bringing out new
instructions
> > aimed at 3D, this gap is likely to increase.
>
> Yes, I've been rather concerned with this potential problem too.
> Although, because J3D makes calls to native implementations, it still
> should use those, assuming the native code is compiled to use it. More
> of concern to me is whether the internal architecture is built to handle
> all the advances in the consumer level video cards. Cards like Rage Fury
> MAXX can throw all sorts of your standard assumptions out the window.
> Rendering two frames interleaved between two graphics processors means
> you need a lot tighter syncing of the rendering loop code with the
> behavioural code. Right now, I'm not convinced that J3D is capable of
> handling these oddball approaches.
>
> > There is also a problem of the
> > program stopping at intervals due to garbage collection.
>
> Ah yes - major PITA. We really need a true realtime JVM capability to
> reduce this. Also, much greater attention to programming code will need
> to be taken too. This is as much a responsibility of the application
> programmer as it is of the J3D team _and_ the Java 2D/Swing folks.
>
> --
> Justin Couch Author, Java Hacker
> Snr Software Engineer [EMAIL PROTECTED]
> ADI Ltd, Systems Group http://www.vlc.com.au/~justin/
> Java3D FAQ: http://tintoy.ncsa.uiuc.edu/~srp/java3d/faq.html
> -------------------------------------------------------------------
> "Look through the lens, and the light breaks down into many lights.
> Turn it or move it, and a new set of arrangements appears... is it
> a single light or many lights, lights that one must know how to
> distinguish, recognise and appreciate? Is it one light with many
> frames or one frame for many lights?" -Subcomandante Marcos
> -------------------------------------------------------------------
>
===========================================================================
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".
