[X3D-Public] containerField is should or must ? large attributes; compression

[Dave A]

Has anyone looked at OgreXML? Here's some snips:

<mesh>
    <submeshes>
        <submesh material="chocolate_molecule_red" 
usesharedvertices="false" use32bitindexes="false" 
operationtype="triangle_list">
            <faces count="1920">
                <face v1="738" v2="771" v3="739" />
                <face v1="772" v2="773" v3="740" />
                <face v1="739" v2="772" v3="740" />
....

and

            <geometry vertexcount="1118">
                <vertexbuffer positions="true" normals="true" 
texture_coord_dimensions_0="2" texture_coords="1">
                    <vertex>
                        <position x="374.138" y="579.34" z="45.8618" />
                        <normal x="-0.195073" y="-2.29564e-007" 
z="0.980789" />
                        <texcoord u="1" v="0.0625" />
                    </vertex>
....

Not sure by they may be relying on the order of the vertices, so maybe 
it should be
<vertex n='1'>
where 'n' is the vertex ordinal.

Or consider the following:

<Shape>
    <IndexedFaceSet>
       <Vertices>
          <SFVec3f n='0' x='.3' y='1' z='0' /> or
          <Vector type='SFVec3f' n='0' x='.3' y='1' z='0' /> or
          <Vertex n='0' x='.3' y='1' z='0' nx='1' ny='2' nz='-1' u='.2' 
v='3'/> or....

where 'n' is the 'index' in the IFS
       </Vertices>
       <Faces>
          <Triangle v1='0' v2='1' v3='2' />   where these attrs index 
into the vertices above, or
          <Face>
             <v='0'/>
             <v='1'/>
             <v='2'/>   where these are the vertex indices, but this 
relies on the order found in the file, not good practice,so...

          <Face>
             <nv='0' v='1'/>
             <nv='1' v='2'/>
             <nv='2' v='3'/>  where nv defines the index order, and v is 
the vertex index.

As far as containment and validation: Basic DTD stuff will define what 
is allowed (and how many/how few) in
any thing. So forget about 'children' fields as defined in VRML, and 
'containerField' attributes in current X3D. Just BE children, contained 
in the thing that makes sense. Shape contains zero or one Appearance, 
Appearance contains zero to many Material, Shape also contains one (or 
more? but not zero) of Box, Cylinder, IFS, etc. What would cause problems?

Here's something else to toss into the mix while thinking about this:

    <Material DEF='myColor'>
       <diffuseColor r='1' g='0' b='0' IS='truckColor' />
       <ROUTE from='script.colorOut.r' to='myColor.diffuseColor.r'/>

Too much?

Cheers

Dave A

Don Brutzman wrote:
> [summary:  lookouts have sighted large icebergs ahead, port and 
> starboard...]
>
> On 8/6/2010 8:18 AM, Alan Hudson wrote:
>> On 8/5/2010 6:59 PM, Tony Parisi wrote:
>
> actually Braden wrote the second-level quote, i believe:
>
>>  >> There's no question that containerField is made necessary by other
>>  >> aspects of the XML encoding. Unfortunately, time has shown that 
>> those
>>  >> aspects are themselves poor design choices.
>
> certainly our knowledge and skills have grown over time, which is good.
> however not sure what "poor design choices" means.
>
>>  >> fieldValue wrapper nodes were talked about some months ago as an
>>  >> approach to resolve issues with overly large attribute values. These
>>  >> wrappers also render containerField unnecessary; and in light of 
>> their
>>  >> availability, it probably makes sense to deprecate containerField.
>
> well, <fieldValue> element certainly is an interesting alternative 
> possibility.
> especially since that functionality has already been implemented as 
> part of
> ProtoInstance.  this would seem to minimize "language bloat" issues.
>
> so the idea is appealing.  has anybody yet:
> - implemented it in a player, or estimated the work-effort involved?
> - written an entry for the X3D v3.3 proposed changes wiki?
> - written potential prose for the specification?
>
> http://www.web3d.org/membership/login/memberwiki/index.php?title=X3D_v3.3_Specification_Changes 
>
> p.s. discussion topic for next Wednesday's call:  can this wiki go open?
>
> also has anybody yet:
> - estimated the impact on X3D scenes?  for Immersive Profile, the
>   Collision proxy example is well known.  however there are a
>   number of advanced components (shaders, layers/layouts, nurbs etc.)
>   where the clutter/obfuscation of parent-child node relationships
>   in a scene might become severe.  heck, we're still having trouble
>   collecting examples for several of these using any syntax.
>
> those 4 points are paths forward that allow us to implement/evaluate.
>
> any fix needs to be carefully scoped to avoid the "wrapper tag"
> morass of a decade ago.  it also helps if a fix has a corresponding
> problem statement, so we can measure whether proposed solutions are
> useful...  which leads us to the next potential iceberg:
>
>> As it stands now we avoid the XML encoding for any real sized files. I
>> am a fan of being able to completely validate the file. So when I teach
>> X3D I use the XML encoding to help them catch errors. But for
>> production usage we stick with .x3dv or .x3db.
>
> well we have something like 3000 examples online and they feel pretty
> real, especially since they are debuggable thanks to XML validation.
> there are a _lot_ of production XML applications and parsers available.
>
> the .x3d XML versions are also best for maintaining "master" copies in
> version control, since conversion into other forms is easier when you
> start from XML.  those conversions from .x3d to .x3dv .x3db .html and
> .wrl are also automated.  if someone rewrote the XSLT converters using
> SAX or STAX then likely any memory issues associated with conversion
> would go away.
>
> for jumbo attributes, it was pointed out that parsing problems are a
> problem of the implementation, not X3D or XML design.  wondering if any
> bug reports were submitted, wondering if any better parsers have been
> found.
>
> another pretty simple solution to jumbo attributes is to split a huge
> node into multiple smaller nodes.  of note is that there are maximum
> limits to geometry size specified in the specification, these are found
> in each of the X3D Profile definitions in the specification itself.
> for example
> http://www.web3d.org/x3d/specifications/ISO-IEC-19775-1.2-X3D-AbstractSpecification/Part01/immersive.html 
>
>
> table excerpt for IFS:
>> IndexedFaceSet 10 vertices per face. 5000 faces. Less than 15,000 
>> indices. 10 vertices per face. 5000 faces. 15,000 indices in any 
>> index field.
>
> the ConformanceNist Test Suite has a number of test scenes designed to
> check player conformance with specification limits.  it was designed to
> VRML97 parameters but most of those required-support values carried over
> unchanged to X3D.  Links and 5000-face IndexedFaceSet example  are at:
>
> http://www.web3d.org/x3d/content/examples/ConformanceNist
> http://www.web3d.org/x3d/content/examples/ConformanceNist/Geometry/IndexedFaceSet 
>
> http://www.web3d.org/x3d/content/examples/ConformanceNist/Geometry/IndexedFaceSet/5000faces.x3d 
>
>
> A quick test of this scene in BS Contact, Instant Reality, Octaga and
> Xj3D rendered speedily and without any console complaint.
>
> checking the spec, comparing it to the test suite, and creating more
> test scenes is a useful way to contribute, if anyone is interested.
>
> If the question is "how big is required?" then spec has already answered.
> If the question is "how big do you want to go?" then that seems to need
> further justification.  Anyone can pick an abitrary number, anyone
> else can double that, etc. etc. which isn't very helpful.  Working
> through a precise rationale for the correct amounts of geometry support
> is certainly important, especially if we hope to converge on an
> implementable/deployable Mobile Profile.
>
> regarding "what problem are we solving?" i hope it is worth pointing out
> that the .x3d XML encoding currently meets all design requirements of
> the X3D Specification.
>
> of course any worry about jumbo attributes might also be reduced a bit
> by the X3D Compressed Binary Encoding.  perhaps more people could help
> with that?  i hope to discuss possible code changes to ParaView with
> Kristian Sons this week, and NPS will try to match the changes in Xj3D
> if we can.  getting the X3D Specification examples converted into .x3db
> equivalently is our final milestone to complete the approval process
> for the recent last-minute errata fixes we submitted  to ISO.
> http://www.web3d.org/x3d/content/examples/Basic/X3dSpecification
>
> if we look to the XML community to see who else is interested in
> performance of really large numeric scenes, then a lot of work
> is found in the standards effort for Efficient XML Interchange (EXI).
> EXI is a W3C Candidate Recommendation.  http://www.w3.org/XML/EXI
>
>
> any way, it is good to know there is still interest in grappling with
> these and other challenges.  hopefully these dialogs will help our
> big group continue to grow in our common understanding of goals and
> solutions.
>
> all the best, Don