water block holes?

#61 Not me currently, although being able to have multiple water blocks would be very, very cool. for instance if you have a river that went over a cliff. you would need one block for the water at the top and one at the bottom and like a particle based waterfall in between.

Ben: is something like this possible with the TSE water?

#62 I'm making some progress. I've setup three copies of Stronghold.mis, one with squareSize = 8, one with squareSize = 4 and one with squareSize = 2. At the moment there are no waterblock holes on any of the test missions.

Now, the bump in the road. When squareSize = 8, the RebuildMasks() method works properly; waterblock tiles that are under the terrain are rejected appropriately. When squareSize < 8, none of the waterblock tiles are rejected (every tile, even those under the terrain are rendered).

Well, back to tinkering with it.

#63 What about the depthMaps? are they aligned propperly?

#64 Yep, they seem to be.

Here's a few quick screenshots of the current progress:
Stronghold.mis - squareSize = 8
Stronghold.mis - squareSize = 4
Stronghold.mis - squareSize = 2

The last hurdle is to figure out why no waterblocks are being rejected when the squareSize is different than 8.

#65 Looks like there's more problems than I originally realized and I'm out of ideas on how to solve them.

For one, I've yet to figure out why RebuildMasks()/BuildLowerMasks() accepts all waterblock tiles on terrains with squareSize < 8. For the purposes of my project, I simply disabled this behavior using the code I posted above (setting pG = 1). This ensures there can never be any waterblock holes on any mission because every tile, even those underground/obscured by terrain, are accepted.

It has the side effect of avoiding a crash bug when squareSize = 16. For me, on what I assume is a clean copy of 1.4, missions with waterblocks and terrains with squareSizes > 12 crash. Debugging the crash shows it stops on line 334 of fluidSupport.cc. The line in question is: *pG = (U8)(FluidLevel > m_pTerrain[i]);. I didn't have the time to properly debug it, my only guess is increasing the squareSize to 16 causes pGrid to go out of range.

Secondly, there's a very odd render bug with waterblocks when squareSize <> 8. The entire waterblock disappears randomly the closer the camera gets to the terrainblock boundary. I'm not sure why this happens. It could be a product of the changes I've made to fix waterblock holes, how the viewing frustrum/clipping plane is setup, etc.

Lastly, there are depthmap alignment problems on waterblocks when the terrain squareSize > 12. Oddly enough, they also (only?) appear near the terrainblock boundaries. It looks as though the waterblock depthmap texture isn't scaled appropriately.

#66 Any progress on this?

#67 BUMP!!!

Any word or has everyone given up?

#68 I've had to drop it and move on. There's several problems with the entire fluid code that make fixing one thing break another.

If it helps, I simply implemented Stephane's changes (as listed above) as well as the change to RebuildMasks() I posted earlier. Stephane's changes will fix most of the odd behavior and my change will prevent waterblock holes. Together they may be just enough to allow you to continue working on your project.

#69 Hey everyone,

My sincere apologies for not coming back and fixing my code up, but I have been terribly busy. I am just finishing up a major project, but will definitely come back to this. I have been using my fix for waterblocks for the past 6 months without any problems (interchanging between squareSize of 4 and 8 on varying maps)... I must have missed something small, but obviously vital. I do promise to get back to this as soon as things have cooled down for me...

Again, my apologies...

Stephane

#70 Cool I look forward to it

#71 I haven't tried this yet, but I was looking over the code just now and I think I see the reason why this cod didn't work in size 8. In the fluidrender.cc code you change this:

F32 Q2 = 1.0f / 1024.0f;

Where it was originally 1.0f / 2048.0f. It's basically hard coding it to terrain size 4, and not taking into account the settings. So at size 4 it should be fine, but in others it will bug out. That's my best guess at least.

#72

#73 So I assume that

f32 Q2 = 1.0f / 2048.0f;    // This is the size of the terrain.
 needs to change to
	f32 Q2 = 1.0f / (2.0 *(m_SquareSize << 7)); This is the size of the terrain.

The reason that the code crashes on SquareSize larger than 8 is because Stephane
changed the line

i = (((m_SquareY0+Y) & 255) << 8) + ((m_SquareX0+X) & 255);
      to
                   i = (((m_SquareY0 + Y) & 255) << m_SquareSize) + ((m_SquareX0 + X) & 255);

This really needs to stay unchanged. It's just building a 16 bit index and the first byte
needs to be shifted just 8 bits, not 16, 32 , or 64 bits.

#74 Any further progress ?

#75 Fixed in 1.5.

#76 Ok, would this mean we can change terrain block size without incurring in problems?