Re: [x3d-public] Native 3D in web browsers

[Braden McDaniel <braden@endoframe.com>]

On Sun, 2007-12-30 at 15:38 +0000, Philip Taylor wrote:
> Is there an
> (unwritten?) understanding that browsers should just ignore the
> profile and try to render as much as they can? (If so, what if the
> high-profiled content is used in an Inline node where there's meant to
> be particular rules for handling profiles?)

I don't think there's any such understanding.

> > > A lot is implementation-defined (e.g. the maximum number of vertexes
> > > supported),
> >
> > Minimum support requirements for such things are defined per profile.
> > See, for example:
> >
> > <http://www.web3d.org/x3d/specifications/ISO-IEC-19775-X3DAbstractSpecification/Part01/interchange.html#OtherLimitations>
> 
> I'm not sure that helps, since the maximum number is still not defined
> and it sounds like browsers should try to handle files which exceed
> the "X3D File Limit". So there's still the problem where:
> * Browser A supports 32K vertices per mesh, because the spec said
> that's acceptable.
> * Browser B supports 16K vertices, because the spec said that's acceptable.
> * Author C creates a file with 20K vertices (not noticing it exceeds
> the limit) and tests it in browser A and everything works fine.
> * User D uses browser B and finds it doesn't work on author C's
> content and so they switch to browser A.
> * Browser B's developers don't like losing users, so they increase
> their vertex limit.
> * Repeat until eventually all browsers support 2^32 vertices and run
> out of memory if you try to really use that many, and there was some
> wasted effort before reaching that stable end point.
> 
> Is there anything to stop this kind of problem in practice?

Why is this an actual problem that needs solving? It's a fact of life
that all viewers on all devices won't be able to render all content.
That's by no means particular to 3D. Do you also think HTML should
specify, for instance, a maximum number of permissible rows for a table?
If not, what's the difference?

> (I can't think of any way X3D could handle this better, other than
> encouraging implementors to initially support 2^32 of everything so
> that nobody will reach the limit (but that's bad for
> simplicity/performance in the more common cases). Unfortunately it's
> still a problem even if there is no good solution...)
> 
> > > and implicitly
> > > undefined (e.g. what happens if you try to IMPORT something that
> > > wasn't EXPORTed).
> >
> > It's not clear to me how that would be anything other than an
> > error [...]
> 
> It's not clear to me what "an error" entails - does the X3D browser
> just shut down and show an error message, until the user leaves and
> loads something else? Does it ignore the problem and continue as if
> the IMPORT wasn't there (and then ignore any ROUTEs pointing at the
> IMPORTed object, etc)?

"An error" entails a circumstance that a content developer ought to
avoid. Trying to normalize failure modes across implementations (and,
necessarily, devices) seems likely to be a very difficult task. (And one
whose yield seems unlikely to scale well.)

> I was thinking mostly of CSS2.1 and HTML5, which specify how to do
> graceful error recovery (unlike XHTML, which says well-formedness
> errors are fatal and doesn't mention any other types of error) - e.g.
> the HTML5 parsing algorithm defines how to convert every conceivable
> string of characters into a DOM tree. Web browser developers seem to
> appreciate that, since the same approach is being consciously used on
> other specifications which they are involved with (XBL2,
> XMLHttpRequest, Selectors API, etc). (I was wrong to just say "modern
> web specifications" and should have been more specific - I've been
> following HTML5 for quite a while so my perspective is somewhat
> distorted!)

In theory I like that approach. In practice it can easily suffer from
the same old problem: inconsistent conformance among implementations.
C++ takes a similar tack. However, nearly a decade after formal
standardization, the consistent parse is one of relatively few things
certain implementations continue to ignore.

You say there appears to be uptake and that's good. But HTML5 is still,
AFAIK, unfinished; and its ultimate popularity, pervasiveness, and the
conformance of implementations are all unknown.

Do you have an idea of how widespread correct implementation of CSS
2.1's parsing rules is? (I'd expect this to be an easy one, though,
since CSS syntax is so simple.)

> > A DOM tree just doesn't seem to map particularly well to the understood
> > notions of a scene graph.
> 
> I agree that reusing CSS/SVG/DOM/etc would probably be an
> inappropriate choice for X3D. But that still means an X3D
> implementation isn't easier to create when it's inside a web browser -
> it would still have to be implemented largely from scratch (or copied
> from an existing library), as a separate component from the rest of
> the browser, so there isn't any integration benefit that would make it
> a natural choice for web browsers to implement. (Compare to e.g. SVG
> itself, which uses CSS and DOM and works in compound documents with
> XHTML, which makes it much more webby and more sensible for web
> browsers to implement. And it's still taken them years and does not
> have good interoperability.)

Yes; X3D has done a sufficiently bad job of pursuing the
aggregate-namespace XML document context that the space is ripe for
someone to pick up the ball and learn from its mistakes. :-)

For better or for worse, the DOM is indeed what one must deal with in
this context. The known limitations or difficulties with respect to
mapping to a scene graph are probably one reason that X3D's designers
haven't pursued this space aggressively. But there is a clear payoff if
this can be made to Not Suck.

> > > My current thought is that X3D can be used as that
> > > higher-level API, implemented purely in JavaScript on top of the web
> > > browser's low-level rendering API.
> >
> > I am skeptical that one could achieve acceptable performance this way;
> > but I could be wrong.
> 
> That's certainly a valid concern. Is there any information available
> on what is important for performance in current X3D browsers? (Memory
> usage for scene nodes?

Not generally a huge issue AFAICT. Large models/worlds tend to be heavy
in terms of geometry data rather than the number of nodes.

>  DEF lookups?

Unlikely to be a problem, IME.

>  Event routing?

Must be fast. You can't afford to do things like string comparisons
per-propagation.

>  Dynamic scene
> changes?

To general for me to comment on.

>  Traversing the scene for rendering?

Obviously frame-rate critical, so needs to be fast. You can do some
clever things like culling subtrees that aren't in the viewing volume.

[snip]

> I'm not sure what's a good tradeoff between following the spec, and
> extending it when a 'better' (easier to implement (for me), easier to
> understand, more powerful, etc) solution is available. I expect I'll
> have to worry about that more if I ever get past the proof-of-concept
> stage, which might take a while (if it happens at all).

When in doubt, take the easy way. :-)

I'd say if you've opted not to follow (at least some profile of) the
spec, be merciless. Do what works and don't be shy about tossing out
stuff that seems hard or just plain weird.

-- 
Braden McDaniel                           e-mail: <braden@endoframe.com>
<http://endoframe.com>                    Jabber: <braden@jabber.org>


-------------------------------------------------------------------------
for list subscription/unsubscription,
go to http://www.web3d.org/cgi-bin/public_list_signup/lwgate/listsavail.html