instantreality forum
news: Welcome to the instantreality forums!
 
*
Welcome, Guest. Please login or register.
Did you miss your activation email?
April 25, 2018, 07:43:00 am


Login with username, password and session length


Pages: [1] 2
  Print  
Author Topic: Instantplayer crashes when creating splines geometry  (Read 12115 times)
Snoopy
Newbie
*
Posts: 17


View Profile
« on: November 04, 2008, 10:51:49 am »

I found a VRML scene on the net  that contains a bunch of javascripts which are supposed to create some B-Splines geometry, which one could change at runtime.

However, instantplayer crashes at startup.

Does anyone have an idea?

For your reference, you can find the scene at http://zach.in.tu-clausthal.de/tmp/splines.zip

I will appreciate all hints, suggestions, tips, etc.

Best regards,
Gabriel.

PS:
Am using instantplayer 2.0.0 beta 5 under Mac OS X.

Logged
pdaehne
Administrator
Sr. Member
*****
Posts: 250


View Profile
« Reply #1 on: November 04, 2008, 07:10:45 pm »

Hello Gabriel,

in your zip file there are at least two VRML files containing external PROTOs missing:

  • Table.wrl
  • TableButtons.wrl

That's probably the reason why the player is crashing.

Bye,

Patrick
Logged
Snoopy
Newbie
*
Posts: 17


View Profile
« Reply #2 on: November 04, 2008, 08:31:51 pm »

Vielen dank fuer die schnelle antwort.

Es stimmt, die WRL's haben wirklich gefehlt.
Habe diese nun nachgeladen.

Leider crasht es immer noch ...

Ich habe das neue Archiv wieder an dieselbe stelle gelegt:
  http://zach.in.tu-clausthal.de/tmp/splines.zip

In dem archiv befindet sich jetzt auch ein file 0Source.txt, der die URL der quelle enthaelt.

Vielen Dank im voraus.

Herzliche Grüße,
Gabriel.

Logged
pdaehne
Administrator
Sr. Member
*****
Posts: 250


View Profile
« Reply #3 on: November 06, 2008, 12:03:07 pm »

Hello Gabriel,

the reason why InstantPlayer does not play the VRML files is mixture of bugs both in the VRML files and the player.

I've fixed most bugs in the player yesterday. Please download the latest dailybuild (build nr >= b10781) from the following URL:

http://ftp://ftp.igd.fhg.de/outgoing/irbuild/

I've also fixed most of the bugs in the VRML files. The fixed version is attached to this post. The original version just worked on Bitmanagement Contact (as the original author of these files also mentiones on his web site).

  • Contact seems not to care for uppercase/lowercase. We (and the VRML standard) do. So I had to fix the case of some names and keywords.
  • The VRML standard forbids (for good reasons) to send more than one event per frame per event-out slot. Contact allows that. To fix that, I've had to change some scripts.
  • The VRML standard does not allow exposed fields in script interfaces. Contact nevertheless supports them. I've replaced exposed fields by a combination of event-in slots, event-out slots and fields.
  • The VRML standard does not allow to change the indices of geometries. The scene nevertheless does that. Both Contact and InstantPlayer support changing the indices, so I did not change that. But be aware that the version attached to this post still is not VRML-compliant and won't work on other VRML browsers. I do not have the time to fix that bug.
  • One of the scripts had a reference in a field to itself:

    DEF KNOTSCRIPT Script {
      field SFNode THIS USE KNOTSCRIPT #this script

    Due to a known bug in InstantPlayer this will crash. In InstantPlayer, you can use the Javascript "this" object instead. Unfortunately, "this" does not exist in many other VRML players.
  • There is a bug in the PlaneSensor implementation of InstantPlayer. You can see that when you try to move the violet slider on the right side of the table. I did not fix that, I'll open a ticket in our bug tracking system.

Bye,

Patrick
Logged
Snoopy
Newbie
*
Posts: 17


View Profile
« Reply #4 on: November 06, 2008, 04:21:35 pm »

WOW! Super!! Riesiges dankeschoen!!

Just a few question for my better understanding:

- is 'exposedField' deprecated?
  I noticed that you replaced many (all?) exposedField's by 'field' + 'eventIn' ...

- I noticed that you moved a lot of createVrmlFromString()'s out of the loop in room.js
  Was there a bug with that? or was it just for elegance or performance?

- Is there a difference between 'isOver' and "isOver", i.e., quotes vs. double-quotes?

- The keyword "IS" needs to be in all upper case? or is that just for better human legibility?



Again, thanks a million!!!!

Best regards,
Gabriel.

Logged
pdaehne
Administrator
Sr. Member
*****
Posts: 250


View Profile
« Reply #5 on: November 06, 2008, 08:18:26 pm »

Quote
WOW! Super!! Riesiges dankeschoen!!

Thanks for an interesting VRML world Smiley

Quote
- is 'exposedField' deprecated?
  I noticed that you replaced many (all?) exposedField's by 'field' + 'eventIn' ...

No, it's not deprecated. You're simply not allowed to use them in VRML Script interfaces. You're allowed to use them in the newer X3D standard, but we do not support them yet because the X3D specification is broken at that point.

Quote
- I noticed that you moved a lot of createVrmlFromString()'s out of the loop in room.js
  Was there a bug with that? or was it just for elegance or performance?

The bug was that you're only allowed to send an event once per frame per event-out slot. In this case, the event-out slot is "newChildren", and I had to make sure the scene fires on that out slot just once.

Quote
- Is there a difference between 'isOver' and "isOver", i.e., quotes vs. double-quotes?

There shouldn't be a difference, but when I tested the scene on the Octaga browser I realized that that browser doesn't support double quotes.

Quote
- The keyword "IS" needs to be in all upper case? or is that just for better human legibility?

It has to be upper case.
« Last Edit: November 07, 2008, 12:15:50 pm by pdaehne » Logged
Snoopy
Newbie
*
Posts: 17


View Profile
« Reply #6 on: November 07, 2008, 12:16:05 am »

>> is 'exposedField' deprecated?
>>  I noticed that you replaced many (all?) exposedField's by 'field' + 'eventIn' ...

> No, it's not deprecated. You're simply not allowed to use them in VRML Script interfaces. > You're allowed to use them in the newer X3D standard, but we do not support them yet > because the X3D specification is broken at that point.

I'd like to learn more about that:
1. In which way is the X3D standard broken at this point?

2. Will the standard ever change that?

3. What if it doesn't? will you then implement the broken definition?


> The bug was that you're only allowed to send an event once per frame per event-out slot.

Is that in the standard?


> Octaga

that player looks nice, too, but it seems to me that the unregistered version does not handle mouse sensors, i.e., I can't interact with the scene -- is that correct?


Best regards,
Gabriel.

Logged
Snoopy
Newbie
*
Posts: 17


View Profile
« Reply #7 on: November 07, 2008, 12:44:36 am »

PS:

>> Octaga

> that player looks nice, too,

don't worry, we won't go astray ;-)

Regards,
Gabriel.

Logged
Snoopy
Newbie
*
Posts: 17


View Profile
« Reply #8 on: November 07, 2008, 01:14:44 am »

BTW:

Auf http://www.octaga.com/joomla/index.php?option=com_content&task=view&id=67&Itemid=114

gibt es bei Octaga ein paar nette szenen -- leider funktionieren sie alle nicht mit InstantPlayer  (bei vielen crasht er).

(Ich koennte sie Dir alle zukommen lassen, dann sparst Du Dir die muehe mit dem downloaden und auspacken.)

Gruss,
Gabriel.

Logged
pdaehne
Administrator
Sr. Member
*****
Posts: 250


View Profile
« Reply #9 on: November 07, 2008, 12:13:09 pm »

Quote
>> is 'exposedField' deprecated?
>>  I noticed that you replaced many (all?) exposedField's by 'field' + 'eventIn' ...

> No, it's not deprecated. You're simply not allowed to use them in VRML Script interfaces. > You're allowed to use them in the newer X3D standard, but we do not support them yet > because the X3D specification is broken at that point.

I'd like to learn more about that:
1. In which way is the X3D standard broken at this point?

2. Will the standard ever change that?

3. What if it doesn't? will you then implement the broken definition?

1. The standard says:

When there is an exposed field "foo", whenever an event is received on "foo", the browser will call a Javascript function "foo". Inside the Javascript code, there is also a variable called "foo". You can read the current value of the "foo" exposed field by reading that "foo" Javascript variable, and you can send new values via the "foo" exposed field by writing these values into the "foo" Javascript variable.

The problem with that spec is that in Javascript functions and variables share the same namespace. So there cannot be a function "foo" and a variable "foo" at the same time. That becomes clear when you replace the usual way to define a function in Javascript:

Code:
function foo(value, timestamp)
{
  // ...
}

by another variant that is valid (and equivalant) Javascript syntax, too:

Code:
var foo = function(value, timestamp)
{
  // ...
}

Even though the spec is broken, some browsers (e.g. Contact) nevertheless allow to use exposed fields in Script interfaces. The reason simply is that these browsers do not really implement standard Javascript.

2. Hopefully the standard will change. We are member of the Web3D consortium that develops the X3D standard, and we've started a discussion about that topic in the consortium.

3. We won't implement the broken definition.

Quote
> The bug was that you're only allowed to send an event once per frame per event-out slot.

Is that in the standard?

Yes. See section 4.10.3 of the VRML spec:

Quote
Nodes that contain eventOuts or exposedFields shall produce at most one event per timestamp. If a field is connected to another field via a ROUTE, an implementation shall send only one event per ROUTE per timestamp. This also applies to scripts...

Quote
> Octaga

that player looks nice, too, but it seems to me that the unregistered version does not handle mouse sensors, i.e., I can't interact with the scene -- is that correct?

My (unregistered) version 2.2 supports mouse sensors.
Logged
pdaehne
Administrator
Sr. Member
*****
Posts: 250


View Profile
« Reply #10 on: November 07, 2008, 12:15:17 pm »

BTW:

Auf http://www.octaga.com/joomla/index.php?option=com_content&task=view&id=67&Itemid=114

gibt es bei Octaga ein paar nette szenen -- leider funktionieren sie alle nicht mit InstantPlayer  (bei vielen crasht er).

(Ich koennte sie Dir alle zukommen lassen, dann sparst Du Dir die muehe mit dem downloaden und auspacken.)

Danke, aber die habe ich schon selber alle auf meiner Festplatte. An nicht funktionierenden Szenen herrscht hier leider kein Mangel Sad

Tschüß,

Patrick
Logged
Snoopy
Newbie
*
Posts: 17


View Profile
« Reply #11 on: November 07, 2008, 04:53:54 pm »

2. Hopefully the standard will change. We are member of the Web3D consortium that develops the X3D standard, and we've started a discussion about that topic in the consortium.

Well, I really hope you can convince them.

BTW: I think it is a bad thing that the standard does not say that VRML-browsers MUST implement at least javascript.
While not being a bug, I think it makes VRML/X3D less exchangable as it could be.

Yes. See section 4.10.3 of the VRML spec:

Quote
Nodes that contain eventOuts or exposedFields shall produce at most one event per timestamp. If a field is connected to another field via a ROUTE, an implementation shall send only one event per ROUTE per timestamp. This also applies to scripts...

That's correct and that makes sense ... BUT:
it does not say that a Script shall never write the same field several times per timestamp.
And, IMHO, it does not make sense to prohibit that -- why should each writing of a field generate one separate event?
The writing of a field by a script, IMHO, should just set a flag that an event for that field has to be generated later during the event cascade.
(Unless that field already has raised an event during the same timestamp, in which case nothing happens -- that's the loop breaking rule.)

Best regards,
Gabriel.

Logged
pdaehne
Administrator
Sr. Member
*****
Posts: 250


View Profile
« Reply #12 on: November 07, 2008, 06:18:01 pm »

That's correct and that makes sense ... BUT:
it does not say that a Script shall never write the same field several times per timestamp.
And, IMHO, it does not make sense to prohibit that -- why should each writing of a field generate one separate event?
The writing of a field by a script, IMHO, should just set a flag that an event for that field has to be generated later during the event cascade.
(Unless that field already has raised an event during the same timestamp, in which case nothing happens -- that's the loop breaking rule.)

Yes, that is the way it is supposed to work, and that's the way we've implemented it in InstantPlayer Smiley

Bye,

Patrick
Logged
Snoopy
Newbie
*
Posts: 17


View Profile
« Reply #13 on: November 09, 2008, 10:44:47 pm »

A postscriptum.

In 4.12.9.3 it says:

"Sending multiple values through an eventOut during a single script execution will result in the "last" event being sent [...]"

So it is exactly as I have assumed:
writing to the same eventOut-variable several times during one script execution fires only 1 event.
(Which makes perfect sense.)

Regards,
Gabriel.

Logged
Snoopy
Newbie
*
Posts: 17


View Profile
« Reply #14 on: November 09, 2008, 11:03:27 pm »

1. The standard says:
Quote
When there is an exposed field "foo", whenever an event is received on "foo", the browser will call a Javascript function "foo". Inside the Javascript code, there is also a variable called "foo". You can read the current value of the "foo" exposed field by reading that "foo" Javascript variable, and you can send new values via the "foo" exposed field by writing these values into the "foo" Javascript variable.

I'd like to read up on that in the standard -- could you point me to the place in the standard?
I tried to find it, but failed ...

Thanks a lot in advance.

Best regards,
Gabriel.

Logged
Pages: [1] 2
  Print  
 
Jump to:  

Powered by SMF 1.1.15 | SMF © 2011, Simple Machines