From brutzman at nps.edu Mon Jan 9 09:54:50 2012 From: brutzman at nps.edu (Don Brutzman) Date: Mon, 9 Jan 2012 09:54:50 -0800 Subject: [X3D educators] X3D event utilities: quick reference sheet available Message-ID: <4F0B29EA.4020107@nps.edu> The X3D event utilities provide simple conversions between time/boolean events, and also sequencing or triggering of integer and boolean values. I've prepared a quick reference sheet for the X3D event utility nodes. It shows input and output events, helping to keep track how to use these helpful nodes. Available at: X3D Event Utility Nodes: Field Event Diagrams http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter09-EventUtilitiesScripting/ http://x3dgraphics.com/examples/X3dForWebAuthors/Chapter09-EventUtilitiesScripting/X3dEventUtilityNodeEventDiagrams.pdf Comments and feedback on these diagrams are welcome. The images for each of these field signatures are also now provided in X3D-Edit when editing these nodes. This makes authoring just a little bit easier. Step by step, or event by event! https://savage.nps.edu/X3D-Edit all the best, Don -- Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149 X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman -------------- next part -------------- A non-text attachment was scrubbed... Name: BooleanToggleInterfaceX3D-Edit.png Type: image/png Size: 154948 bytes Desc: not available URL: From brutzman at nps.edu Sun Jan 15 22:58:08 2012 From: brutzman at nps.edu (Don Brutzman) Date: Sun, 15 Jan 2012 22:58:08 -0800 Subject: [X3D educators] [X3D-Public] X3D event utilities: quick reference sheet available In-Reply-To: <4F0B5638.5070907@gmail.com> References: <4F0B29EA.4020107@nps.edu> <4F0B5638.5070907@gmail.com> Message-ID: <4F13CA80.9010402@nps.edu> On 1/9/2012 1:03 PM, Michalis Kamburelis wrote: > Don Brutzman wrote: >> I've prepared a quick reference sheet for the X3D event utility nodes. >> It shows input and output events, helping to keep track how to use these >> helpful nodes. > [...] >> Comments and feedback on these diagrams are welcome. > > Very nice, but I found two errors. many thanks! thanks for patience with my reply. > Checked everything vs X3D 3.2 specification, and view3dscene, and InstantReality: > > 1. BooleanFilter: Both "inputTrue" and "inputFalse" are identity functions. "inputNegate" is not equivalent to "inputFalse" at all. That's how it works in view3dscene, specification, and tested with InstantReality also (easy to test using the "Logger" node, available in both view3dscene and InstantReality): > > - set_boolean=TRUE => inputTrue =TRUE and inputNegate=FALSE > - set_boolean=FALSE => inputFalse=FALSE and inputNegate=TRUE > > That is, inputTrue and inputFalse generate always the same value that was passed to set_boolean. They only filter it, as the node name suggests (inputTrue is not generated at all when set_boolean=FALSE is received, and vice versa). looks good, i was confused. interestingly, the spec seems slightly ambiguous: ============= 30.4.1 BooleanFilter http://www.web3d.org/files/specifications/19775-1/V3.2/Part01/components/utils.html#BooleanFilter "When the set_boolean event is received, the BooleanFilter node generates two events: either inputTrue or inputFalse, based on the Boolean value received; and inputNegate, which contains the negation of the value received." ============= > Test X3D boolean_filter.x3dv attached, available also in SVN on http://svn.code.sf.net/p/castle-engine/code/trunk/demo_models/event_utilities/ BS Contact 8 gave me the following error: Loading scene C:\Users\brutzman\Desktop\boolean_filter.x3dv VRML syntax error: line 2 in C:\Users\brutzman\Desktop\boolean_filter.x3dv: (PROFILE) Expected '{'; got 'I', non standard field ? VRML syntax error: line 2 in C:\Users\brutzman\Desktop\boolean_filter.x3dv: (PROFILE) Expected '{'; got 'I', non standard field ? seems to work fine in IR > 2. TimeTrigger and IntegerTrigger: set_boolean = FALSE is *not* ignored, it works the same as set_boolean = TRUE. In case of TimeTrigger, the specification expicitly says "The value of set_boolean shall be ignored." In case of IntegerTrigger, nothing is said about the meaning of set_boolean value, so I guess it's supposed to be ignored too, for consistency. i guess it should be consistent too. Spec bug submitted. i was thinking that the receipt of a 'false' event should be ignored as a way of keeping track of the semantic value of the event. a common authoring issue is the pairwise generation of true/false events when using TouchSensor isOver or isActive. it is more verbose to have to use a BooleanFilter each time, and actually that is different from our original design criteria which was to make these as simple as possible for authors to accomplish common use cases. the isOver/isActive true/false is a one-two punch that often leads to severe author or user frustration, because the only way that a user can get something done is to HOLD THE MOUSE AND NOT LET GO!!! which is a horrible design flaw. So I don't think that honoring 'false' events as a default behavior is a good idea. Such 'false' events can get special handling with needed, but in general their semantics seem to be, well, _false_ and so they should be ignored. therefore i've entered a second bug (which contradicts the previous one and the default behavior of TimeTrigger) to say that false events should be ignored for set_boolean to IntegerTrigger and TimeTrigger. this will lead to simpler authoring and more reliable constructs, i believe, if people check the issue out with commonly authored scenes. having it as a pair of bugs will ensure we consider it properly and collect the full rationale of pros and cons in the Mantis database. thanks Len for administering these for working group meetings, and hip hip hooray for Web3D Consortium being organized to support this. > This is tested by integer_trigger.x3dv, attached (available also inside http://svn.code.sf.net/p/castle-engine/code/trunk/demo_models/event_utilities/ ). If set_boolean=FALSE would be ignored, this test would fail when moving mouse out of the box --- IntegerTrigger with integerKey=0 would never fire. But it works, so set_boolean=FALSE is handled just like set_boolean=TRUE, both in view3dscene and InstantReality. understood, i think you are correctly consistent with the spec and look forward to further discussion to see if we can improve this further or not. > Regards, > Michalis updated .pdf attached, will upload tonight, again thanks all the best, Don -- Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149 X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman -------------- next part -------------- A non-text attachment was scrubbed... Name: X3dEventUtilityNodeEventDiagrams.pdf Type: application/pdf Size: 32395 bytes Desc: not available URL: From brutzman at nps.edu Mon Oct 1 08:51:07 2012 From: brutzman at nps.edu (Don Brutzman) Date: Mon, 1 Oct 2012 08:51:07 -0700 Subject: [X3D educators] announce: X3D Tooltips now provide full support Message-ID: <5069BBEB.9060607@nps.edu> I'm happy to report that the X3D Tooltips now provide full support for all nodes in X3D. X3D Tooltips http://www.web3d.org/x3d/content/X3dTooltips.html The X3D tooltips provide summary descriptions and authoring hints for each X3D node (element) and field (attribute) in the version 3.3 specification. They provide context-sensitive support for authors and tools, with each node also providing appropriate links to the X3D Abstract Specification, the X3D Schema Documentation and the X3D DOCTYPE Documentation. Recent work includes: - addition of missing nodes from X3D version 3.2 - Separate Reference Version tooltips for X3D version 3.3, 3.2, 3.1 and 3.0 tooltips - Additional languages include Chinese, French, German tooltips, Italian tooltips, Portuguese and Spanish tooltips. These are current as of X3D v3.1 (meaning the majority of nodes). - Explanatory sections regarding accessType and type declarations, excerpts follow. I hope that everyone finds these useful. I frequently refer to them when authoring or teaching X3D. If anyone is interested in updating any of the X3D Tooltips in other languages, please let me know. I can develop some diff scripts that will show differences with the complete Tooltips. As ever, comments questions and improvements are welcome. Have fun with X3D! ===================================================== accessType Definitions accessType determines whether a field corresponds to event input, event output, or persistent state information. Events are strictly typed values with a corresponding timestamp. ROUTE connections must match accessType between source field and target field. initializeOnly: can be initialized, but cannot send or receive events. This is usually the case for fields that are too computationally expensive to change at run time. initializeOnly: can be initialized, and can also send or receive events. This is usually the case for fields that are too computationally expensive to change at run time. inputOnly: cannot be initialized or included in a scene file, but can receive input event values via a ROUTE. outputOnly: cannot be initialized or included in a scene file, but can send output event values via a ROUTE. X3D accessType design keeps 3D graphics rendering fast and interactive, also helping to keep X3D players small and lightweight. ===================================================== type Definitions Data types classify the possible values for a variable. X3D is a strongly typed language, meaning that data types must match for a scene to be correct. Each field in each node (i.e. each XML attribute) has a strictly defined data type. Multiple data types are provided for boolean, integer, floating-point and string values. Each of the base types are either single-value or multiple-value. Examples: SFFloat (single-value), SFVec2f (2-tuple), SFVec3f (3-tuple), SFOrientation (4-tuple for axis-angle values). Arrays are also provided for all base types. Nomenclature: SF = Single Field (single value of base type), MF = Multiple Field (array of base-types). The X3D Schema is able to validate numeric type information and array tuple sizes in X3D scenes for initializeOnly and inputOutput field initializations that appear within an X3D file. ROUTEs pass events, which are strictly typed values with a corresponding timestamp. ROUTE connections must match type between source field and target field. Since they are transient, event values themselves cannot appear within an X3D file. For MF multiple-field arrays, commas between values are normally treated as whitespace. However, X3D Schema validation will not accept commas that appear within vector values, only between values. MFColor examples: color="0.25 0.5 0.75, 1 1 0" is valid while color="0.25, 0.5, 0.75, 1, 1, 0" is invalid. This is an authoring assist to help authors troubleshoot errors in long arrays of values. Failure to match data types correctly is an error! Types must match during scene validation, scene loading, and at run time. This is A Good Thing since it allows authors to find problems when they exist, rather than simply hoping (perhaps mistakenly) that everything will work for end users. Several Extensible Markup Language (XML) data types are also included in these tooltips. CDATA is an XML term for Character Data. The base type for all XML attributes consists of CDATA characters. CDATA is used throughout the X3D DOCTYPE definitions, which can only check for the presence of legal strings and thus are not able to validate numeric type information. Strictly speaking, a few CDATA attributes (such as those for the meta element and other elements appearing inside the head element) are not fields of X3D nodes and thus do not have corresponding X3D data types. FIXED indicates that no other value is allowed. When used with an empty string "" value, this is used to indicate that X3D inputOnly and outputOnly fields are not allowed to appear in an X3D file. ID is a NMTOKEN that is unique within the scene, corresponding to the DEF label in X3D. IDREF is a reference to one of these unique scene IDs, corresponding to the USE label in X3D. NMTOKEN is an XML term for Name Token. NMTOKEN is also a CDATA string but must also match naming requirements for legal characters with no embedded spaces. The following table provides a complete list of X3D data type names, descriptions and example values. [...] ===================================================== all the best, Don -- Don Brutzman Naval Postgraduate School, Code USW/Br brutzman at nps.edu Watkins 270, MOVES Institute, Monterey CA 93943-5000 USA +1.831.656.2149 X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman