[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[x3d-public] Re: [www-vrml] Walking Kamala
>Joe D Williams wrote:
Dave A wished
Ultimately, I'd love to be able to code X3D the way I do javascript.
Namely, just 'include' (or 'import' whatever) the file, and be able to
access its contents at-will, just like javascript.
you can, all you gotta do is define the interfaces.
if you bring something into your runtime that you wish to interact
with, you must know the interfaces in advance.
Thus, you must declare them.
But when importint Javascript, I don't have to define anything. I like
that A LOT.
ex:
In a file called scene.html:
<SCRIPT SRC="Flux.js" language="JavaScript"></SCRIPT>
I can edit Flux.js to my heart's content, and I don't have to worry
about syncing declarations in scene.html (except where key interfaces
may change). I can just add functions to Flux.js and just use them in
scene.html (or any other such included external script). MAN is that
handy! I cannot do this with X3D (let alone the whole issue of one x3d
script 'knowing' about another, or any concept of 'global' variables or
functions, my God what I wouldn't give, but that's a whole other
discussion).
I understand for whatever security and propriety reasons the need to
'hide' content, and
Agan, this sounds great to get working for author time,
but for run-time, along this path lies madness.
Such a file would/could be 'imported' and just used as if it had been
there all along, just like javascript does. Wouldn't that be nice?
Except for the runtime 'export all' and its mate default 'import all'
I would say again, please speak to your boss. X3D has included
in the standard a definition of how to define the Inline interfaces
you wish to expose. That is EXPORT. Also, you get to match
these up with interfaces in the containing scene. That is IMPORT,
There are all sorts of things you can do with this. One thing you
cannot do is skip declaring the interfaces. Really, give the run-time
a break and do your programmer thing and list them interfaces.
As an programmer, I understand. But as an author, and one who'd like to
see much greater acceptance of X3D in the world, having to declare
things in two or more places is just plain unmanageable. I am currently
on my 3rd commercial site where such things get in the way all the time.
In each case, the desire is minimal to no need to know anything special
about X3D. They just want to export models (from Max or Maya or
whatever), and have them inserted into scenes. As it is, this means me
writing a server-side X3D parser for them, and maintain it. Time and
money. If they can't afford that, there is little recourse. Import would
help, but only if, again, there were no need for a third tool (server
side in my case) to manage syncing the interfaces.
As for giving the run-time a break: I'm inching ever more (and
cautiously) toward 'screw the run time' (I have friends that do runtime,
nothing personal), but the effort they are saving by not implementing
such conveniences reflects in HUGE amounts of time, especially when
added up across all the people who are working on things like this, or
would, if it weren't so labor-intensive. I see little benefit in using
X3D as a run-time format, other than it's an open standard, if I have to
do all the work myself. Instead of writing X3D tools, I might as well
dump out OpenGl. The runtime, IMHO, exists to make it easy to do 3D on
the web. Where if falls short, I make noise, but with love, like a
parent yelling at those damn kids to not play on the freeway.
Not to have to sync proto/externproto headers? To be able to get at
whatever you need/want from another file?
if you stay with XML, then you can do this at author time, and to a
certain extent from a live browser window.
Any examples handy?
>> Anywho, just as putting a loadsensor on an Inline does NOT tell you
when all of the Inline's contents are loaded (just the inline itself,
but wouldn't THAT be nice too!?), I would live with an extern/imported
file being able to be load-sensed, such that I could know when that's
'in'
Try this out. Figure out a way for the proto or inline or script to tell
you its
state before it is completely loaded and running.
I'm not asking for the incoming content (Inline, proto) to tell me
progress (I do this with externproto's firing of a 'loaded' event, which
is hacky, but hey). What I'm asking for is the BROWSER to tell me the
progress of the downloading of incoming externproto! In fact, Flux does
put this progress on the status bar, so I know the data is available. It
just needs to get to the scene and/or SAI API's somehow. Then I can make
a REAL progress bar. Data point: some of my extern protos have over
400,000 polys and are 2 megs in file size (gzipped). Not small. And I
may be loading several of them. I need better progress reporting!
I agree that anything with a url should be able to be load sensed.
What happens when you load sense the url for an inline?
If I have a url in an inline, and the inline is otherwise loaded
and running except for some textures, then I could export
a report from a loadsensor in the inline, or figure out what to
do in the inline and report something.
That is, if IMPORT/EXPORT is working.
However, since the proto or inline or script is completely able to
report its status when it is loaded and running, I may not use
loadsensing anyway. I may want a report from the logic itself,
not logic that is watching the url.
I'm sensing Inline loading just fine with Flux (although it would be
SUPER nice if it could automatically keep track of any other assets that
Inline might call, such as other Inlines or textures, sounds, etc. and
include that in it's percent complete). As it is, I have a hybrid
scheme, where I give 'percent downloaded' on Inines and 'unknown til
loaded' on ExternProtos.
Cheers
Dave A
Thanks and Best, Regards,
Joe
-------------------------------------------------------------------------
for list subscription/unsubscription,
go to http://www.web3d.org/cgi-bin/public_list_signup/lwgate/listsavail.html