Hello,
>John Richardson wrote:
>
>> VRML 97 is an ISO standard so it is open source.
>
>Bzzzt. Wrong answer. ISO != Open Source. In fact, most ISO standards are
>incredibly closed due to patent limitations (look at the MPEG spec for a
>classic example). Sure anyone can purchase a copy of an ISO spec, but
>you have to pay for the page count, which can be incredibly expensive
>(at last look the MPEG 4 v2 spec was just over 5000 pages).
>
Thanks for the corrections. Justin is one of the VRML guru's.
I listed a conclusion with very little logic in between.
So, I'll be philosophical instead. VRML 97 is some sort of standard and
it's philosophical foundation seems to be biased towards openness. There
are many commercial implementations with proprietary technology and many
Web3D technology extensions. However, there are also open source
implementations such as OpenVRML and the VRML97 Java3D loaders. There are
also some "pseudo Open Source" implementations such as Blaxxun's community
source and Cyber Kogenai (spelling) which has C++ and Java versions. There
is also a few UNIX/Linux efforts and also some Open Source authoring tools
(Meshworks, and Cyber Kogenai).
So I concluded that Standards facilitates Open source efforts by groups and
individuals but did not really convey my meaning and this led to hoof in
mouth syndrome.
Now, this is all relative since all major open source efforts are
multidisciplinary and may bump heads with proprietary issues or patent
issues. Obviously, as Justin pointed out, open source efforts can involve a
lot of pain , delay and workarounds for the designers and implementers of
open source software from standards. A standard may facilitate open source
efforts as a byproduct of the standards process. However, the standard may
be designed so that commercial implementations can be optimized and made
interoperable.
>> It is extensible which
>> means it can be incredibly complex and annoying due to browser
>> implementations of Java.
>
>Due to problems with the VRML Spec that have never really been sorted
>out.
I just singled out Java browsers because the original question related to
applets and the ability of generic users to view a web page.
Restart: Can be incredibly complex and annoying due to...
1) Browser implementations of Java.
2) Spec problems. I believe that this translates into browser
implementations of the spec, EAI and other recommended practices (GeoVRML,
h-anim, Universal Media...).
3) Interoperability issues between artists, 3-D modeling system's export
code and browser writers.
4) Java issues in general.... Java3D loaders in specific.
5) Enhancements designed to further competitors business models.
6) Differing goals of the general simulation community, the VRML content
community, scientific visualization community, tool manufacturers, business
people,...
7) Designers loading up too many behaviors.
8) through 12) <add your own reason here>
So, to answer again the original question.
I) Because of some of the comments above, the VRML world provider must test
the world in as many of the mainstream browsers as possible. The modeler
used to produce the world should be VRML friendly. The provider should also
design for the web if the world is reasonably complex with regard to
geometry. This may ultimately mean exporting to Shout3D or Cult3D or using
a polygon reduction tool. It may also mean "going easy" (this means
restricting to simple) on the behaviors. The VRML world producer should
also test the worlds in the open source viewers (Lookat,...) and Java3D
loaders so that we get better open source viewers.
II) VRML 97 and other format loaders. If VRML 97 is not as simple as you
like or if your geometry is in OBJ or LWO format there are the default
loaders from Sun. There seem to be other loaders for DXF, 3DS and some CAD
formats.
Note: Being a Java3D list I assume that this is a primary topic. So, the
viability of using Java3D is directly proportional to the viability and
correctness of the loaders. Not developing a Java3D app. That can be done
as easily (perhaps not wisely) as application development in any OO
language. You can then spend 2 years coding up "million polygon" shapes by
hand. It is better to just generate worlds in your favorite modeler and
smile as some Java3D loader class ingests the geometry.
Note: There may be other "viability issues" such as performance, scaling,
human computer interface, usability,... I just feel that Java3D is sterile
without content and that entertaining worlds will push the "loader
envelope" resulting in "Can't load world" errors.
Note: I can break the VRML 97 loader on legitimate wrl files that load in
Contact.....
Related answer to question
From: "Jonathan Albert C. Vallar" <[EMAIL PROTECTED]>
Try to get the examples from "3D User Interfaces with Java3D". The idea is
to encapsulate many of the housekeeping and loader functions. This is sort
of a more sophisticated "Simple Universe" that is in the Java3D utility
packages. The Author is Jon Barrilleaux.
Then get "The Annotated VRML 2.0 Reference Manual" which is in electronic
form to study VRML so you can understand the source for the loader.
John F. Richardson
>
>--
>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
>-------------------------------------------------------------------
===========================================================================
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".
