[X3D-Public] authoring environments and browsers: why both?

Tony Parisi tparisi at vivaty.com
Tue May 12 17:19:22 PDT 2009

What he said


-----Original Message-----
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.

Alan Hudson

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 mailing list