[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