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

Niclas Olofsson nicke.olofsson at gmail.com
Thu May 14 11:11:06 PDT 2009


Agree.

Tony Parisi skrev:
> What he said
> 
> Tony
> 
> 
> -----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
> application?
>> 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?
> Would 
>> 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.
> 



More information about the X3D-Public mailing list