[opensource-dev] Out of FOV rotating child prims update bug (was: Re: OpenSource reciprocal help)
On Tue, 18 Dec 2012 10:32:15 +0100, Henri Beauchamp wrote: > On Mon, 17 Dec 2012 16:18:59 -0500, Oz Linden (Scott Lawrence) wrote: > > > No, we can't, sorry. > > Did you ever say "yes" and actually provide any kind of useful help > to an OpenSource developer ?... I'm yet to find a case in which that > happened... > > You, know, the time I spend sorting out LL's mess, I don't spend it > providing you with bugfixes (even if, because of the stupid CA stuff, > I must find convoluted ways to contribute, such as the private emails > I already sent to you to point out and explain nasty bugs in your > code). > > FYI, there are currently two nasty bugs in the renderer code that I > was investigating: > .../... > - another, even more serious bug, deals with scripted, punctually > moving objects (sliding and rotating doors, for example), which > position fails to be updated in the renderer when they are off > the camera FOV; click on an auto-closing door to open it, then > turn away from it so that it's no more in the FOV and wait till > it closes automatically, then turn around again to face it: > surprise, it appears as still open (but it's not: you'd bump > into it and right-clicking on the spot where it should be makes > it render again) ! For what it is worth, I identified the bug that was preventing step-rotating (llSetRot()) child primitives to be properly updated while out of the FOV (the similar, sliding doors, issue was solved in a recent patch that made its way to viewer-development lately). The problem is in lldrawable.cpp, around line 562. You need to change: else if (!isRoot() && (!mVObjp->getAngularVelocity().isExactlyZero() || dist_squared > 0.f)) for: else if (!isRoot() && (target_rot != old_rot || dist_squared > 0.f)) This is because prims rotating with llSetRot() don't have a velocity. 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
Re: [opensource-dev] Current status on non-biped/giga|micro mesh avatars
> What is the current status on how SL handles mesh avatars that are not quite > "standard"?? > > as an example if im using a Dire Wolf mesh avatar (and its properly rigged) > will it work with quad animations?? > > Please do not just link to some semi random LL wiki page only link if it > covers large/small and or quad avatars. Your subject line seems to vary a bit from the contents of the email, and I'm having difficulty interpreting your question. I'm going to assume the following: -You are making a quadruped rigged mesh avatar. -You intend to create "micro" and "macro" versions of this avatar by resizing the mesh and reimporting it. -You are making a complete set of custom quadruped animations. And I'm going to assume your actual question is as follows: -Can I use the same animations I've created for a normal sized avatar on the micro and macro versions of the same avatar? If you've experimented with uploading rigged mesh at all, you'll notice that there is a "height offset" value that you can set. When uploading a macro or micro avatar, the primarily change will be modifying this offset so the figure stands with their feet set on the ground. I have not done experimentation regarding animations and scaled meshes myself, but whether your animations can be reused or not depends on how the hip height of the animation itself is handled depending on how the hip height is configured when uploading rigged mesh. If the animation's height is a proportion of the configured height, then a crouching animation will put your tiny avatar just slightly further towards the ground, a normal avatar a larger distance but the same proportion, and so on. Otherwise, if it's closer to an absolute value, your tiny avatar is going to drop underground while playing the normal sized avatar's crouch animation. You will also notice, as you experiment with the animations, that the motion of the feet of the walk animation from a normal sized avatar no longer lines up with the ground on different sized avatars. The speed the agent traverses the landscape is not configurable, so giants and tinies move across the ground at the same speed. When you scale the figure up, it needs to move the legs slower. Same with scaling down -- the legs need to move faster. Assuming I understood your question right (feel free to rephrase it if I did not so someone else can take a stab at it), your answer is "yes and no." And also "depends." Do some experimentation based on the above and let us know the result. However, I'm certain some of the animations will simply not work and need to either have their height adjusted for the different sizes of avatars, or have their timing adjusted. If your question is specific to animations and rigged mesh scales as I assumed, you may also find further help inworld under a group related to your 3D modeling program, or the Avatar Maker's Guild. Stickman ___ 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
[opensource-dev] Current status on non-biped/giga|micro mesh avatars
What is the current status on how SL handles mesh avatars that are not quite "standard"?? as an example if im using a Dire Wolf mesh avatar (and its properly rigged) will it work with quad animations?? Please do not just link to some semi random LL wiki page only link if it covers large/small and or quad avatars. -- Robert L Martin ___ 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
