[
Lists Home |
Date Index |
Thread Index
]
----- Original Message -----
From: "Bullard, Claude L (Len)" <len.bullard@intergraph.com>
To: "'XML Developers List'" <xml-dev@lists.xml.org>
Sent: Wednesday, June 08, 2005 5:30 AM
Subject: RE: [xml-dev] Why XML for Messaging?
> If you dig through the original DTDs for what has
> now become X3D, you'll find the very first one
> was mostly just geometry because that made
> sense. It has my name on it. It started the
> process but was quickly tossed away.
>
ok, that makes sense.
I am arguing, not because I think it is actually useless, but I believe it
does have a number of problems.
but, what I still do feel is needed is, a well defined format for a well
defined task. not some big mass of "components", with no real distinction
between the structure and semantics of the data.
sorry again if I am missing the point...
> The problem was X3D had to be upwardly
> compatible with VRML97 and it was patterned on HTML.
> So they poured it all into one bucket because
> HTML was predicated on the notion of one
> neatly and possibly compressed file. Designs
> for games and designs for internet apps differed
> in that respect, at least in theory, because
> packets are cheaper than connections.
>
yes, however, it does seem like a bit of a mess imo.
ok, so, yes, games do end up with a very large number of very specialized
files. one could vary this, but, they could have at least kept a game-like
design internally?...
> Spilt milk. X3D works well enough for this
> pass. The critical thing is to keep the
> standards moving forward so that the technology
> does not get captured by private interests.
>
yes, ok.
I guess a bigger challenge for X3D is it's rarity/lack of app support? (a
quick skim shows that pretty much none of my apps seem to support it).
though, maybe it aims for something different though?...
if it's intended use is 3d windows in web browsers, then, yes, maybe a
single specialized set of tools for accessing it makes sense. however, the
whole "3d in a browser" thing does not make that much sense to me unless the
browser can be competitive with that of a game engine, or what could be done
with a special purpose tool for some other format.
maybe I am missing the point, but I am not clear if there is that much of a
point for it (at least for the time being). it does not seem to be well
posed as a "uniform format for application data interchange", and it does
not seem like a worthwhile format for simulating 3d worlds either.
all I can come up with is "format for users to look at 3d animated gizmos",
ok, not so compelling. 3d animated gizmos, maybe better than pictures, but
actually worth it?...
unifying 3d model formats seems like a good goal, eg, if I could export from
one app and load in another, with a common format, that would be quite
useful (vs, say, a large number of apps, each supporting a lot of formats,
but maybe only at most having 1 or 2 in common). I have read some about some
different efforts to face this problem.
shared 3d worlds, could be quite interesting, but then again, I would
personally imagine it being approached "differently".
actually, I once beat together a trivial 3d client for jabber/xmpp, which I
had felt could possibly be interesting. the problem then became the
bandwidth limits enforced by the servers. really, it was difficult to stay
below the limit. appart from this, it could have been interesting, but I had
personally lost interest (shortly after beating together the app).
"best" would probably be something resembling a game server, eg, with users
interacting with it through use of udp packets (or maybe tcp streams,
possibly worse, possibly better).
my attempt avoided a game server, but paid for it (eg: only being able to
send an update every few seconds to keep the server from noticing). I didn't
have any 3d worlds or anything, but could have. in my case, I was going over
multi-user chat, so the thing could have been, eg, having a client set up as
a "world bot", which would go about managing world related stuff, and
telling users what map is being used, ...
things like maps could reside on websites, and be pulled down as needed (a
simple idea would be bundling a lot of the related files, eg, in zips).
how would this relate to x3d? ideally, it shouldn't exactly, the format
should not care about this. of course, this kind of thing is necessary in
the definition of a shared 3d world.
now, for file formats, something "like x3d" could be cool, but, I don't feel
the design is up to it. more likely, I would rather adopt file formats from
the gaming industry...
> There are many rounds in social games that matter.
>
> BTW: XML is awkward for graphics in several
> ways. It's another 'suboptimum but ok' format.
>
ok.
xml, I don't think, is the main problem. I think the problem is more that of
an "ass-backwards" design (but, then again, I am not sure exactly what it is
trying to pull off).
note: I also dislike the 'X' model format, but, imo, it makes more sense...
'X' is a complicated format for a well defined task.
X3D is a complicated for a task I have yet to determine exactly.
the set of formats I end up using:
raw triangle meshes (many different uses);
ac3d, makes sense for static models;
smd, for skeletal models (characters, ...);
variations of the quake map format (in particular, valve 220).
any of these could probably be done well enough in xml, I don't doubt this.
just, by convention, these tend to be raw text formats. I don't feel xml is,
inheritly, a worse representation than plain text. just, efficiently parsing
it could be a little more work.
in particular, one important difference that comes to mind is memory use,
with a line-driven text format, one can get by using a small amount of
buffers, and only having a small part o the file in memory at once (the
parsed form quite possibly being the internal representation), wheras xml
would tend to produce large parse trees (eg: what is 10MB in line-driven
text could be 10-15MB in xml could, depending on the parser implementation,
take several hundred MB of heap to store the parse trees).
on this ground though, one can doubt the usefulness of xml for models, but
it can still be reasonable though (one thing that comes to mind is
intermixing the parsing and the processing to keep memory use low, rather
than attempting to parse the whole file at once).
as a plus, xml provides an abstract representation, where extensions can be
added without breaking existing processors (even if, for example, the app
does not recognize some data, it can be ignored and the model still used).
more so, I can imagine some possibly quite interesting advantages.
> len
>
>
> From: cr88192 [mailto:cr88192@hotmail.com]
>
> I have looked at X3D before, but had not been impressed in that it seems.
> it seems to have too much stuff embedded in itself, and tries to be too
> many
> different pieces at once (rather than a number of different formats and
> files, each representing a different piece).
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
>
>
|
