[X3D-Public] authoring environments and browsers: why both?
tparisi at vivaty.com
Tue May 12 17:19:22 PDT 2009
What he said
From: x3d-public-bounces at web3d.org [mailto:x3d-public-bounces at web3d.org]
On Behalf Of giles
Sent: Tuesday, May 12, 2009 5:17 PM
To: John Carlson
Cc: X3D Graphics public mailing list
Subject: Re: [X3D-Public] authoring environments and browsers: why both?
John Carlson wrote:
> Why are there both authoring environments and browers/players?
> Shouldn't a browser be able to support/deliver an authoring
> I realize the same dichotomy has existed with HTML as well--but there
> are HTML browsers which support editing, right? Is there something
> missing from VRML/X3D which only authoring environments provide?
> providing these within the context of VRML/X3D make a better standard?
A system optimized for playback is architected fairly different then one
made for authoring. Authoring systems are typically about flexibility
with lots of extra data floating around. Browsers are typically about
the fastest, smallest playback of the content.
Doesn't mean you can't combine them but I doubt a combined version would
be as performant as an optimized player.
A simple example from the spec would be an ElevationGrid. Its height
field is not an input/output field. So a browser can in theory throw
away the height data after it has generated the triangles needed. An
authoring application cannot as you might wish to edit those values.
Tradeoffs like this abound in the spec. Ie VRML and X3D have left many
places where a browser can optimize playback by not having to honor
requests for data in its original form.
President Yumetech, Inc. www.yumetech.com
President Web3D Consortium www.web3d.org
206 340 8900 ext 111
Open Source CAN be free, as in "free puppy"
X3D-Public mailing list
X3D-Public at web3d.org
More information about the X3D-Public