[#VWR-380] Resized Flexible Prims Render Improperly

1. Second Life Viewer - VWR

Resized Flexible Prims Render Improperly

Created: 04/Apr/07 03:31 PM Updated: 29/Jul/09 05:58 PM

Return to search

Component/s:

Graphics, Scripting

Affects Version/s:

First Look: Render Pipeline, 1.14.0.x, 1.20

Fix Version/s:

1.20 Release Candidate

Environment:

Windows XP, 1MB RAM, Geforce Go 448/64, Geforce 6600/256, ATI Radeon 1300/128,

Issue Links:

Relates

This issue Relates to:

SVC-38 llSetPrimitiveParams has issues with multiple parameters in one call

This issue is related to by:

VWR-332 LSL translate and rotate interpolate at different rates (Was: Scripted prim movement rendered differently when object is selected)

~~VWR-528~~ llSetScale fails on Flexi Objects

Linden Lab Issue ID:

DEV-3803

Description

« Hide

llSetPrimitiveParams is used by the children to resize the prims and move them around a central parent prim so that the entire object resizes properly.

When the prims are rigid, they rezise and move correctly. When the prims are flexible, they also resize and move correctly but they do not appear to be properly sized and aligned in the viewer. They generally appear either too thin or too tall (scrunched) and too far away from the central parent prim.

Selecting the object with the editor pops them into proper perspective so I know the LSL is functioning properly and the viewer is getting the correct settings. The viewer is simply not rendering the object properly. Myself and two others have reproed this using Nvidia and ATI all staring at the same objects and seeing the same wonkiness.

When the prims are made non-flexible, the effect works as expected. When the prims are reflexed, the misrepresentation functions as before.

I can provide samples or the script to a Linden who's attempting to reproduce the effect.

All

Comments

Change History

Sort Order:

[ Permlink | « Hide ]

Khamon Fate added a comment - 04/Apr/07 09:26 PM

Update: the misrendering only occurs when llSetPrimitiveParams resizes and moves the children, not when they are simply resized and left in place. It's apparently an issue with properly rendering flexible child prims that have been moved by a script.

[ Permlink | « Hide ]

Khamon Fate added a comment - 06/Apr/07 10:15 AM

One more clarifcation, we only see this effect when child prims are being offset to the object using llSetPrimitiveParams(). Not when the entire object is moved by a script.

[ Permlink | « Hide ]

Kothlak Balhaus added a comment - 31/May/07 10:51 AM

I am not sure if this is the right place to post this, but I have been having problems with flexible feature while building for 3 weeks or more, now. And I am not sure if it is a client based problem or not, or that anyone else is having the same issue. But when I make a prim and turn on the flexible feature, then try and change the size of it, wheather manually or by changing the nimbers...it does not change size. In the "stretch" mode, the bounding box changes to the size I make, but the actual prim does not. I have found I have to do one of 2 things to get the prim to change size. (1) zoom out away from the prim, it will change. (2) turn the flexi feature off, then back on. This is minor, but somewhat annoying.

[ Permlink | « Hide ]

WarKirby Magojiro added a comment - 18/Aug/07 12:07 AM

I can confirm this too. Happens wenever you resize a flexiprim in a linkset. Unlinked flexis work fine, but those which are linked requirte some addditional editing to make the effect show.

[ Permlink | « Hide ]

Soft Linden added a comment - 27/Aug/07 03:08 PM

This is getting imported, but please add a script example or clear repro instructions - devs grab things faster that include an easy repro.

[ Permlink | « Hide ]

Gigs Taggart added a comment - 19/Oct/07 01:59 AM

llSetScale() doesn't behave properly if the Flexible property is enabled.

To Reproduce:

1. Rez a cube, and put this script in it:

integer Big = TRUE;

default
{
touch_start(integer total_number)
{
if (Big) { llSay(0, "Scaling little"); llSetScale(<.2, .2, .2>); } else { llSay(0, "Scaling big"); llSetScale(<.5, .5, .5>); }
Big = !Big;
}
}

2. Touch the cube, see that it toggles big and small.

3. Go to the Features tab and enable Flexible.

4. Touch the cube again, see that it doesn't scale properly any more.

[ Permlink | « Hide ]

WarKirby Magojiro added a comment - 23/Mar/08 10:37 PM

Soft, any updates on this? I'm running into it with my current project, and it's really being a nightmare

This issue has been around a long time :/

[ Permlink | « Hide ]

WarKirby Magojiro added a comment - 23/Mar/08 10:47 PM

The only workaround I can find that works is setting the object to non flexible before doing the transform, and flexible again after. Trying to force an update with llSetText or similar only half works

[ Permlink | « Hide ]

Mo Noel added a comment - 24/Apr/08 06:04 AM

I experience the same.
My workarround is to toggle flexi after the resizing.
This supplies a much better look, but does not work all time.
In facr with the latest viewers it seems to work worse.

[ Permlink | « Hide ]

nya Linden added a comment - 05/Jun/08 05:33 PM

this has been fixed and released in 1.20 RC3

[ Permlink | « Hide ]

Kayla Stonecutter added a comment - 03/Aug/08 01:36 PM

This issue is present in Release viewer 1.20.15 (92456). The script posted by Gigs Taggart works fine with a normal prim, but does not render properly with a flexi prim. The issue with scripted prim move using llSetPrimitiveParams is also messing up, showing the prim as a long thin prim when it should be at minimum size for all three axis.

[ Permlink | « Hide ]

Kayla Stonecutter added a comment - 03/Aug/08 01:43 PM

Changed 'Affects Version/s' to v1.20.

[ Permlink | « Hide ]

Harleen Gretzky added a comment - 03/Aug/08 10:27 PM

Still happens for me in 1.20.15 also.

[ Permlink | « Hide ]

Bloodsong Termagant added a comment - 29/Jul/09 05:58 PM

1.22

still wrong!