Game Development Community

water block holes?

by Desmond Fletcher · in Torque Game Engine · 01/19/2002 (3:14 pm) · 76 replies

Anybody have an idea why sections of the water block might disappear?

holodeck.st.usm.edu/vrcomputing/waterhole.jpg
#41
02/05/2006 (10:43 pm)
Relax, James. We're not out to get you. :)

It's fixed in TSE because we rewrote the terrain (Atlas; the TSE legacy terrain probably still has whatever issues the TGE version has) and the water from scratch to take advantage of the new GPU features and architectural elements there.

That's why I suggested writing a new water object as a viable option - that's what we did for TSE and it solved all kind of problems. :)

Meanwhile, there are a ton of options to solve your problem that don't involve anything more than some time, effort, and maybe a little sweet talk. If you notice, of the five options I mentioned, one involved paying GG money, two involved paying someone else (or just talking them into doing it), and the others didn't involve any money at all. All of them have a definite time line, probably less than a month.
#42
02/06/2006 (8:40 am)
Point taken, I appologize. I just very frustrated with this.

I'll prolly just get the TSE. That seems to be the easiest solution.
#43
02/06/2006 (9:26 am)
Quote:That's why I suggested writing a new water object as a viable option - that's what we did for TSE and it solved all kind of problems. :)

If only TSE had a fixed-function fallback, then we could all switch. Any word on if this will be the case?
#44
02/06/2006 (9:43 am)
Are you saying that the TSE does not have a fallback for someone that doesn't have shader support?
#45
02/06/2006 (10:09 am)
TSE current requires a GF3 or Radeon 8500 or higher.

Meanwhile, there are plenty of ways to solve this that don't require dropping support for lower end systems. For the cost of a TSE upgrade you could probably pay someone to resolve your issue under TGE. :)
#46
02/06/2006 (11:29 am)
We are using upscaled models in our newest game, it it works like a charm. I only had to tweak the player gravity and I think I need to change the bins' size (performance goes whacky when the camera gets close to some trees and stuff, I fear everyone is going to the overflow bin).
#47
02/06/2006 (12:10 pm)
The map squareSize and detail to change on a Map by map basis. So that is not really a pratical Option. It looks Like I will have to upgrade to the TSE.
#48
02/06/2006 (1:02 pm)
Did the code I posted above not help you, James? It's a very hackish way of getting around the waterblock holes issue but at the very least it should let you continue on with your project until a better solution comes along.
#49
02/06/2006 (1:39 pm)
Yeah, give the code above a try. I'm all for people buying TSE but there are several things to try here that could solve your problem, or at least solve it well enough you can continue making your game!
#50
02/06/2006 (2:40 pm)
Ive looked at all of the above code, and tried to generalize it for any terrain squaresize. There are MANY instances that have not been addressed with much of the code samples above. Much of the terrain and waterblock code rely on the magic numbers 256 and 8, or variations of that, like 2048(256*8) or 2047(256*8 -1). There are also some methods that do ray casting which use some bitshifting for quick math that rely on these numbers.

So for me personally, due to time constraints, I decided to try the suggestion of Chris Haigler, by modifing the method which checks which blocks are visible into a method that accepts all blocks. There is small performance hit, but it was fine in my case (terrain squaresize=4). Also, I made sure that the waterblocks I did put into the world were just the right size to cover what needed to be covered since the entire block is being rendered.

Sorry,
John.
#51
02/06/2006 (2:54 pm)
Tried the code above, in 1.4...

It does tile under the terrain, but the appearance of water above ground is inconsistent.
Sometimes it looks fine, sometimes like the image below.
Sometimes opening and closing the editor results in it rendering correctly.
So it's not reliable... damn, was excited there for a sec.

EDIT:
btw - The code I tried was: Setting *pG = 1

The image uses: terrain squaresize = 2.


www.internet3d.net/water.jpg
#52
02/06/2006 (8:20 pm)
The fact that it's happening randomly is just odd. You'd expect it to either function properly or not.

Seeing as how GenerateDepthMaps() is still generating alpha'd depth maps, I wonder if it's simply the UV coordinates that are off? Looking over the GenerateDepthMaps() method in waterBlock.cc, it seem as though the terrain position offset is hardcoded to 1024, maybe that's a starting point?

Just tossing out ideas here.
#53
02/06/2006 (10:57 pm)
That is exactly the problem as far as I can tell. However this problem is simplefixable by just manually forcing a value. At least no in my case anyway as need the ability for some maps to be at squareSize 2 some will be 4 and maybe some at 8. I don't ever see me needing 16 but ya never know.

From what I can gather there was never any thought of this engine going any further than Tribes 2 when it was written. It seems like it was hard coded to serve their immediate needs without any thought of licensing out for other uses.

From what I understand that was never even considered until Dynamix was closed and GG bought the rights to the engine from sierra.

As for the above problem the you can change the hard coded values "Only if you are making all of the mapps for you games at the same squareSize. If you are like me and need to change it depending on what the map calls for then changing these hard coded values will not solve the problem for you.

the only real solution is to find a way of reading the value of squareSize in the terrain block and storing it somewhere so that all of the places where the value is hard coded can look there to find the value that they should be set to. Actually I guess it is to variables. One being the value for the size of the waterblock and one being the value of the offset of the the waterblock.

I know what the solution is and I even know how it should function I just don't have the programming skill to do it myself.

I took C++ in school but that was a long time ago and I have been doing computer graphics since that time. I remember the logic but not the code.
#54
02/06/2006 (11:13 pm)
When I try changing the value to one I can't even get it to compile. I throw errors every time.

I don't know if this is becasue I'm doing something else wrong or if it is becasue I'm using Visual Studio 2005.
#55
02/07/2006 (1:58 pm)
James,

Why don't you offer a bounty to whoever fixes this? The TSE bounty system is a good model here. Surely a small amount of money is worth saving you so much pain and hassle. :)

Ben
#56
02/07/2006 (2:59 pm)
Ill put in for a bounty for an updated waterblock class. What I really need is different terrain size support and support for waterblocks < 32 units.
#57
02/07/2006 (3:00 pm)
How much of a bounty would there be? I would do this if it gets high enough. I've been thinking about porting over my old water...
#58
02/07/2006 (3:08 pm)
Depending on the specifics, GG would be willing to offer a free TSE license or a few content packs in exchange for a version of the water code that dealt properly with different square sizes. If you've got it, either post it here or mail me directly so it can get reviewed.

(We may not have time to solve the problem in-house but we do want to see it taken care of!)
#59
02/07/2006 (3:22 pm)
I say "port", but what I mean is rewrite my old water to work in Torque. It may take a week or two (I have a day job).
#60
02/07/2006 (3:38 pm)
How do you folk use WaterBlocks? Me, I use it mostly as a plane - ie, it covers the entire terrain. Does anyone use multiple water blocks at different sizes and positions?