[X3D-Public] containerField is should or must ? large attributes; compression
Tony Parisi
tparisi at gmail.com
Mon Aug 9 11:53:20 PDT 2010
As a practical matter I would not advocate changing the feature. Far
too late in the game. I was speaking more theoretically.
Tony
Sent from my iPhone
On Aug 8, 2010, at 6:24 PM, Don Brutzman <brutzman at nps.edu> 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
> --
> 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, virtual worlds, underwater robots http://faculty.nps.edu/brutzman
>
>
> _______________________________________________
> X3D-Public mailing list
> X3D-Public at web3d.org
> http://web3d.org/mailman/listinfo/x3d-public_web3d.org
More information about the X3D-Public
mailing list