Menu
▾
▴
xvrml-schema-dev — Discussion of xVRML Schema development issues
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
(1) |
Mar
(3) |
Apr
(6) |
May
|
Jun
(1) |
Jul
|
Aug
(1) |
Sep
|
Oct
(1) |
Nov
|
Dec
|
|---|
|
From: Jeff S. <jso...@gm...> - 2005-10-14 21:03:37
|
Thanks Dave! There is a new drop of Carina in SourceForge with the following changes: - Errors in files now show up as a button in the status bar - Information window on the worlds has been moved to the view menu - Animated gif support added to image textures - Added support for libxslt to convert files instead of using Java - Added open recent menu option - Added basic help system - Bugfix: Commas in vrml files are handled better - Bugfix: Saving of some values in preferences fixed The VRML import, especially from files created by modelers and containing zillions of commas, is much improved. And the best part? Dave has implemented animated GIF support in Carina, so artists get to take the first steps away from building "ghost town" scenes, and the first intimations of movement and dynamicism have entered the arena. As usual, Dave is distributing binaries for Windows and Mac and source tree for Linux. jeffs |
|
From: Miriam E. <mi...@we...> - 2005-08-18 23:36:40
|
Hi folks, I have to go out shortly, so I'll keep this as quick as I can. Interpolators are neat, but they are one of the hardest things in VRML to understand, also they are NOT general purpose. There are some situations where the scene author knows the startpoint, endpoint, and duration of an action, but in *most* situations only two of these will be known, and sometimes not even that. In such situations the poor author has to go through all manner of contortions to make the awfully over-specialised Interpolator nodes work for them. In many, perhaps most, situations the author will have just a startpoint and a force (and sometimes only a force). I'd suggest leaving Interpolators in for backward compatibility, but spend the time working on coupling any VR display system to a physics simulator like ODE. Let the display just display, and let the physics take care of movements. Interpolators have descended from cartooning, but cartoons and VR are quite different things. You can make VR work like cartoons, and for that Interpolators could be useful I guess, but I think most authors would prefer to be able to throw a ball and have it arc up and down to bounce around without explicitly animating it and without needing to know ahead of time where it will bounce to. It is much more sensible to set one force (the wind) against a tree blowing in the breeze rather than having to animate every darned leaf and branch with Interpolators. I have come to the conclusion that building up general purpose animation libraries (walk, run, jump, etc.) that can be easily adjusted to different characters (a dwarf walks differently from a giant, and a pirate with a wooden leg walks differently from either) is next to impossible using Interpolators. In order to develop such general purpose animation libraries we need to use physics simulators. They exist and are free and open source. We should be using them. Otherwise it is like saying the graphics accelerators in video cards exist, but we'll use the main CPU because that is how it used to be done. Simplify and extend. :) Best wishes, - Miriam David Huffman wrote: >>so >>the first question which came up was >>what exactly is in the "key" element? >> >> numbers from 0.0 to 1.0 [representing % of the way through an >>animation]? >> numbers representing absolute (Unix) time? >> numbers representing absolute (since the simulation started) time? >> numbers representing relative (since it was triggered) time? >> something else? >> >>Dave Huffman had some good thoughts about this issue >>which he expressed during the Team meeting this week... >> >>Dave: you want to chime in on this discussion please? > > > the key element is exactly what it looks like, and i think it should stay the way as it was in the original vrml specs. an unbounded set of numbers that are always increasing. realize that a position interpolator has nothing to do with time. it is only a calculator converting a float value to a new position. it shouldnt be a percentage because it may not necessarily just go from start to end. If it is based on time, then it would go from beginning to end like you are expecting. If it was based on something else, like another objects position, it may not go from start to end so simply. > > i believe strongly of keeping the key a float, as it has no connections to time directly. most people connect a time sensor to position interpolators, but it is not always that way, so we must keep it generic. also note that interpolators are not triggered, the sensors such as the time sensor is triggered. > > i believe we have two discussions here, one for the type of keys in interpolators, which i believe should remain generic, and a discussion on how time should be represented in time sensors. a position interpolator has nothing to do with time unless a time sensor is connected as input, and at that point it is only converting an input to output. interpolators can not be time dependent. > > dave -- ---------=---------=---------=---------=---------=---------=------ A life! Cool! Where can I download one of those from? ---------=---------=---------=---------=---------=---------=------ http://werple.net.au/~miriam My live Journal page http://www.livejournal.com/users/miriam_e/ |
|
From: Jeff S. <je...@ar...> - 2005-06-07 13:26:07
|
new release of the xVRML Schema [build 032.08.06 beta]
and docs and sample app and so on
available at SourceForge now...
new release of Carina viewer to be posted shortly
including major UI overhaul
and code refactoring and bugfixes
and additional import of more file-formats
and support for loading and displaying more nodes...
main Schema changes in current release:
added stepValue to Avatar [default 0.75 m]
added optional attribute "solid" with default="true" to:
Box
Cone
Cylinder
Sphere
[already present in Extrusion]
added VRML97-style defaults to Extrusion:
crossSection default="1.0 1.0 1.0 -1.0 -1.0 -1.0 -1.0 1.0 1.0 1.0"
orientation default="0.0 0.0 1.0 0.0"
scale default="1.0 1.0"
spine default="0.0 0.0 0.0 0.0 1.0 0.0"
jeffs
--
Jeff Sonstein
[RIT] http://www.it.rit.edu/~jxs/
[Personal] http://ariadne.iz.net/~jeffs/
[PGP] http://ariadne.iz.net/~jeffs/jeffs.asc
[Project] http://xvrml.net/
-----------------------------------
There are no bugs
there are just undocumented features
|
|
From: Jeff S. <je...@ar...> - 2005-04-25 15:59:37
|
would really appreciate folks looking at and commenting to us
esp in re Proto-related changes
[summary of changes]
<Carina v 20050419>
- Added Viewpoint node for xVRML and VRML, load and export
- Added backface culling
- Support solid and ccw attributes in IndexedFaceSet
- Use texture objects, images stored video ram when possible
and speeds rendering of textured scenes
- Preferences look much better and are much more user friendly
- and various Bugfixes
<xVRML build 032.08.05 beta>
- first serious proposal for cleanly specifying Proto-related nodes
- Specified exact choices for Avatar.children and removed Viewpoint
- changed defaults for Avatar.cameraOffset and Viewpoint.position
- specified how to deal with four basic configurations
and interactions possible:
o No Avatars and no Viewpoints in file
o No Avatars but at least one Viewpoint in file
o At least one Avatar but no Viewpoints in file
o At least one Avatar and at least one Viewpoint in the file
- fixed problems with Use inside appearance
as Material and/or Texture replacements
- made Avatar.name required
- removed mis-statement in Use docs about Avatar
jeffs
--
Jeff Sonstein
Assistant Professor
Department of Information Technology
Rochester Institute of Technology
--------------------------------------------
[RIT] http://www.it.rit.edu/~jxs/
[Personal] http://ariadne.iz.net/~jeffs/
[PGP] http://ariadne.iz.net/~jeffs/jeffs.asc
[Project] http://xvrml.net/
--------------------------------------------
There are no bugs
there are just undocumented features
|
|
From: David H. <en...@ar...> - 2005-04-13 21:41:41
|
Jeff Sonstein wrote .. > 2) reworked Avatar.children to dis-allow Viewpoints All good but this one. It is still possible to specify a viewpoint just not as a direct child of avatar. For example, you can do Avatar.children.Transform.children.Viewpoint. removal of the viewpoint from avatars might have to be an application level thing. i would probably say just change the Avatar's children to be childrenAndGroupingNodes like before. dave |
|
From: Jeff S. <je...@ar...> - 2005-04-13 15:39:39
|
I have posted a candidate 0.32.08.05 beta release Schema and docs and etc at the xVRML Project site and strongly request that people review the modifications proposed... I'd like to do a new SourceForge drop today/tonight if possible iggest items to review: 1) Use inside Shape.appearance cleaned up 2) reworked Avatar.children to dis-allow Viewpoints 3) reworked defaults for Avatar and Viewpoint 4) clarified interactions between Avatar and Viewpoint 5) specified initial user position values in all 4 cases: a) no Avatars and no Viewpoints b) no Avatars but at least one Viewpoint c) no Viewpoints but at least one Avatar d) both at least one Avatar and at least one Viewpoint please review jeffs -- Jeff Sonstein Assistant Professor Department of Information Technology Rochester Institute of Technology -------------------------------------------- [RIT] http://www.it.rit.edu/~jxs/ [Personal] http://ariadne.iz.net/~jeffs/ [PGP] http://ariadne.iz.net/~jeffs/jeffs.asc [Project] http://xvrml.net/ -------------------------------------------- There are no bugs there are just undocumented features |
|
From: Jeff S. <je...@ar...> - 2005-04-08 16:51:24
|
fixed problem with Shape appearance and Material Texture Use combinations and permutations (I think) please look at the Shape node docs at the Project site and tell me what you think... these changes shouldn't break any existing content note the file http://xvrml.net/examples/appearanceCombos.xwrl which demonstrates all the legal ways to put them together [although it throws an error in the current distribution of Carina because of a bug in the current distribution of Carina] thanks for the code terviedw, Dave and the chat about possible approaches... it helps a lot to chat w colleagues when stuck Project Team Members... subscribe to the #$%^ xvr...@li... list please today jeffs -- Jeff Sonstein Assistant Professor Department of Information Technology Rochester Institute of Technology -------------------------------------------- [RIT] http://www.it.rit.edu/~jxs/ [Personal] http://ariadne.iz.net/~jeffs/ [PGP] http://ariadne.iz.net/~jeffs/jeffs.asc [Project] http://xvrml.net/ -------------------------------------------- There are no bugs there are just undocumented features |
|
From: Jeff S. <je...@ar...> - 2005-04-08 03:22:46
|
I have dropped version 0.32.09.00 alpha of the xVRML Schema and Schema documentation and modified examples onto the Project server at: http://www.xvrml.net/currentAlpha/ the changes proposed in this version are primarily in the Shape node and I need for people to review: http://www.xvrml.net/currentAlpha/docs/core.html#element_Shape and to comment to <xvr...@li...> inside the Shape.appearance is the last place that semantics associated with Use needed to be fixed as the current beta Schema would not allow replacing *both* appearance.Material and appearance.Texture with Use nodes and that is not our intent thanksfully this appears to be the only place that Use is broken I have brought back some notation from VRML97 now that I remember why we needed it in the first place to solve the problem I reworked a bunch of example xwrl files and placed them on the server too to illustrate what effects the changes to the Schema will have on xVRML world files... it is because the changes **will** break existing content that the version bumps to 0.32.09 the reworked examples may be found at: http://www.xvrml.net/currentAlpha/examples/ the file "appearanceCombos.xwrl" shows all permutations of all the legal combinations of 2 which were intended: (material and texture) (material and Use) (Use and texture) (Use and Use) Project team members: please insure that you are subscribed to xvr...@li... as that is where I would like the discussion to take place this is the most straightforward route I can find to insuring that the combinations and permutations which we intend to be valid are valid while insuring the validation process relieves the application of as much responsibility for insuring it is a good file as is reasonable jeffs -- Jeff Sonstein Assistant Professor Department of Information Technology Rochester Institute of Technology -------------------------------------------- [RIT] http://www.it.rit.edu/~jxs/ [Personal] http://ariadne.iz.net/~jeffs/ [PGP] http://ariadne.iz.net/~jeffs/jeffs.asc [Project] http://xvrml.net/ -------------------------------------------- There are no bugs there are just undocumented features |
|
From: Jeff S. <je...@ar...> - 2005-04-07 16:41:05
|
after a couple of passes through the Schema
I am now pretty convinced that
the only real Use issue remaining
[see my last posting about this]
is within Shape.appearance
it now says:
<xs:choice minOccurs="0" maxOccurs="2">
<xs:element ref="Material"/>
<xs:element ref="Texture"/>
<xs:element ref="Use"/>
</xs:choice>
and the problem with that is
replacing **both**
the Material **and**
the Texture
in the same appearance
with 2 Use nodes [1 per]
jeffs
--
Jeff Sonstein
Assistant Professor
Department of Information Technology
Rochester Institute of Technology
--------------------------------------------
[RIT] http://www.it.rit.edu/~jxs/
[Personal] http://ariadne.iz.net/~jeffs/
[PGP] http://ariadne.iz.net/~jeffs/jeffs.asc
[Project] http://xvrml.net/
--------------------------------------------
There are no bugs
there are just undocumented features
|
|
From: Jeff S. <je...@ar...> - 2005-03-10 20:40:33
|
re: our current discussion about how to deal w protos... 1) here is what my proposal now looks like in pseudo-code form: <World> optional <NavigationInfo> optional <WorldInfo> optional <ProtoList> optional <AvatarList> 1 <children> which may contain groupingAndChildrenNodes <ProtoList> 0 to * <ProtoDefinition> <ProtoDefinition> required "name" attribute (a unique xs:ID) 0 to many <FieldDefinition> 1 <children> which may contain groupingAndChildrenNodes a FieldDefinition consists of required "name" attribute (an xs:string) required "target" attribute (xs:IDREF points to child of its' ProtoDefinition) optional "targetAttribute" attribute (an xs:string) optional "defaultValue" attribute (an xs:string) 1 optional element of any type from the xVRML namespace groupingAndChildrenNodes may contain 0 to many ProtoInstance <ProtoInstance> optional "name" attribute required "definition" attribute (xs:IDREF points to ProtoDefinition "name" attribute) 0 to many <Field> <Field> required "name" attribute (xs:string provides name to outside world) required "value" attribute (xs:string provides default value) (should this be optional?) 1 optional element of any type from the xVRML namespace (provides default settings) 2) any element any attribute references: see discussion of xs:any element here: http://www.w3.org/TR/xmlschema-0/#any see also description of xs:any element here: http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-any see dscription of xs:anyAttribute here: http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/structures.html#element-anyAttribute see also discussion of xs:any and xs:anyAttribute "namespace" and "processContents" attributes here: http://www.w3schools.com/schema/el_any.asp 3) I think it is better to limit to the local namespace rather than [shudder] arguing through making a list and then enumerating the elements/attributes allowed in the Schema... although it *would* take a load off of the application-builder it would IMHO grossly increase the complexity of the Schema jeffs -- Jeff Sonstein Assistant Professor Department of Information Technology Rochester Institute of Technology -------------------------------------------- [RIT] http://www.it.rit.edu/~jxs/ [Personal] http://ariadne.iz.net/~jeffs/ [PGP] http://ariadne.iz.net/~jeffs/jeffs.asc [Project] http://xvrml.net/ -------------------------------------------- There are no bugs there are just undocumented features |
|
From: Jeff S. <je...@ar...> - 2005-03-09 23:45:34
|
David Huffman wrote .. > Here is that proto write-up i said i would do. thanks I'm going to cross-post my reply to the xvrml-schema-dev list so we can (hopefully) engage some other "eyes and brains" in this > The key issue is supporting complex data types such as SFColor, specifically > default values in the definition, and initial used values in the instance. > To do this, we extend the definition of what a field and field definition > is. [lines snipped out] tell me if the following meets what you are after: <World> optional <NavigationInfo> optional <WorldInfo> optional <ProtoList> optional <AvatarList> 1 <children> which may contain groupingAndChildrenNodes <ProtoList> 0 to * <ProtoDefinition> <ProtoDefinition> required "name" attribute (a unique xs:ID) 0 to many <FieldDefinition> 1 <children> which may contain groupingAndChildrenNodes a FieldDefinition consists of required "name" attribute (an xs:string) optional "target" attribute (xs:IDREF points to child of its' ProtoDefinition) optional "targetAttribute" attribute (an xs:string) optional "defaultValue" attribute (an xs:string) 1 optional element of any type from the xVRML namespace groupingAndChildrenNodes may contain 0 to many ProtoInstance <ProtoInstance> optional "name" attribute required "definition" attribute (xs:IDREF points to ProtoDefinition "name" attribute) 0 to many <Field> <Field> required "name" attribute (xs:string provides name to outside world) required "value" attribute (xs:string provides default value) (should this be optional?) 1 optional element of any type from the xVRML namespace (provides default settings) ----- I *think* I am thinking about this straight <grin/> > did you still want a thursday one on one meeting? yes please jeffs -- Jeff Sonstein Assistant Professor Department of Information Technology Rochester Institute of Technology -------------------------------------------- [RIT] http://www.it.rit.edu/~jxs/ [Personal] http://ariadne.iz.net/~jeffs/ [PGP] http://ariadne.iz.net/~jeffs/jeffs.asc [Project] http://xvrml.net/ -------------------------------------------- There are no bugs there are just undocumented features |
|
From: Jeff S. <je...@ar...> - 2005-03-06 13:11:09
|
in the interests of "keeping peace in the family"
I'd like to suggest moving the discussion of Proto in xVRML
onto the xvr...@li...
and off of the xvrml-announce and www-vrml lists...
we are currently struggling with Proto
and I would love to get some help from the list members
in figuring ou the best way to approach it...
our current interim solution is unsatisfactory to one and all
for one reason or another
here is a sketch of the current [unsatisfactory] proto proposal:
----- snip -----
<xs:element name="World>
<xs:complexType>
<xs:sequence>
<xs:element ref="NavigationInfo" maxOccurs="1" minOccurs="0"/>
<xs:element ref="WorldInfo" maxOccurs="1" minOccurs="0"/>
<xs:element name="ProtoList" maxOccurs="1" minOccurs="0">
<xs:complexType>
<xs:sequence maxOccurs="unbounded" minOccurs="0">
<xs:element ref="ProtoDefinition"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="AvatarList" maxOccurs="1" minOccurs="0">
<xs:complexType>
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element ref="Avatar" maxOccurs="unbounded" minOccurs="0"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="children" type="groupingAndChildrenNodes"/>
</xs:sequence>
<xs:attribute name="name" type="xs:ID"/>
</xs:complexType>
</xs:element>
[ ... ]
<xs:element name="ProtoDefinition">
<xs:complexType>
<xs:sequence>
<xs:element name="FieldDefinition" maxOccurs="unbounded" minOccurs="0">
<xs:complexType>
<!-- name to the outside world -->
<xs:attribute name="name" type="xs:string"/>
<!-- unique name of the thing inside being exposed -->
<xs:attribute name="target" type="xs:IDREF"/>
<!-- specific attribute of the thing inside being exposed -->0
<xs:attribute name="targetAttribute" type="xs:string"/>
<!-- should we make "type" an enumeration of legal values? -->
<xs:attribute name="type" type="xs:string"/>
<xs:attribute name="defaultValue" type="xs:string"/>
</xs:complexType>
</xs:element>
<xs:element name="children" type="groupingAndChildrenNodes"/>
</xs:sequence>
<xs:attribute name="name" type="xs:ID" use="required"/>
</xs:complexType>
</xs:element>
<xs:element name="ProtoInstance">
<xs:complexType>
<xs:sequence>
<xs:element name="field" minOccurs="0" maxOccurs="unbounded">
<xs:complexType>
<xs:attribute name="name" type="xs:string" use="required"/>
<xs:attribute name="value" type="xs:string" use="required"/>
</xs:complexType>
</xs:element>
</xs:sequence>
<xs:attribute name="definition" type="xs:IDREF"/>
<xs:attribute name="name" type="xs:ID"/>
</xs:complexType>
</xs:element>
[ ... ]
<xs:complexType name="groupingAndChildrenNodes">
<xs:annotation/>
<xs:choice maxOccurs="unbounded" minOccurs="0">
<xs:element ref="Anchor"/>
[ ... ]
<xs:element ref="ProtoInstance"/>
[ ... ]
<xs:element ref="VisibilitySensor"/>
</xs:choice>
</xs:complexType>
----- snip -----
so how do we expose
an element rather than an attribute of an element?
one proposal is to say that
if ProtoDefinition.targetAttribute.FieldDefinition
is equal to the reserved word "node"
then the whole element is being exposed
but that has problems too...
the whole thing seems really clumsy to me
how to keep the Schema doing most of the error-checking
[the closer to creation errors are caught the better]
and how to minimize the post-validation work the app needs to do
while still keeping the spec simple and easy to understand????
input very very welcome
jeffs
--
Jeff Sonstein
Assistant Professor
Department of Information Technology
Rochester Institute of Technology
--------------------------------------------
[RIT] http://www.it.rit.edu/~jxs/
[Personal] http://ariadne.iz.net/~jeffs/
[PGP] http://ariadne.iz.net/~jeffs/jeffs.asc
[Project] http://xvrml.net/
--------------------------------------------
There are no bugs
there are just undocumented features
|
|
From: Jeff S. <je...@ar...> - 2005-02-07 15:56:04
|
I have released build 0.32.07 beta of the Schema and example Java classes and documentation at the xVRML SourceForge site [ http://sourceforge.net/projects/xvrml/ ] and updated the posted materials at the xVRML website [ http://www.xvrml.net/ ] jeffs -- Jeff Sonstein Assistant Professor Department of Information Technology Rochester Institute of Technology -------------------------------------------- [RIT] http://www.it.rit.edu/~jxs/ [Personal] http://ariadne.iz.net/~jeffs/ [PGP] http://ariadne.iz.net/~jeffs/jeffs.asc [Project] http://xvrml.net/ -------------------------------------------- There are no bugs there are just undocumented features |
