VRML - VRML and X3D

Author

VRML and X3D

Joe D Williams

2006-11-05, 11:33 pm

Hi,
I'm just going to go ahead and post this here
because it is a great example of how VRML and X3D
can work together, today. At the core of it is the idea
that the standard can allow authoring tools to progress
and innovate. The tool can abstract the actual user
code interfaces into an object that can be used at
every level of the creation process and well into
production and delivery validation and support.
Looking from the standpoint of X3D Anywhere! based on a
human-readable text form having an execution model,
there will probably be many more 'standardized' players
out there than 'stanards-capable' authoring tools.
When the creation and testing tools can match up well
with delivery tools, then there will be fewer problems
in marketing, delivery, and support.

For example, for X3D, it is easy to imagine authoring tools
that produce VRML and X3D standard shapes.
Some of the best ones are long gone. in more detail,
the idea that an authoring tool can provide help in producing
animation and/or interaction scripting must require familiar
knowledge of the actual interface model of the target delivery
platform. The basics are simple, with the VRML and X3D
interface model providing adequate definitions for node event
interfaces. Authorable time and event based animation should be
available, VRML and X3D offer a straightforward event generation
and routing system along with a predictable event cascade
to produce the next simulation frame. For instance, if the author
wanted a soinning red cube in middle of the screen, it shoud
be possible for the authoring tool to abstract that concept all
the way out to a single button that selects
"Red Spinning Cube in the Middle of the Screen"
and have it run in every VRML and X3D player out there.

it starts getting complicated when the event data types or logic
don't match up, or the author wants to extend the event model in
unanticipated directions/connections. in these cases either the
authoring tool, or the author, will resort to generating
'scripted' behaviors (as distinct from 'built-in' behaviors)
to achieve the needed event processing. Just as the advance
from VRML1 to VRML97 enabled authoring tools to provide
new levels of 'built-in' animation, so X3D adds some details
that improve the native non-scripted capabilities that can
be provided by the creation tools. To show this, I want to use
a simple example that fell out of the sky. Later you may ask
how can a door fall out of the sky, but that is really a differnt topic.

A door that responds to simple open and close commands
by actually opening and closing in a predictable and realistic
way seems like a basic necessity. let's start with a simple
door that just oppens when you press a button and closes
when you press it again, For starts, let's just assume that
we don't care about safety and the ations are interlocked
so that once the door starts opening or closing, it continues
until the action is complete, then is ready for another command.
That is, for example, when you select Open, then the Close botton
is disabled, until the door is fully open.

door contiuesjust as virtually as it is in reality, except for difficult in

storyprovided by
gin to the authorwayssIn
applications that need to use all benifits of the
standardized X3D, then

the
production and deliverydeprocess.

d
can work togeher

Joe D Williams

2006-11-05, 11:33 pm

OOpps! hit Send instead of Save. More later.
Best Regards,
Joe

"Joe D Williams" <joedwil@earthlink.net> wrote in message
news:P%QUg.4891$Y24.3654@newsread4.news.pas.earthlink.net...
> Hi,
> I'm just going to go ahead and post this here
> because it is a great example of how VRML and X3D
> can work together, today. At the core of it is the idea
> that the standard can allow authoring tools to progress
> and innovate. The tool can abstract the actual user
> code interfaces into an object that can be used at
> every level of the creation process and well into
> production and delivery validation and support.
> Looking from the standpoint of X3D Anywhere! based on a
> human-readable text form having an execution model,
> there will probably be many more 'standardized' players
> out there than 'stanards-capable' authoring tools.
> When the creation and testing tools can match up well
> with delivery tools, then there will be fewer problems
> in marketing, delivery, and support.
>
> For example, for X3D, it is easy to imagine authoring tools
> that produce VRML and X3D standard shapes.
> Some of the best ones are long gone. in more detail,
> the idea that an authoring tool can provide help in producing
> animation and/or interaction scripting must require familiar
> knowledge of the actual interface model of the target delivery
> platform. The basics are simple, with the VRML and X3D
> interface model providing adequate definitions for node event
> interfaces. Authorable time and event based animation should be
> available, VRML and X3D offer a straightforward event generation
> and routing system along with a predictable event cascade
> to produce the next simulation frame. For instance, if the author
> wanted a soinning red cube in middle of the screen, it shoud
> be possible for the authoring tool to abstract that concept all
> the way out to a single button that selects
> "Red Spinning Cube in the Middle of the Screen"
> and have it run in every VRML and X3D player out there.
>
> it starts getting complicated when the event data types or logic
> don't match up, or the author wants to extend the event model in
> unanticipated directions/connections. in these cases either the
> authoring tool, or the author, will resort to generating
> 'scripted' behaviors (as distinct from 'built-in' behaviors)
> to achieve the needed event processing. Just as the advance
> from VRML1 to VRML97 enabled authoring tools to provide
> new levels of 'built-in' animation, so X3D adds some details
> that improve the native non-scripted capabilities that can
> be provided by the creation tools. To show this, I want to use
> a simple example that fell out of the sky. Later you may ask
> how can a door fall out of the sky, but that is really a differnt topic.
>
> A door that responds to simple open and close commands
> by actually opening and closing in a predictable and realistic
> way seems like a basic necessity. let's start with a simple
> door that just oppens when you press a button and closes
> when you press it again, For starts, let's just assume that
> we don't care about safety and the ations are interlocked
> so that once the door starts opening or closing, it continues
> until the action is complete, then is ready for another command.
> That is, for example, when you select Open, then the Close botton
> is disabled, until the door is fully open.
>
>
>
>
> door contiuesjust as virtually as it is in reality, except for difficult
> in
>
> storyprovided by
> gin to the authorwayssIn
> applications that need to use all benifits of the
> standardized X3D, then
>
>
>
> the
> production and deliverydeprocess.
>
>
> d
> can work togeher
>

Joerg Scheurich aka MUFTI

2006-11-05, 11:33 pm

> For example, for X3D, it is easy to imagine authoring tools
> that produce VRML and X3D standard shapes.

Unfortunatly, this is not really easy. Cause of the change of the NURBS
component nodes from ISO/IEC14772-1:1997/Amd. 1:2002 to ISO/IEC 19775:2004
it is rather difficult to produce both VRML and X3D shapes.
Of course a NURBS node can be rendered als IndexedFaceSet, but this can
bring other problems. E.g. if you have a animation of the controlpoints
of a Nurbs(Patch)Surface the intermediate result between the keys are
different from a CoordinateInterpolator based animation of a IndexedFaceSet.

The vague NURBS descriptions in
http://www.web3d.org/x3d/specificat...tSpecification/
do not make it easier.

For example in 27.2.3 you can read:

| A closed B-Spline curve can be specified by repeating the limiting control
| points, specifying a periodic knot vector, and setting the closed field to
| TRUE. If the last control point is not identical to the first, the field is
| ignored

As far as i understood NURBS, a closed B-Spline curve would be constructed
alone by repeating (n-order (+1?) times) the limiting control points, if the
last control point is identical to the first control point.
The meaning of the other fields is unclear for me (e.g. a closed field
would be sensefull, if it would be defined as something like: no need to
repeat the limiting control points, if the close field is set and using the
control points of the other end as neighbours in the sense of

/ 1, if t_i <= u < t_i+1
N_i,0(u) = <
\ 0, else

cause this would smooth a edge built by "repeating the limiting control points
with first and last controlpoint identical").

I do not even know, what a "periodic knot vector" is, cause a knot vector
has to be nondecreasing.

http://web.cs.wpi.edu/~matt/courses...alks/nurbs.html

| The sequence of knots in the knot vector U is assumed to be nondecreasing,
| i.e. t_i <= t_i+1.

An other mystique sentence is in 27.3.2:

| closed defines whether the curve should be rendered as a closed object in
| the given parametric direction allowing the object to be closed in one
| direction, but not the other (EXAMPLE cylinder).

A cylinder is a 2D surface, not a curve. So how do you understand this
sentence ?

Even the images in the X3D Nurbs definition are confusing:

For example it is unclear, if the image of NurbsSwungSurface

http://www.web3d.org/x3d/specificat...wungSurface.png

shows two curves (that would form a invisible shape) or two different shapes
(build from two curves, where at least one curve is invisible) ?

Please compare to

http://www.web3d.org/x3d/specificat.../NurbsCurve.png

which clearly shows a Curve...

> Authorable time and event based animation should be
> available, VRML and X3D offer a straightforward event generation
> and routing system along with a predictable event cascade
> to produce the next simulation frame.

Unfortunatly not. For example rotations...

> For instance, if the author
> wanted a soinning red cube in middle of the screen, it shoud
> be possible for the authoring tool to abstract that concept all
> the way out to a single button that selects
> "Red Spinning Cube in the Middle of the Screen"
> and have it run in every VRML and X3D player out there.

The rotations build into VRML/X3D follow the definition of

| 19.4.5 OrientationInterpolator
|
| An OrientationInterpolator interpolates between two orientations by
| computing the shortest path on the unit sphere between the two orientations.
| ...
| The results are undefined if the two orientations are diagonally opposite.

So if a authoring tool give full control over all data, it is possible to
create a undefined animation and any VRML and X3D player can display it
differently.

so long
MUFTI
--
Auserlesener Halt, da Video oder Lebhaftigkeit-Klammer zu halten
(aus einem Softwarehandbuch, Stichworte: animation und clip)

Joe D Williams

2006-11-05, 11:33 pm

Hi MUFTI, Thanks for replying.

There may be some changes in the latest abstract that answer some of your
comments.

http://www.web3d.org/x3d/specifications/
ISO-IEC-19775-X3DAbstractSpecification_Revision1_to_Part1/
Part01/components/nurbs.html

AT this time the abstract has been republished and incorporates current
comments.

"Joerg Scheurich aka MUFTI" <rusmufti@helpdesk.bera.rus.uni-stuttgart.de>
wrote in message news:eg2kjc$2sb$1@infosun2.rus.uni-stuttgart.de...
>
> Unfortunatly, this is not really easy. Cause of the change of the NURBS
> component nodes from ISO/IEC14772-1:1997/Amd. 1:2002 to ISO/IEC 19775:2004
> it is rather difficult to produce both VRML and X3D shapes.
> Of course a NURBS node can be rendered als IndexedFaceSet, but this can
> bring other problems. E.g. if you have a animation of the controlpoints
> of a Nurbs(Patch)Surface the intermediate result between the keys are
> different from a CoordinateInterpolator based animation of a
> IndexedFaceSet.
>
> The vague NURBS descriptions in
> http://www.web3d.org/x3d/specificat...tSpecification/
> do not make it easier.
>
> For example in 27.2.3 you can read:
>
> | A closed B-Spline curve can be specified by repeating the limiting
> control
> | points, specifying a periodic knot vector, and setting the closed field
> to
> | TRUE. If the last control point is not identical to the first, the field
> is
> | ignored

Changed text:
A closed B-Spline curve can be specified by repeating the limiting control
points, specifying a periodic knot vector, and setting the closed field to
TRUE. If the last control point is not identical to the first
or there exists a non-unitary value of weight within (order-1) control
points
of the seam, the closed field is ignored.

>
> As far as i understood NURBS, a closed B-Spline curve would be constructed
> alone by repeating (n-order (+1?) times) the limiting control points, if
> the
> last control point is identical to the first control point.
> The meaning of the other fields is unclear for me (e.g. a closed field
> would be sensefull, if it would be defined as something like: no need to
> repeat the limiting control points, if the close field is set and using
> the
> control points of the other end as neighbours in the sense of
>
> / 1, if t_i <= u < t_i+1
> N_i,0(u) = <
> \ 0, else
>
> cause this would smooth a edge built by "repeating the limiting control
> points
> with first and last controlpoint identical").

Does that change help?

>
> I do not even know, what a "periodic knot vector" is, cause a knot vector
> has to be nondecreasing.
>
> http://web.cs.wpi.edu/~matt/courses...alks/nurbs.html
>
> | The sequence of knots in the knot vector U is assumed to be
> nondecreasing,
> | i.e. t_i <= t_i+1.

I don't know. Does it mean nondecreasing fixed periodic?

>
> An other mystique sentence is in 27.3.2:
>
> | closed defines whether the curve should be rendered as a closed object
> in
> | the given parametric direction allowing the object to be closed in one
> | direction, but not the other (EXAMPLE cylinder).

Good catch. I can't find that sentence anymore.

>
> A cylinder is a 2D surface, not a curve. So how do you understand this
> sentence ?
>
>
> Even the images in the X3D Nurbs definition are confusing:
>
> For example it is unclear, if the image of NurbsSwungSurface
>
>
> http://www.web3d.org/x3d/specificat...wungSurface.png
>
> shows two curves (that would form a invisible shape) or two different
> shapes
> (build from two curves, where at least one curve is invisible) ?
>
> Please compare to
>
> http://www.web3d.org/x3d/specificat.../NurbsCurve.png
>
> which clearly shows a Curve...

Art in the revised copy
http://www.web3d.org/x3d/specifications/
ISO-IEC-19775-X3DAbstractSpecification_Revision1_to_Part1/
Images/NurbsSwungSurface.png
has not changed from the original X3D art that I can see.
I agree the two diagrams you mention appear different but I
don't know details.

>
>
> Unfortunatly not. For example rotations...
>
>
> The rotations build into VRML/X3D follow the definition of
>
> | 19.4.5 OrientationInterpolator
> |
> | An OrientationInterpolator interpolates between two orientations by
> | computing the shortest path on the unit sphere between the two
> orientations.
> | ...
> | The results are undefined if the two orientations are diagonally
> opposite.
>
> So if a authoring tool give full control over all data, it is possible to
> create a undefined animation and any VRML and X3D player can display it
> differently.

That means the authoring tool must be smart enough to not let that happen:)
Surelly the tool would choose more that two points in that sequence so that
the undefined state is not produced.

>
> so long
> MUFTI

Thanks again, MUFTI. There were some far-reaching changes to NURBS from
VRML97 to X3D and I am sure your comments are carefully considered.

Best Regards,
Joe

Joerg Scheurich aka MUFTI

2006-11-05, 11:33 pm

> Changed text:
> A closed B-Spline curve can be specified by repeating the limiting control
> points, specifying a periodic knot vector, and setting the closed field to
> TRUE. If the last control point is not identical to the first
> or there exists a non-unitary value of weight within (order-1) control
> points
> of the seam, the closed field is ignored.

> Does that change help?

Not really. But the Sentence about

| If the closed field is set to FALSE, the implementation shall not be
| required to smoothly blend the edges of the surface in that dimension into
| a continuous surface.

is very usefull, cause it clearly tells about the closed Fields are good for.

A few colums later the sentence is more or less repeated

| If either the uClosed or the vClosed field is set to FALSE, the
| implementation shall not be required to smoothly blend the edges of the
| surface in that dimension into a continuous surface.

but well, better two sentences then none 8-)

[color=darkred]
> I don't know. Does it mean nondecreasing fixed periodic?

Can you understand "nondecreasing fixed periodic" as "repeating the same
value ??? times" ?
I can not, but maybe this is my fault....

[color=darkred]
> Art in the revised copy
> http://www.web3d.org/x3d/specifications/
> ISO-IEC-19775-X3DAbstractSpecification_Revision1_to_Part1/
> Images/NurbsSwungSurface.png
> has not changed from the original X3D art that I can see.
> I agree the two diagrams you mention appear different but I
> don't know details.

The picture about NurbsSwungSurface.png and NurbsCurve.png look rather similar
and this is part of the problem. NurbsCurve.png clearly shows a "fat" curve.
NurbsSwungSurface.png shows either two Curves (but should also show a surface,
cause NurbsSwungSurface is a surface (27.4.12 NurbsSwungSurface
"NurbsSwungSurface describes a generalized surface")) or it shows two surfaces
(that do not differ visually from a curve like in NurbsCurve.png, together
with talking about two curves and showing surfaces this is mega confusing).

The same confusion applies to

http://www.web3d.org/x3d/specificat...weptSurface.png

I would vote for showing both the two curves and the resulting shape in both
figures. Or at least, if you only can show curves but no surface, then please
add a text and arrow to each curve to avoid confusion.

[color=darkred]
> That means the authoring tool must be smart enough to not let that happen:)
> Surelly the tool would choose more that two points in that sequence so that
> the undefined state is not produced.

Usually keyframe type animation creation let the user track state and next
state. Do you think should a authoring tool do, if it detect a ambigous
sitution ?
BTW: AFAIK, there can be a similar situation in the ColorInterpolator...

thanks
so long
MUFTI
--
Auserlesener Halt, da Video oder Lebhaftigkeit-Klammer zu halten
(aus einem Softwarehandbuch, Stichworte: animation und clip)

Joe D Williams

2006-11-05, 11:33 pm

"Joerg Scheurich aka MUFTI" <rusmufti@helpdesk.bera.rus.uni-stuttgart.de>
wrote in message news:eg3mg5$4t2$1@infosun2.rus.uni-stuttgart.de...
>
>
> Not really. But the Sentence about
>
> | If the closed field is set to FALSE, the implementation shall not be
> | required to smoothly blend the edges of the surface in that dimension
> into
> | a continuous surface.
>
> is very usefull, cause it clearly tells about the closed Fields are good
> for.
>
> A few colums later the sentence is more or less repeated
>
> | If either the uClosed or the vClosed field is set to FALSE, the
> | implementation shall not be required to smoothly blend the edges of the
> | surface in that dimension into a continuous surface.
>
> but well, better two sentences then none 8-)
>
>
>

From:

http://web.cs.wpi.edu/~matt/courses...alks/nurbs.html

"The Knot Vector...

The sequence of knots in the knot vector U is assumed
to be nondecreasing...

For NURBS, the relative parametric intervals (knot spans)
need not be the same for all shape segments, i.e. the knot
spacing is nonuniform, ...

In contrast, a periodic knot vector U = { 0, 1, ... , n } is
everywhere k-1 times continuously differentiable.) ..."

The last quote is the only occurance of 'periodic knot vector'
in that article and seems to accept the concept as OK to use
fixed 'periods' but not a requirement because the degree of
the B-Spline is always allowed to vary.

> Can you understand "nondecreasing fixed periodic" as "repeating the same
> value ??? times" ?
> I can not, but maybe this is my fault....

i can understand that it means repeated. but not how many times.
Maybe just repeated an many times as you need to close it?

>
>
>
> The picture about NurbsSwungSurface.png and NurbsCurve.png look rather
> similar
> and this is part of the problem. NurbsCurve.png clearly shows a "fat"
> curve.
> NurbsSwungSurface.png shows either two Curves (but should also show a
> surface,
> cause NurbsSwungSurface is a surface (27.4.12 NurbsSwungSurface
> "NurbsSwungSurface describes a generalized surface")) or it shows two
> surfaces
> (that do not differ visually from a curve like in NurbsCurve.png, together
> with talking about two curves and showing surfaces this is mega
> confusing).
>
> The same confusion applies to
>
> http://www.web3d.org/x3d/specificat...weptSurface.png
>
> I would vote for showing both the two curves and the resulting shape in
> both
> figures. Or at least, if you only can show curves but no surface, then
> please
> add a text and arrow to each curve to avoid confusion.

Now I see better what has bothered me when I try to understand what is
going on using these two illustrations.
Not seeing the result surface leaves me without a vital clue, I think.

>
>
>
> Usually keyframe type animation creation let the user track state and next
> state. Do you think should a authoring tool do, if it detect a ambigous
> sitution ?

Well, it is not exactly a syntax error and there is not notation included
that makes it possible to include a range of values in the schema,
so I guess that must leave it up to the author or the authoring tool.

> BTW: AFAIK, there can be a similar situation in the ColorInterpolator...

Yes, that one seems to me to be more difficult to capture and avoid.

>
> thanks
> so long
> MUFTI

On the matter of the two artworks, I need more guidance telling me
how the apparent differences in the way the curves are
represented are accurate, and how to show that resulting
surface.

Anyone else??

The two images are:

http://www.web3d.org/x3d/specificat...weptSurface.png

and

http://www.web3d.org/x3d/specificat.../NurbsCurve.png

Thanks and BestRegards,
Joe

Joerg Scheurich aka MUFTI

2006-11-05, 11:33 pm

> For NURBS, the relative parametric intervals (knot spans)
> need not be the same for all shape segments, i.e. the knot
> spacing is nonuniform, ...

> In contrast, a periodic knot vector U = { 0, 1, ... , n } is
> everywhere k-1 times continuously differentiable.) ..."

AFAIK: If you use such a periodic knot vector with not n(+1) Order times
repeated values for the first and the last controlpoint, the curve will
noch hit the first and last controlpoint itself (which need to be at the same
place if the curve should be closed). AFAIK in the general case, the curve
would not be closed by simply using the normal NURBS features.
In this case, you would need a additional formula to fill the gap between
the begin and end of the curve.

> The last quote is the only occurance of 'periodic knot vector'
> in that article and seems to accept the concept as OK to use
> fixed 'periods' but not a requirement because the degree of
> the B-Spline is always allowed to vary.

In this general case the first and last controlPoints do not hit the
curve itself, therefore the curve would not be closed, either the curveends
get too long or to short to meet the the first and last controlPoints.

The longer i think about the closed fields, i get worried.
In the new clearification for NurbsPatchSurface, it is written, the closed
field define, if the edge, the curves meet is smooth blended or not.
While you can smoothed a surface by accounting a matching Normal vector,
you can not smooth a curve in case of the NurbsCurve node, cause there
is no equivalent of a Normal vector.

I think, it should be clearly written into the standard, what exactly
technically has to be done to "smooth", if a closed field is set.
[color=darkred]

The real big problem in this field is the problem of not having exact numbers
on computers.

To get the undefined rotation animation you need the number PI (at least in
some cases) for the angle.
The number of PI can not exactly reached by digital floating point numbers.

Real life authoring tools need to round the numbers, often they cut away
dezimal numbers at the end to limit the size of the VRML file. Even if
they show all numbers, they can round either up or down for the last bits
when producing ASCII data.
So a authoring tool would generate either the one or a completly different
defined rotation animation (or in other words: "nearly undefined rotation
animation"), depending on the rounding algorithm and the number of written
digits.

So a epsilon length is needed, a "what is nearly" zero, to deal with the
problem.

A similar problem applies to each SFRotation/MFRotation field:

| 5.10 SFRotation and MFRotation

| .. An SFRotation is written to the X3D file as four floating point values.
| The allowable form for a floating point number is defined in the specific
| encoding. The first three values specify a normalized rotation axis vector
| about which the rotation takes place.

In the general case and in practise, you can not normalize the rotation axis
(length == exactly 1) and write the numbers to ASCII without to tell, what
should be seen as good enough to be exactly of length 1.

BTW: For a axis/angle rotation pair, there is no need to know how long the
axis is. But this is another story 8-(

so long
MUFTI
--
Every Array object has a length property whose value is always an
integer with positive sign and less than 232.
32
Layout error einer ECMAScript Spezifikation in HTML: 2 -> 232