|
|
|
[
Permlink
| « Hide
]
Slippery Enzyme added a comment - 29/Jan/08 03:47 PM
The water level is definately set slightly low and should be adjusted. A good way to see this deomstrated is by using a small radio controled boat. The small diplacement of the vehical makes it much more evident.
This has been fixed and deployed. The boat I was testing could still get water above its deck when turning steep, but when I checked the position of the boat it appeared to be hovering slightly above the intended height.
Andrew, I am afraid I must disagree.
I have measured the water height in both Main and Beta Havok sims and they both read 20.0000, as one would expect. I have a data recording of boat height in the Beta sims from Dec 19. It shows an average Z position of 20..54103 meters. A measure taken today in the Beta sims (Feb 6) shows an average Z position of 20.5395 meters. This is the same boat code specifying height/hover/buoyancy. No changes. Identical test conditions. The difference in these numbers looks so small as to be probably indicative of identical relevant server code, given that they are an average of about 40 samples.. I have a measurement taken Dec 19 in the Main grid showing an average Z position of the boat for identical conditions of motion to be 20.827 meters. This data collection has been my test baseline for all test reports filed. Boat Z position in the Beta Havok grid sims as of Feb 6 is approximately 0.3 meters lower than it is for the Main grid sims and this manifests itself as water pixels in the boat more prominently than in Main grid. I verified this with other boat types, too. I don't think this is a resolved issue. I suspect VEHICLE_BUOYANCY.
Casual observation with the boats I sail most often (Flying Tako 3.3, my own) is that Z position seems fine, but I found one that was sunk about .4m. Looking at the script, I noted VEHICLE_BUOYANCY was 0.5, and changed it to 1.0, which brought it back to normal. ...interaction seen with VEHICLE_HOVER_EFFICIENCY when buoyancy was <1., but buoyancy seemed the real culprit. It may very well be a problem of Beta Havok buoyancy not yielding the same vehicle result as Main Grid buoyancy – or Hover Height. Those are reasonable and promising areas for Andrew perhaps to investigate in adjusting the performance of Havok to fix this. Requoting more clearly:
Dec 19 Main Grid height data collected from instrumentation code (via llGetPos) in a boat – 20.827 meters Jan 17 Beta Havok grid height – from same instrumented boat in identical conditions – 20.54103 meters Feb 6 Beta Havok grid height – from same instrumented boat in identical conditions – 20.5395 meters The Jan 17 and Feb 6 Beta Havok measurements indicate no change to boat height. It is 0.3 meters lower than Main Grid and this will likely put water pixels inside hundreds (maybe thousands) of boats in SL. I examined the checkin logs and noticed that my latest changes to the hovering vehicle code were after the freeze point for the last Havok4 preview update, so I had prematurely resolved this bug since you don't have access to my changes.
I then double checked the boat and looked carefully at the hover height. I now have the boat hovering at about 20.67 meters. The water is 20 meters and the hover height set in the script is 0.6 meters. The extra height appears to be caused by the fact that the boat also has buoyancy of 1, and I had added some extra anti-gravity to compensate for low hovering height which kicks in even when the buoyancy is not set for the vehicle, but only when the vehicle is below its hover height. When I removed the buoyancy setting I found the boat hovered around 20.53 meters. The expected height change from removing the anti-gravity would be: gravity * timestep * hover_timescale / hover_efficiency = 9.81 * 1/45 * 1.5 / 0.4 = 0.817 meters Given the error of the bobbing boat that is close enough to appease my expectations. As it turns out I had to add a similar extra anti-gravity hack to the llMoveToTarget() feature. I think the reason it is required is that the order of operations has changed between Havok1 and Havok4. Havok1 would integrate gravity, then the actions, but Havok4 does the actions first and then integrates gravity, so the actions don't have the gravitational speed registered before they try to adjust their velocities to achieve their goals. The vehicle feature is an "action" that computes new impulses every step of the physics engine. So this is a conundrum. The boat is hovering about where it is supposed to, and yet that is not high enough for Havok1 compatibility. So, it seems there must have been some bug in Havok1, or some odd interaction, where combining anti-gravity, along with the order of operations issues, contrived to keep the vehicle ~0.2 meters higher than it was supposed to be, instead of the smaller boost I'm seeing. Should I add a new magic number to recover the last 0.13 meters? It may or may not work perfect for the various other hover vehicles out there. Or, should I just be happy that it is now hovering where we expect? Thank you for the reply, Andrew. The "bobbing boat" is the wave model and the numbers I quoted above is not a single measure, but as I mentioned an average of 40+ 2 Hz samples, in order to average out that bobbing.
If I understand correctly what you just said, the new Feb 5 Havok deploy did NOT include the fixes you have made. In the interests of minimizing your workload, might I suggest that you need not do anything more to this until your fixes are deployed for our observations? It sounds like you may have addressed 60+% of the height difference of Havok 1 vs Havok 4with your fixes. This may suffice to address the visuals in question for various boats. Given that we have not seen the effects of your changes yet, my suggestion is . . . we wait until we do. Thanks for your hard work on it. I found that I change VEHICLE_BUOYANCY, 0.5 to 1.0 and that is is around the right hight. I have some small Remote Control boats in FairChang Village and have adjusted 2. Left 2 as they were (sinking. lol).
Andrew, I must presume a new Beta Grid update happened, perhaps as part of the early adopter restart done today (Feb 13), and it appears to have captured the work you mentioned above. I now confirm your measure of 20.67 meters for the test platform boat. This is clearly higher than the 20.54 prior to this latest rev.
It's all a matter of visuals of course. My eyeballs say there is still too much water in the boat, though clearly less and you clearly did make an improvement. Might I ask you to aim at the 20.827 number measured on Main Grid? I understand that your work suggests some H1 error on the Main Grid that is yielding a different appearance for what should be the same number. The point is valid. But if it's not a devastating bother with dangerous side effects, another elevation of 0.17ish meters would be good for all the boats I tested. This looks like about 5-6 inches of water in the boats vs not in the boats. Thanks for your work on this. Definite improvement. Gypsy, I can not confirm your observation.
I observe and measure the instrumented boat height to still be 20.67 meters, consistent with the most recent improvement on this JIRA of about 13 Feb. We're looking for about 0.12 meters additional improvement, but the improvement obtained from the original water-in-the-boats situation has been retained in this most recent deploy. I noticed a larger hover height discrepency in the new H4 versus H1. The SIM is:
You are at 228417.1, 275950.7, 20.9 in Mystica located at sim1062.agni.lindenlab.com (8.4.129.212:13006) Havok4 Beta Server 1.19.1.82411 After some empirical testing it seems correllated with buoyancy. H4 does not apply the same displacement effects for a given buoyancy. I can trim the hover height to be identical between H4 and H1 if I set the boyancy to 0.4. Example: In H4 varying the boyancy between 0 and 1.0 does not seem to change the hover height, unlike H1 where the displacement varies considerably. This is a major problem in that it breaks all hovering objects. I have re-examined the newest H4 deploy with the instrumented boat used for all previous measures.
I measure an extremely tiny reduction in altitude of the boat. It is still approximately 20.6 meters with all its constant settings of hover and buoyancy., but it is perhaps .01 or .02 meters lower than before. This is such a small amount that the wave motion influenced measure could be deceptive. Regardless, the boat is 0.17ish meters lower than Main Grid. Hopefully Andrew can add that per the comment string above. Here is some data on the H4/H1 hover discrepency... In this run I have a physical boat which I move between two SIMs, one with H4 the other H1. I let the boat settle before taking measurmenets. I stepped the buoyancy from 0.1 to 0.5 and then 1.0. The greatest displacement errors occur on either side of buoyancy=0.4. The problem with any much over 0.03 meters is that canals or waterways tend not to be deep so the toelrances to avoid the floorboard from going underwater are tight. bouyancy is often used to compensate for avies standing on the deck, to limit the downward displacement.
Here are trhe differances in meters: Details follow: Mystica = Havok4 Beta Server 1.19.1.82411 [15:03] You: buoy = 1.0 [15:06] You: buoy = 0.1 [15:07] You: buoy = 0.2 [15:09] You: buoy = 0.3 [15:11] You: buoy = 0.4 [15:12] You: buoy = 0.5 I just made an adjustment to the vehicle behavior relating to this. I checked it onto the repository, so it is committed but not deployed yet, but I wanted to give a "heads up" to all you patient boat owners/creators/racers out there.
The way it used to work in Havok4 is as follows... the vehicle action would NOT provide any of its own buoyancy (VEHICLE_BUOYANCY) if you happened to be hovering above your intended hover height AND the VEHICLE_FLAG_HOVER_UP_ONLY behavior was being used. So if you added vehicle buoyancy then it wouldn't actually change your hover height. It turns out that the boat ALSO use llSetBuoyancy() which is independent of the vehicle stuff, so the two actions would fight, and the boat would float a little higher than its specified hover height. So what I did was changed the logic such that such a vehicle as described above will still provide a buoyancy effect when hovering less than (1 + vehicle_buoyancy) * (-GRAVITY) * physics_engine_timestep = 2 * 9.8 / 45 ~= 0.435 m. Really this translates to an extra ~0.217 cm max since there already was the llSetBuoyancy() pushing the boat about that much already above its intended hover height. If you happen to test boats after the NEXT preview update and find this bug to be fixed then feel free to close it, otherwise I'll eventually get around to closing it sometime later. Thanks, Andrew. I seem to have a bad habit of leaving script commands active that cause no harm at the time, but apparently cause problems later, at times like this.
Of course, I have looked at multiple boats by multiple builders so the issue could not be derived only from my quirky arrangement – but no matter; you clearly are on the trail of improvement and I will be sure to recheck on your next beta deploy. Thanks for the coat of polish. Here are the results with the latest h4 beta. The differences are much closer.
Here are trhe differences in meters: -- [22:00] You: buoy=0.0 [22:01] You: buoy=0.1 [22:03] You: bouy=0.2 [22:06] You: buoy 0.3 [22:07] You: buoy=0.4 [22:08] You: buoy=0.5 [22:09] You: buoy=0.6 [22:10] You: buoy=1.0 Andrew, Balpien,
I know there are some deploys of Beta H4 work being made to some Main Grid sims that have opted in for Beta testing. I have been doing all of my measurements on the Beta Grid and then comparing them to non H4 (H1?) sailing focused sims on the Main Grid (in fact, comparing them to measurements from December, which should not have changed given no changes to H1 Main Grid sims). I do no testing work in H4 equipped Main Grid sims. I have just completed measurements at Bismarck Sea on the Beta Grid. I do not observe any change in altitude of the test boat object. The typical value for it remains about 20.6ish meters, as compared to 20.8ish meters on the Main Grid. A second boat (Mothgirl's Flying Fizz ) is not instrumented so I can make only visual judgments, but they seem quite clear that it remains lower on the Beta Grid than the H1 Main Grid. Was a deploy of the most recent changes you made, Andrew, sent to the Beta Grid today? Sigh... [EDIT -- I just got done looking at the code again and am not sure what to do...]
Balpien, that was intriguing data. Perhaps you've got a boat that is using the vehicle buoyancy effect but NOT ALSO the alternative llSetBuoyancy()? Your data isn't very linear, especially around the sweet spot, but it also doesn't have error bars, not too surprising since your raw data is not extensive enough to use statistics. In any case, your data made me go back and look more carefully at a particular spot in the code. As it turns out I was making some assumptions that there was extra llSetBuoyancy() in one threshold – my primary test subject had been the blue racing yacht that Owen had given me, which has the extra buoyancy. Owen, the updated code has not yet been pushed to the Beta grid, but was deployed to a single private estate for internal testing. Unfortunately, the corresponding internal jira item for this one was reopened by QA – they didn't have the blue yacht, but the boats they did have were actually hovering a little lower than before! After revisiting my logic it looks like I'll have to remove that aforementioned assumption about the external buoyancy, which will probably cost the blue yacht any small gains that I had given it. I'm not seeing much hope in squeezing a final 20 cm out of a hat. Just forcing all vehicles to hover 20 cm too high seems like a bad HACK and will probably break some other content. I haven't quite given up, but my hopes of matching Havok1 behavior exactly here are dwindling. How about something water specific . . . I know you're not coding in LSL for the servers but perhaps something like if llWater > llGround for an X, Y coord in a region, then a different multiplier in your server code applies to hover parameters? Balloons will float in the pixels higher over water than over land, but we are only talking about 0.3ish meters here. That is likely invisible for a balloon, but very visible for boats.
Anyway, is that too offensive a kludge? Owen, I am testing this on the main grid in the elf circle islands. Some of the regions are H4 enabled while others are not, so it permits me to shuffle between them to observe differences.
Andrew, yes, I am using a boat with vehicle buoyancy applied and no others. Here's a snippet of the code: float HoverHeight = 0.4;
I can send a copy of the boat I use to you and/or Owen if that helps. Also, here is the simple instrumentation script I use. Feel free to pass the script around.: // Height Reporter, Balpien hammerer - freely redistributable. float Tolerance = 0.01; // Amount of tolerable height drift. default timer() if (llFabs(LastPos.z - pos.z) > Tolerance) { llOwnerSay("pos = " + (string)pos + " rot = " + (string)rot + " " + llGetRegionName()); LastPos = pos; LastRot = rot; } } Andrew,
As of tonight, March 27, in response to Sidewinder Linden posting to the blog notice of a new H4 beta deploy, I re-performed the height measure. The present number, averaging about 20 points to eliminate the wave model's effect, is 20.648 meters. This is very slightly lower than the previous measure, but so close to it that with the wave model in effect I would be reluctant to say it is clearly a lower altitude. Potentially Significant Item: Simon Linden has been kind enough to address some H4 problems that were affecting the wave model. He made some changes that did generate improved appearance. The measurement that I just quoted above (20.648 meters) is an average of samples that appears to have a clearly larger sigma than previously as the wave model does its thing. There are occasional measurements of 20.7+ meters (and 20.5ish meters) in what I just looked at. This has not been true in the past. Note the wave model is NOT purely rotations around X and Y. Now, we don't want to be tailoring what you're doing too very much to that single boat object, and I don't think we are thus far. The changes Simon (or someone) made appear to be affecting performance of the object in a way that MAY have affected these altitude measurements for not just this boat, but others, too in reference to the comments you just made about other boat measurements being confusing. There is no question that the standard deviation of altitudes is wider than it was before in today's samples, and that motion is not purely rotations. I think it is possible someone else has made a change that is affecting your experiments. I thought about Owen's logic about how boats are more sensitive to height variations than regular buoyant vehicles and had to finally agree – it is the easiest path out, and most other vehicles probably won't notice the hover height discrepancy. I did the messy HACK of artificially raising the effective hover height for vehicles that ALSO have vehicle buoyancy set. The one vehicle I've been testing (ACYacht) appears to be floating at the right height.
I'm marking this as "Fix Pending" but feel free to close this bug should you test and find it truly fixed. Re: 1.20.0.83683.
My boats are at this stage all custom, I noted a .324-.384m variation in the hover height post patch. Thats almost half a meter lower and has caused all of the smaller vehicles to sink completely. The larger rideable ones as you can imagine are now taking in water, eep! :O The below I have noted an 0.324m variation taking the height from 20.022m to 19.698m: llSetVehicleFloatParam( VEHICLE_HOVER_HEIGHT, 0.02); and my R/C Boat toys noted a .384m variation taking their height from 20.047m to 19.663m: llSetVehicleFloatParam( VEHICLE_HOVER_HEIGHT, 0.1); Examples left here side by side: http://slurl.com/secondlife/Concordia%20Discorse/80/231/23 I'm seeing something similar with the surfboards in the main grid roll-out. The boards and AV are mostly underwater now, where the boards were perfectly water level before. Makes for a whole lot of unhappy surfers.
To quote a famous Linden . . . Sigh.
I am measuring 20.792 meters of average height on the test object used since Dec 19, and this is substantially improved from the previous 20.6ish meters of height of recent Beta deploys. And it is very close to the December 19 Main Grid measure of 20.83. I suppose it is as Andrew feared. Vehicles are achieving baseline heights in different ways. I have tested Flying Fizz and Tako in addition to ACC and I find that main grid H4 is the substantial improvement that was intended. The ACC, Fizz and Tako-based boats represent thousands owned in SL, and they now are at proper height floating in the water pixels. Clearly all vehicles did not get their height defined in the same way. Andrew, in his text above, suspected this. It's a tough problem. This is certainly not anyone's fault in how they built their vehicles. It's just a tough reality for H1 vs H4. Maybe Andrew can work a miracle. My measure is what I just quoted. The predominant boats that I know of in sl sailing are now floating with water pixels not appearing above the decks and they look correct.. I'll be needing copies of some of these vehicles in order to debug.
BTW, I suspect this problem is related to That is, there was a bug in the Havok1 code that made buoyant + hover + HOVER_UP_ONLY boats stay at water height, however there were also such vehicles that could indeed float into the sky. Why did similar vehicle setups provide two distinct behaviors? My first thought that this was finally a real example of a schrodingbug, where the bug's dualistic waveform had collapsed sometime during the Havok4 rewrite. But of course, there must be some logical explanation for the intergalactic upsets. I noticed this too with Snaptick Laxness's Snap Kayak. Definitely sits low, especially to the back. There are public ones available on Livingtree island, to the north, for a demonstration of the issue. If there is anything else I can hel on with that element, I'll gladly do so
Updated to current server: still an issue.
Here are a couple of screen shots of my AV while sitting on a surf board after the new Havok 4 roll-out.
----------------------------------------------------------------------------------------------------------------------------------------- You are at 270740.0, 305707.7, 21.0 in Tsunami Beach located at sim2527.agni.lindenlab.com (216.82.18.24:13018) This is still an issue with H4 on the main grid. I have surfboards which surf under the waves, waves which ride too low in the water and billiard balls which rez halfway in the table. My sim is Cameo. Feel free to visit and try the surfing and billiards, neither of which really works now.
I tried three surfboards (two at Tsunami Island and one at Majini Island). Two still had sections above water when I was sitting down, which looked about right, and the last was just barely under the water – nowhere near as bad at the *.bmp pictures above. The script of the last one had been written in early 2007. When I ran the numbers based on the parameters I was getting about the right height.
If you balance the hover velocity with gravity, then solve for the delta_height that the hover has yet to go you get: delta_height = (gravity * (1-vehicle_buoyancy) * physics_timestep * hover_timescale / hover_efficiency) + (vehicle_buoyancy * havok1_height_adjustment) where: delta_height = distance between the hover target and the center of the root prim when hover is at equilibrium with gravity --> I'll be needing a copy of the buggy surfboard in the picutres. Also, I tested Snapstick's kayak in Livingtree. Turns out my purchase of the kayak prompted Snapstick to come by and see what I was doing. Snapstick had already fixed the kayak in another vendor and had forgotten about the one in Livingtree – it is now updated with a kayak that floats at the right height. Unfortunately, the old kayak was also floating at the right depth according to the formula above. The older (bugged) version of the kayak was using a hover_timescale that was longer than what was used in the surfboards, although the final intended height was a little obfuscated by how it was computed in the script. I suspect I shouldn't have scaled the havok1_height_adjustment term by the vehicle_buoyancy. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||