|
|
|
Darien Caldwell made changes - 28/Jan/08 01:06 AM
whatever the cause they're going to have a lot of pissed off content creators (myself included) if they don't fix this since it will (for lack of a better term) break a huge amount of content.
I've seen the same differences testing this for repeatability at The Omega Concern and Fulda Gap sims. This could be a show stopper issue as it will affect a LOT of furniture.
Darien Caldwell made changes - 03/Feb/08 07:37 PM
Darien Caldwell made changes - 03/Feb/08 07:37 PM
Darien Caldwell made changes - 03/Feb/08 07:38 PM
Darien Caldwell made changes - 03/Feb/08 07:38 PM
I'll import this bug and we'll talk about this issue again internally... I had a few weeks ago noticed that sit targets seemed somewhat different in Havok4, but here's the thing I wonder about... In the cases that I tested, with animation overrides off, they seemed very close or identical, whereas with animation overrides on they seemed to vary. The bizarre part, which frankly I'm not sure what to do with, is that depending on the furniture I've seen sit locations be higher or lower with Havok4.
Now before everyone gets completely cranked up about this, I suspect that if you wander around in Havok1-based regions with various AO"s on, and try various furniture, you'll find that sit locations seem to be pretty inconsistent. From what I have seen so far, Havok4 may be different in some cases, but I am not yet convinced that it diverges in a systemic way from Havok1 - in other words individual items might be different but in general it seems no more "generally mismatched" in sit location than Havok1 was (which wasn't very consistent to start with). Please feel free to show me otherwise - I'm all ears, and what I'm writing here is initial observations. We have talked about this and this seemed to be the team consensus... Thanks, Sidewinder
lindenrobot made changes - 05/Feb/08 09:44 PM
Actually your observations would be in agreement with what I have seen. First I want to point out the pictures above were with AO off. AOs can and do cause all sorts of variations, I agree. But that variable is eliminated above. I suspect that rotation is playing a role here too, so depending on the rotation associated with the sit target, the offset can go any direction, up, down, or even to the side. As I see it will take more conclusive evidence to convice the team, I'll see what I can do to provide that evidence.
I have added two pictures, H1 Sit part2 and H4 sit part2. This is again the same setup, in an H1 sim and a H4 sim, this time with the sit target set to: vector sit_pos = <-1.0, 0, -0.5>; As you can see, the avatar is now rotated 90 degrees to the chair. Note the distance between the knee and the top of the chair. In the H1 sim, the Avatar is farther away from the chair as compared to the H4 sim. This directly matches to what is seen with -90 degrees rotation, with H1 sit being lower down than the sit in H4. So I think this could account for the differences seen as mentioned. The offset always appears to be in one direction (the X direction as defined by the sit target), however the rotation can alter the apparent offset in world. Next question, how much of an offset is there? Doing a lot of jumping back and forth, I came up with a difference of 0.05 meters. (It was conicidentally during all this that I found a new bug Let me reiterate, All conditions between H1 and H4 are the same, except for Server version. Same AV, no shoes, no AO, nothing else. I feel i've outlined the issue as best I can, and thus, I rest my case.
Darien Caldwell made changes - 06/Feb/08 12:44 AM
Darien Caldwell made changes - 06/Feb/08 01:07 AM
Sidewinder, I urge you to read the thread I linked to above. I don't remember clearly enough to be able to describe in perfect detail what's wrong with the old H1 llSitTarget(), but I know that it's not doing what one would expect it to do. There's a systematic offset built into llSitTarget() that seems to be based on the rotation of the prim setting the sit target, and I'm certain that I ruled out avatar animations as the culprit in this.
Here's how I ran into this weird behavior: I was attempting to make an "Easy sit target setter" tool. The idea is that you'd be able to easily set the sit target on any prim that's at any rotation, for example some random prim of a piece of furniture that's not at a "nice" rotation. You'd sit on a separate poseball prim, then move that prim so that your avatar was sitting correctly on the furniture, and then a script would calculate what llSitTarget() parameters would need to be set on the furniture prim in order to land your avatar in exactly the same place. The calculations seemed like they should be fairly simple, but it turned out that they weren't. I checked my math over and over (and it was simple math), and I had Seifert Surface check it with me. Both of us are quite well versed in quaternion math. No matter what we did, if the rotations of the poseball prim and the target prim were different, then the theoretically mathematifcally "correct" sit-target on the target prim would "miss" by some amount less than a meter, every time. I'm certain this means that there's some weird offsetting happening in llSitTarget() as it currently exists on the grid. I spent hours carefully plotting out what this offset was and finally managed to write some code that compensated for it, so that my Easy Sit Target Setter can always take a sit target on any one prim and translate it into a matching sit target on another prim that puts the avatar in the exact same spot. The offsets we're seeing in havok 4 look to me like they might be simply caused by the fact that havok 4 doesn't include this bizarre offset. I'm all for fixing the bug, but in doing so, you're going to break a lot of content, so be careful! Not sure what this is, Lex, but I suspect it's something other than a change in the previous llSitTarget() glitch. You and I attacked that problem kinda backwards of each other in that thread, but the method I used for finding the glitch values is yielding the same results in Havoc 1 and Havoc 4 regions (assuming Caledon and Caledon SteamSkyCity are running Havoc 4, as I believe them to be). (The glitch explored in that thread was objectively measurable because the seated agent position-
EDIT: crap! Des must have had Caledon rolled back to Havoc 1, at least while I was testing. I just retested on Strathnaver and indeed the glitches are different between the two Havoc versions. I'll try to calculate exactly what the new constants are and post back. So sorry I jumped to the wrong conclusion before. EDIT 2: Indeed, I'm pretty confident it is exactly this glitch that differs. In Havoc 1, the avatar's position is offset from the sitTarget by a constant <0, 0, -0.4> in the prim's orientation, minus 1/37.9 of the avatar's height in the sitTarget's Z direction. In Havoc 4, this latter offset doesn't occur. So, llSitTargets set in Havoc 1 will correct for both of these factors, but in Havoc 4, where the sitTarget-oriented offset doesn't occur, the avatar is located upward from the sitTarget in the direction of the sitTarget by that 1/37.9 of the avatar's height for which correction was necessary in Havoc 1. (If all that is confusing, my code for setting a sit target to match the position of a poseball-seated avatar in http://forums.secondlife.com/showpost.php?p=1504321&postcount=82
Simon Linden made changes - 07/Feb/08 04:57 PM
Bingo... thanks for following up with the tough work on this, Qie. I still don't quite know why you found a variation based on the avatar's Z height, while my testing seemed to indicate no variation no matter what height I chose, but regardless, we both know that llSitTarget() in Havok 1 behaves oddly. Thanks for doing the work to find out that llSitTarget() in Havok4 behaves oddly in a different way.
Personally, I'd love to see that 0.4 AND the 1/37.9 or 0.186 go away in the form of llSitTargetCorrect(), and keep the old legacy behavior in llSitTarget().
Simon Linden made changes - 12/Feb/08 11:39 AM
McCabe Maxsted made changes - 12/Feb/08 04:54 PM
Harleen Gretzky made changes - 15/Feb/08 11:46 AM
I've noticed that hugger scripts aren't working very well in havok 4 regions. Avatar positions are off, and the avatars never seem happy with their positions as they continue trying to walk forward after colliding. Could this be related to this issue?
I believe with great certainty that this is a systematic change. I have created a tool to measure this offset, and I have found it to be exactly 0.0 in H4, where it's based on avatar geometry in H1 (not exactly proportional to height, it uses various aspects of avatar geometry in differing proportions, but close enough for jazz). This would break existing content, requiring the sit target vector to be changed in many many existing objects.
Dylan, I believe that the hugger problem is completely unrelated, that is a change in avatar collision physics, and this is only related to sit target calculation. Sidewinder, you can use the script which I posted with http://jira.secondlife.com/browse/SVC-1553 From my testing, it looks like the fix was a success.
Thank you so much! SL is saved! 
Darien Caldwell made changes - 16/Mar/08 08:29 PM
Darien Caldwell made changes - 16/Mar/08 08:30 PM
Arawn Spitteler made changes - 25/Aug/08 06:37 AM
Sue Linden made changes - 13/Nov/08 12:12 PM
Sue Linden made changes - 13/Nov/08 04:54 PM
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Major
Sit Targets created under Havok 1 are offset under Havok 4
http://forums.secondlife.com/showthread.php?t=153963
I wonder if maybe the sit target positioning code was rewritten, and whatever bug was in the old code was quietly fixed in the process. I'm all for making sit target positioning more logical, but this might break a lot of content.