Water, water everywhere... but its not supposed to be!

#1 Yes and yes. insert this waterblock in manually and see if it works

Otherwise something have gotten broken recently.

new WaterBlock(pond) {
      position = "-304 536 -10.8939";
      rotation = "1 0 0 0";
      scale = "480 576 87.8968";
      UseDepthMask = "1";
      surfaceTexture = "~/data/water/waterdark";
      ShoreTexture = "~/data/water/wateredge";
      envMapOverTexture = "~/data/skies/sunset_0007";
      envMapUnderTexture = "~/data/terrains/grassland/sand";
      specularMaskTex = "~/data/water/specmask";
      liquidType = "RiverWater";
      density = "1";
      viscosity = "15";
      waveMagnitude = "10";
      surfaceOpacity = "0.75";
      envMapIntensity = "0.4";
      TessSurface = "50";
      TessShore = "60";
      SurfaceParallax = "0.5";
      FlowAngle = "45";
      FlowRate = "0";
      DistortGridScale = "0.1";
      DistortMag = "0.05";
      DistortTime = "0.5";
      ShoreDepth = "10";
      DepthGradient = "1";
      MinAlpha = "0.03";
      MaxAlpha = "1";
      removeWetEdges = "0";
      specularColor = "1.000000 1.000000 1.000000 1.000000";
      specularPower = "6";
         textureSize = "32 32";
         params3 = "1.21 -0.61 0.13 -0.33";
         floodFill = "1";
         envMapTexture = "~/data/skies/sunset_0007";
         params0 = "0.32 -0.67 0.066 0.5";
         extent = "100 100 10";
         seedPoints = "0 0 1 0 1 1 0 1";
         params2 = "0.39 0.39 0.2 0.133";
         params1 = "0.63 -2.41 0.33 0.21";
   };

#2 Nope. The problem still exists.

To elaborate: the problem is ONLY with the non-visual aspects of the water effect... not the visual Map or tint. So if your water block settings are not drastically different than normal physics, like high water density or "lava" settings, you may not notice that the problem exists.

I can understand how you might think all is well with your H2O blocks, though. In your example block, the water density is set to the default "1"... So, if you drive your vehicle or walk your player to a spot lower than the H2O block, you might not notice the slight slowdown &/or floaty-ness. Try bumping your density up to 9 or 10 (so the player floats), and THEN try walking outside the paramenter of the water block at a lower altitude. I suspect you'll have the same problem we're having. (This is probably why Matt first noticed the problem only when his 2nd LAVA pool blew him up!)

(Note that this oddity occurs even in the default Torque demos if one "digs a dry hole" lower than the water surface and bumps the nearby water density up.)

Thanks for the input tho...

#3 Yup Brian I got the same result here. ;)
We're building a jump and run game that has higher water density that doesn't let you jump very high when in the water so it is very noticeable when you hit the "invisible water" on dry land. Or for the fact that you get killed on the other side of the map from the lava. ;)

Matt

#4 Im not sure what you are getting at, the player will run at regular speed in water unless db variabes are set

//Water Movement
   maxUnderwaterForwardSpeed = 16; // 80% of runforce
   maxUnderwaterBackwardSpeed = 15; // 90% of max water forward speed
   maxUnderwaterSideSpeed = 15; // 90% of max water forward speed

I wish I could help but with these setting we are able to place and contain the water block (ie rescaling them).

Only when the player is in the waterblock will it's speed change. I know this for a fact because I forgot scale the Z (depth of the water) which allowed players to easily walk out of the water block by walking undernight the water blocks. And all effect were gone

Edit Unless you want things to float I would leave the density to it's default. Alter the players' effect in a player dataBlock

#5 Okay here is a short video I made using Fraps showing the problem. You can see that when I exit the water my speed increases until I get over the little hill and back down to the level of the original waterblock. At that point I slow down and I am not able to jump just as if I was in the actual water. If anybody has trouble viewing the video, I used the XviD MPEG-4 codec.

Matt

[EDIT]
Removed video from site. ;)

#6 Anthony,
Again, I appreciate your help but its clear that we've been unable to communicate nature of the problem to you. The code examples you keep sending prove my point... that you wouldn't notice the problem BECAUSE all of your defaults are so close to
the norm.

Try digging a hole beside the lake in the Torque Demo after first
adjusting the density to 10 as I suggested above. Then jump into the dry, empty hole... you'll get stuck at the invisible water level.

Better yet, go on the internet and see if you can log into Brian's Demo a few minutes from now and I'll have it ready for you.

Its starting to sound like Matt and I have stumbled into a water block anomaly that, for the reasons given above, has never really surfaced before. (Puns Intended. sorry)

Any thoughts from Employees?

#7 I do concur that we might both be missing each others point.

But just to reiterate. I think the problem is that you are trying to get the same effect but are going about it the wrong way ( note this is just my humble opinion). If your goal is to have players walk into "pools" and have thier speed change while in water. Try this

Place the water block and scale it to the area you like (leave it's default settings).

By default the player will show no differance in it's speed. To change that ,you are suppost to use the player class's variables (the one I have listed above). Those will affect the players' speed while inside a waterblock.

Now if that does not work might I recommend placing echo() via the scripts in the waterblock onEnter() onExit() to besure they are actually in waterblocks. You can also search in the player class and hard code some tracing with the con::printf() commands in the c++ to see if the player is submerged or not.

#8 Matt: I've had the same problem as in the video...

#9 Anthony,

If I may step in for a moment. Brian's problem isn't that the Player is in water, they are not suppost to be in water. The water pool is above them and far far away. The problem is that that the player is effected by this water pool. For example:

Sorry for the bad asci art.

Left   Right  
             |     |            
             v     v
            _.......  <- top  
           / \_____/ 
          /           <- bottom
___X_____/   

Where:
   Left - Is pointing to the left most edge of the water block.
   Right - Is pointing to the right most edge of the water block.
   Top - Is pointing to the top most edge of the water block.
   Bottom - Is pointing to the bottom most edge of the water block.
   . - Periods are the top of the water line running up to the shore.
   _ and / are the "land"
   X - Is the player. Far away from the water block, 
       not in the water block, but below the "top" line of 
       the water block.

Now the problem Brian is seeing is that player in spot "X" is having water like effect even though the player isn't in the water block. He does not want these effects while the player isn't in the water block.

Make sense? Do you know how to remove this side effect of having a small water block at a higher elevation thant he player on dry land?
Edit - To clean up my asci art. yes it did look worse.

#10 Well Put, Dan.

Your Picture Is Indeed worth a Thousand words.
Thanks.

Anyone know how to fix?

#11 Check the code that checks for being in the water or not, and change so it doesn't test for the waterblock's height fork (ie being in between its lowest and highest point), but if the player/entity is actually in a waterblock.
That what comes to mind :)
And submit a resource with the results, and a lot of people will be happy, I'm sure

#12 This must be a recent bug because all waterblocks I have used behaive correctly. But again trace the code to insure the player is in the water.

Finally I still retain my point that you should not use the water's density to create the effect of drag while a player is in a waterblock. There are already variables created in the player class to control that.

Possibly changing the density is affecting something else (non waterblock related) the quick easy way to avoid it is to use Torque existing feature and leave the waterblock's density to its default to achieve the same effect. ie the variables I have posted above.

But on a side note, through out our development cycle the waterblocks were some of the most trickies features to impliment, for I time they wouldn't even render. So I presume it is a new bug =(

#13 I've had the same problem.

Just a note on the video though: Very cute :D

#14 Thanks Nicolas,

Your suggestion seems like a reasonable way to approach the problem. I'll let everyone know how it goes.

#15 Guy goes to a doctor and says:
"Doc, it hurts when I do this..."

So the doctor says:
"Then don't do that."

Its true that the doctor makes an excellent point. Its also true that the doctor's point, from the patient's perspective, is not particularly helpful.

#16 I ran into this problem also. After reading this thread I decided to dig into the code to see if I can figure it out, since it doesnt appear to be sorted out yet.

Anyway, I sorta found the problem, but have not found the root of the problem, and the more minds on it the better ;)

First I should mention that the problem appears to be only in the x/y extent. If the player goes completely below the bottom of the waterblock, it works fine again.

Now, the problem appears to be that the mObjBox member of WaterBlock is getting hosed somewhere along the line. I believe in all cases for WaterBlocks mObjBox should be (0,0,0), (1,1,1). And this is the case the first couple of times that resetWorldBox is called for the waterblocks. However, after the first couple of times, mObjBox becomes (-10000, -10000, 0 ), (10000, 10000, 1 ), I'm guessing this is probably the result of some relic leftover from an early implementation of waterblocks. I haven't yet been able to figure out where this is being changed.

Then in resetWorldBox this is multiplied by the scale of the waterblock. This ends up basically multiplying the size of the WaterBlock's affected area by 20,000 in the x,y dimensions.

A workaround that will eliminate this problem is to make resetWorldBox virtual in SceneObject.h, and implement resetWorldBox for the WaterBlock class, and at the very beginning change mObjBox to (0,0,0) (1,1,1).

Like so:

void WaterBlock::resetWorldBox()
{
   mObjBox.min = Point3F( 0, 0, 0 );
   mObjBox.max = Point3F( 1, 1, 1 );

   SceneObject::resetWorldBox();
}

Then everything should work fine.

I will look further when I get more time, to see if I can figure out where mObjBox is getting hosed, but maybe somebody else can figure it out in the meantime ;)

Peace

#17 @Gerald: you are right on the spot, the problem is the mObjBox. EdM had fixed it before but his fix causes soemthing else so it was taken out from Torque.

@Anthony: I doubt your waterblocks worked ok since this bug was in Tribes 2 too, and has been there since then.

Regards,
Xavier.

#18 This is the problem (in Anthony's waterblock code):

scale = "480 576 87.8968";

The Z must be set at 1 (ie, scale= "480 576 1.0"; ) .

If you wish to make it deeper, move the Z position up.

Good luck!

-EricF

Edit: I don't know if this will allow you to place two waterblocks at different heights, but it does take care of problems like being out of the water for a bit, and then hear the splash.

#19 I never had a problem the waterblocks work just fine, as they still do (I just played with a head version). My point was that in order to cause drag for a player one should not use the waterblocks' density variable instead set the player's variables that limit the players speed while in water

//Water Movement   maxUnderwaterForwardSpeed = 16; // 80% of runforce  
 maxUnderwaterBackwardSpeed = 15; // 90% of max water forward speed   
maxUnderwaterSideSpeed = 15; // 90% of max water forward speed

#20 @Anthony: It's not the same, you are missing the point. The waterblocks are broken and they effect the whole map under it's height when used. And changing the player's speed wont do the trick in many cases, like wanting to slow down vehicles, or any rigid objects. Also, limiting the speed is not the same than adding viscocity, in a fuild with viscocity you can't accelerate at the same rate than in air.