[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). 

what is in the ,js file for the html? (language="JavaScript"is not used,
try text/javascript for html)
if you reference nodes, by name, then you will need to keep track.
Of course you won't need to declare variables if everything is global.
And who is confused about when scripts should be able to talk
to each other?
However, except for the things that are different, it is the same.

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! 

As t should be for simple stuff.

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). 

if you can handle javascript for DOM, then you can handle
ecmascript for SAI.


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. 

Two or more? Sorry, the answer is zero to as many as necessary.
Really, if you are having a problem in keeping track of this
kind of stuff, then you must change the way you do it for your
customer's sake. Try drawing pictures with blocks and lines
and some sort of annotation showing event flows.
Show an example that really causes you a problem.
Get some consistency in the basic input, maybe.

I am currently on my 3rd commercial site 

care to show any links?

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. 

or html or flash, or any authoring, probably ... ...

They just want to export models (from Max or Maya or whatever), and have them inserted into scenes. 

Historically, these may be complex models but they should work.
Usually, they can be greatly editied for web use.
Probably many simpifying features of X3D are not used.
In 90% of these cases you can improve the things a lot if
you can read the code and use a text editor.

As it is, this means me writing a server-side X3D parser for them, and maintain it. 

What does that have to do with you problem? It does not
seem to me to be a great idea to generate externprotos
on the fly from the server. .

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. 

I'm still not sure how this would be any different in your html
example. If the node you import does not have the same interface
names as the node it is replacing it with, then you will need to
change your containing scene 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. 

Sorry, I'm missing you naming some sort of alternative tool that will
give you the conveniences you seek.

Instead of writing X3D tools, I might as well dump out OpenGl. 

Sorry, I'm missing how this will solve your problem.
Where will you dump it to and what tool will work with it?
For instance, there is no load sensor in ogl.

The runtime, IMHO, exists to make it easy to do 3D on the web. 

Yes. As easy as is possible.

Where if falls short, I make noise, but with love, like a parent yelling at those damn kids to not play on the freeway. 

Maybe check your browser of choice to make sure it is
working as expected. Somtimes a simple bug, like a missing
interface, makes it harder than it should be.


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? 

When i said that i was thinking of client-side script and xml
transformation and processing tools,


>> 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!?), 

You must sense the state where it can be sensed.

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). 

Deep down, what other choice is there?
If you had another choice, why would you use it?

What I'm asking for is the BROWSER to tell me the progress of the downloading of incoming externproto! 

how can the browser know if the proto doesn't know?

In fact, Flux does put this progress on the status bar, so I know the data is available. 

Please consult with the manufacturer concerning the actual
meaning of the built-in status/progress bar.
Google may be your friend on this because percent loaded is
requested for everything. How do classA html browsers do it?

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!


Again, most all of those can be improved using some tools for X3D
and a text editor. Getting consistent input that fits into your scene
in a consistent way may be the best choice

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. 

How is it that you are able to achieve percent loaded on inlines
but not for protos? I can understand some special cases, but
not the general case. How are the probems different?
How can you keep detailed track of things in the 'might call'
category any better in the Browser than in the inline or proto.
if this is important, you build reporting into the inline or proto
and tell it to the containing scene as soon as you can.


Cheers
Dave A


Thanks and Best, Regards,
Joe


Anyway, it sounds like two big issues, both very common in
content creation and publishing. Now you know the problems
and understand what the browser can or at least is supposed to
do, maybe you can make some headway and maybe even
formulate a comment against the standard.

Best Regards,
Joe 

-------------------------------------------------------------------------
for list subscription/unsubscription,
go to http://www.web3d.org/cgi-bin/public_list_signup/lwgate/listsavail.html