Alex Bowden wrote:
> What I meant by truncated was that if I asked CVS for version 1.1 then I got
> it but if I asked for version 1.0 (as very specifically stated by
> Alan/Giles) I was told that there was no such version.
There are different "1.0" versions. CVS does not have a concept of 1.0.
When a new file is checked in it always has the Revision number of 1.1,
so if you were looking explicitly for a file with version of "1.0" you
won't find it. The other "1.0" is what might be considered Xj3D Version
1.0, which is the Sun loader code. If you consider our work as Version
2.0, then Sun's loader, which has a continuous heritage from the first
code, to what is known as Xj3D today, would be considered 1.0. The Tag
that Alan mentions is the last known good tag where Sun's code remained
intact, with none of the Version 2.0 (ie XML) work attached to it. Past
that release, and up to the tag known as VERSION-2-0-M2, Sun's code was
still part of the current tree in the repository. It had been modified
somewhat from the VRML97.jar in that we tried to hack it to get to work
with the requirements of the X3D spec, but AFAIK, Sun never took the
option of using that code within their VRML97.jar that comes with the
J3DFly program. In fact, I have no idea which version of the code from
CVS they actually use and it may not even be derived from the CVS version.
What you are looking for, might not be what you are actually getting. Be
careful for what you ask for, because you might receive it.
> In fact (thank to Georg Rehfeld [[EMAIL PROTECTED]]) I have now
> downloaded the "Initial" version. ("cvs checkout -P -r Initial x3d" for
> anyone else that wants it) which is what I believe Alan/Giles intended.
It isn't. That Initial tag is the code that was first checked into the
CVS repository. It has none of the bug fixes and none of the
improvements that were later made to the code either by the Sun
employees, who had write access to CVS at the time (before even Alan or
I did) or by some of our later improvements. That code would be circa
1997 or 98 - definitely not what is available in J3DFly.
> I have combed the back archives trying to find any link that will get me the
> source of the old code. It becomes clear in doing so consistent resistance
> to help anyone find the old code. Even quite direct questions where the
> questioner makes it clear that he wants the old Sun loader code get pushed
> toward the XJ3D version as being a replacement.
Correct. We have no desire to support someone using old code that hasn't
been maintained for 12 months or more. If someone asks a question about
bugs in it or whatever, we will ignore it, or suggest that they use the
latest version of the code. You see the Sun engineers doing the same
with Java3D. Don't use the old code, use the current code because that
is the latest and greatest and has all the bug fixes in it - even if it
is a beta.
> This CLEARLY gives the impression that the XJ3D loader makes the Sun VRML97
> loader redundant even for someone who had explicity indicated that the old
> Sun loader did what they need.
That is a true statement. The old loader is redundant and has been
replaced by a newer system. We as maintainers of that code wish to only
support the newer version and so direct the person to use the new code
so that they can get support.
> Can I hope that, in view of recent statements that the XJ3D loader is
> unlikely to get within a factor of 3 of the speed of the old Sun VRML97
> loader, that this practice may change?
No. We will only push the latest version of the Xj3D code. That is the
only way we can get feedback on what needs to be fixed. We have no
desire and no intention to support old code, that is, as of today,
currently a dead project. If someone else wants to recommend their VRML
loader, they are free to voice their opinion on the list the same as
what we do. Considering the poor to non-existent state of documentation,
and the lack of functionality of the old code, we feel it is a diservice
to recommend to someone crap code.
> However, I take the last comment about carrying a URL as a positive step.
> Just a shame it wasn't done in the first place :^)
Since when? That has always been the policy of j3d.org. It doesn't care
who or where or why. If there is a link to a product, we'll put it
there. I see no need to keep restating that point in every email on
every post about a VRML loader.
> Of course you, as a person, have the right to create and push any product
> you want.
> But you and Alan/Giles act in roles like Web3D chair and J3D FAQ maintainer.
> Its great that someone does these things, but it also gives you a bit of a
> responsibility not to use those roles to push your personal hobby horse to
> the detriment of a community who generally will accept people in those roles
> as being even handed.
But you fail to understand what those roles are. Alan is the chair of
the Open Source group at the Web3D consortium. One of those projects is
Xj3D. His job is to promote Web3D consortium open source projects, not
to promote all projects. It is not his role to promote NCSA's loader,
nor Satoshi's loader. Xj3D is an official project of the consortium, and
therefore he is doing his job correctly by promoting the latest version
of the official project and trying to keep everyone up to date. Xj3D is
written and maintained by more than just Alan and myself. There are at
least 5 people who have write access to that CVS repository. FWIW,
j3d.org's codebase has 6 people with the same access.
Now, as for myself, what else am I do? This is a project and it is the
best VRML toolkit out there. If someone wants old code, my
responsibility is to point them to something that works. If someone asks
about "where can I get a VRML loader" what should I do? Should I just
shut up and say nothing, which is what it seems you want me to do? Not
bloody likely. This is one project that I work on and I am going to
promote it. Like all the other coders out there, I want more people to
use my code so why shouldn't I promote it? As a civic responsibility, I
should also be trying to steer them away from old, unmaintained code and
towards something that is more modern and well supported. If I point
them to old code, they'll curse me for pointing them to crap, but if I
point them to current code, I get accused of not being fair? I can't win.
> If the chair of Web3D and the J3D FAQ compiler tell me the same about XJ3D v
> VRML97.jar I would like to be able to take it on faith as being the case.
There are two things there and it really depends on what the user asks
in the first place. If they say "where can I find the source for the Sun
loader?" we answer with "it's not available that we know of" - which it
isn't. As someone with access to the CVS repository, I have no clue
about what Sun's loader is or where it came from. For all we know they
dumped the code to the Web3D consortium and then did their own internal
development that forked from what we have in the public repository. In
fact, I can almost guarantee that to be the case. Read carefully the
wording of the people that post this question to the list. They always
ask for the source to the VRML97.jar that comes with J3DFly. We are
providing a correct answer. If the user asks for "where can I find a
VRML loader" we point to the loader page and then recommend they use
Xj3D. Again, nothing wrong or incorrect in that answer either, so
where's the problem?
The other part you miss is that we are directly promoting the code. At
no time are we saying "use this code because Yumetech maintains it and
wants to make money off it". The is no commercial bias, despite the fact
that our company does offer a commercial support contract for the
codebase. I can't see how much more fair we can be.
To be honest, I'm not that interested in X3D/VRML anymore. I write and
extend Xj3D because I'm paid to do so. The j3d.org code, OTOH, I write
and extend because I enjoy doing so and would do it if nobody paid me to
do so. I promote Xj3D because it is the best product to fulfill the
majority of the needs. If you read the j3d FAQ, nowhere does it express
any bias toward any loader. In fact, I leave a lot of stuff out, just
avoid accusations of being biased (for example there should be a FAQ
entry for "Where can I find the VRML97.jar source?"). I can't win either
way, so bugger it, I'm going to take a position that satisfies my
personal interests first.
> Its slow every time. I'm using an API that contains a class VRML97Loader
> with an API method load(URL). I have not had or delved into the source to
> track performance below the API level. However...
>
> I have one file that takes 8 seconds in XJ3D and 2 seconds in Sun loader.
> I have one file that takes 1 minute in XJ3D and about 15 seconds in Sun
Ok, Good. Now we have something to work with. Is this the final M4
release and not one of the test versions? If so, is your geometry mainly
composed of IndexedFaceSets? If yes again, can you check what is
happening with the memory usage? Somehow, between one of the test
releases and the final release, something in the IFS code went out the
window and it starts consuming massive amounts of memory. That's a known
bug and will be the first thing Alan attends to when he gets back from
his honeymoon in a couple of weeks.
> I haven't changed any in either loader (it defaults to slow?)
Yes, I believe that is the case.
--
Justin Couch http://www.vlc.com.au/~justin/
Java Architect & Bit Twiddler http://www.yumetech.com/
Author, Java 3D FAQ Maintainer http://www.j3d.org/
-------------------------------------------------------------------
"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".
