[Source] [X3D-Earth] Xj3D property setting for origin manager, for inclusion in X3D-Edit

chris dragonmagi at gmail.com
Fri Jun 5 20:36:33 PDT 2009


ok, no worries, thanks for spending the time to explain,

chris

2009/6/6 Rex Melton <rex.melton at comcast.net>

> chris wrote:
>
>> thanks Rex, yeah that all makes sense, just one more query on the last
>> point:
>>
>>
>> 2009/6/6 Rex Melton <rex.melton at comcast.net <mailto:
>> rex.melton at comcast.net>>
>> ....
>>
>>    A straight line calculation certainly is more efficient than the
>>    orthodromic distance. However, the elevation threshold is set
>>    rather high by default (50km) for a variety of reasons. A straight
>>    line distance from the established origin to the viewpoint would
>>    incorporate the elevation. Adding that component to the distance
>>    threshold would cause recalculations more frequently than would
>>    really be necessary. In other words, in order to keep the amount
>>    of recalculation down, only the 'lateral' distance from an
>>    establish origin is considered (and necessary I think) and not the
>>    vertical. Hope that makes sense..... If not, let me know and I'll
>>    try to explain it again.
>>
>>
>> So if you make the threshold distance greater, you could use the more
>> efficient calculation, e.g. comparing distance^2 to threshold^2? I remember
>> that geovrml scaled speed based on elevation, so one could also scale
>> threshold similarly.
>>
>
> The orthodromic distance calculation only happens once per frame. Overall,
> it's not that expensive. On the order of a matrix multiply.
>
> What IS expensive is recalculating all the geo-coordinates that are loaded
> in the scene to account for a newly established local origin.
>
> The trade-off you suggest may produce a miniscule performance increase per
> frame. But will likely introduce a recalculation penalty more frequently.
> Overall, I think it would negatively impact performance.
>
>  Presumably, the content developer could also tweek the distance based on
>> amount of jitter and framerate.
>>
>
> At present, the thresholds are configured with properties at browser
> instantiation time. They -could- be exposed for an application to manage.
>
> I don't consider this approach to be more than a temporary proof of
> concept. Spec wise - GeoOrigin will likely be removed or deprecated. How
> that gets managed by a browser should be transparent to the user.
>



-- 
http://www.vrshed.com
There be greater truth at the centre.
http://www.floatingorigin.com

Association of Virtual Worlds, http://associationofvirtualworlds.ning.com/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://web3d.org/mailman/private/source_web3d.org/attachments/20090606/16ca3e2a/attachment-0001.html>


More information about the Source mailing list