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. _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
