[opensource-dev] Review Request: BUG-1709: Tiny prims do not rescale properly at very high viewer framerates

Henri Beauchamp sldev at free.fr
Mon Feb 18 01:48:12 PST 2013


On Mon, 18 Feb 2013 10:44:21 +0100, Henri Beauchamp wrote:

> On Mon, 18 Feb 2013 03:02:40 -0000, MartinRJ Fayray wrote:
> 
> > I fixed that by comparing the original scale versus the new target
> > scale (instead of comparing the original scale versus the new
> > interpolated target scale), in lldrawable.cpp "updateXform" to decide
> > whether a scale change requires an immediate rebuild or not.
> 
> Yes, the child primitive is properly resized in this case, BUT, it
> snaps to its new size instead of resizing smoothly (which basically
> means that the server side smooth resizing is done for nothing at
> all !...). It's not very pretty and I'm pretty sure some makers and
> vendors of scripted items (especially the ones with apparent
> "mechanics" in their products) will not like it...
> 
> Granted:
> LLVector3 vec = mCurrentScale - dest_scale;
> if (vec * vec > MIN_INTERPOLATE_DISTANCE_SQUARED)
> 
> causes less stress than:
> if (old_scale != target_scale)
> 
> But it's pretty rethorical and theorical since I'm still to see
> a sim where thousands of child prims would resize simultaneously
> to have high enough an impact on the frame rate in the second
> case...

Addendum:

I guess you could do the stepped resizing for non-visible prims (you
could even increase the steps size) and do smooth resizing for visible
(in FOV) prims...

Henri.


More information about the opensource-dev mailing list