Possible minimap/water bug, screenshots included
by GregM · in RTS Starter Kit · 03/26/2005 (10:59 pm) · 19 replies
I am working on a naval strategy game that requires expansive oceans with very little terrain visable above the water. When I make maps like this they often crash on startup. The console log ends during minimap rendering so I suspect that is part of the problem. I have tested these same maps in the regular TGE SDK and the work fine.
If I load the demo or example mission, hit F11 for the editor and then open the ocean mission with file->open mission It opens okay. As soon as I exit the editor it crashes again. Note that the world editor GUI doesn't have a minimap, but one is rendered when returning to normal game mode.
Once in a while I am able to get the mission to load, but it comes up all corrupted. If this happens it crashes on exit or on F11.
Here are screenshots of how the bug appears in the RTS (pardon the programmer art):
note the holes in the terrain.
the minimap has odd tiling on the water textures.
you can see throught the holes to the backside of the terrain, but units still stand atop them like they were solid.
here is a shot of the same map loaded in the world editor - looks fine here:
I've tried loading the exact same map and mission file into regular TGE and it workd fine, never bugs out or crashes. Editor works, exits clean, etc.
Now, If I remove or comment out the water block the map loads fine. If I shrink the block so it only covers part of the map things start working again. Also seems to work better if I drop the waterblock below the terrain so it's hidden.
edited to fix tags
If I load the demo or example mission, hit F11 for the editor and then open the ocean mission with file->open mission It opens okay. As soon as I exit the editor it crashes again. Note that the world editor GUI doesn't have a minimap, but one is rendered when returning to normal game mode.
Once in a while I am able to get the mission to load, but it comes up all corrupted. If this happens it crashes on exit or on F11.
Here are screenshots of how the bug appears in the RTS (pardon the programmer art):
note the holes in the terrain.the minimap has odd tiling on the water textures.you can see throught the holes to the backside of the terrain, but units still stand atop them like they were solid.here is a shot of the same map loaded in the world editor - looks fine here:
I've tried loading the exact same map and mission file into regular TGE and it workd fine, never bugs out or crashes. Editor works, exits clean, etc.
Now, If I remove or comment out the water block the map loads fine. If I shrink the block so it only covers part of the map things start working again. Also seems to work better if I drop the waterblock below the terrain so it's hidden.
edited to fix tags
#2
03/26/2005 (11:13 pm)
Squaresize is 8. I've avoided other squaresizes since those have issues with waterblocks
#3
Also, have you tried actually disabling the mini-map and see if it still happens? Would help to isolate it for sure.
03/26/2005 (11:33 pm)
Heh..can't blame me for trying. What's the total dimensions of the block? Also, have you tried actually disabling the mini-map and see if it still happens? Would help to isolate it for sure.
#4
The water block in the images is 2048 units so it will tile nicely, but I've had problems with anything over 7something. I think it was 768 but can't recall now.
I'm really hoping I just missed something stupid or don't understand something about the world editor and waterblock limitations.
This bug should be easy to duplicate but I'd be happy to post my mission and terrain files if anyone wants to look at them.
03/27/2005 (1:30 am)
Haven't tried disabling the mini-map yet, will try that and perhaps porting the mini-map to stock TGE. I didn't even suspect the mini-map as an issue until friday night. I've kind of ignored the whole issue for a couple months.The water block in the images is 2048 units so it will tile nicely, but I've had problems with anything over 7something. I think it was 768 but can't recall now.
I'm really hoping I just missed something stupid or don't understand something about the world editor and waterblock limitations.
This bug should be easy to duplicate but I'd be happy to post my mission and terrain files if anyone wants to look at them.
#5
and
All functions appear to work now. world editor works, game exits clean, etc.
03/28/2005 (4:28 pm)
Well, I removed the minimap and everything works now. Looks like that was the problem.and
All functions appear to work now. world editor works, game exits clean, etc.
#6
EDIT: looks at forum, realizes its a bug report ;-)
03/28/2005 (4:36 pm)
Well that kinda sucks! Dont you wanna use the Minimap? :-(EDIT: looks at forum, realizes its a bug report ;-)
#7
03/28/2005 (5:08 pm)
What graphics mode were you working in? Just trying to collect info to try to duplicate this when I get the chance.
#8
800x600
bit depth set to default (32bit on my machine)
windowed mode.
Running on a Gforce2MX with 32MB
OS is Win98SE
My artist was having the same problem on win2K with a Gforce FX series card.
03/28/2005 (6:39 pm)
OpenGL800x600
bit depth set to default (32bit on my machine)
windowed mode.
Running on a Gforce2MX with 32MB
OS is Win98SE
My artist was having the same problem on win2K with a Gforce FX series card.
#9
It looks like the mission area is rendered in 4 pieces, repositioning the camera each pass to get the different areas. Unfortunately, the water renders itself relative to the camera....so we get four different views of the water with the sun reflection in a different spot each time (relative to the new camera position).
05/12/2006 (3:55 pm)
I just ran into this problem.It looks like the mission area is rendered in 4 pieces, repositioning the camera each pass to get the different areas. Unfortunately, the water renders itself relative to the camera....so we get four different views of the water with the sun reflection in a different spot each time (relative to the new camera position).
#10
05/31/2006 (7:51 pm)
I have the same problem too.. but only when i restart the mission... adjusting the visible / fog distance / TessSurface/TessShore seems to help 
#11
What can I say about this bug is that it happens when waterblock is larger than mission area, i.e. area that is rendered on minimap.
Hopefully our Jedi-master, Stephen Zepp, will figure something out soon :)
EDIT: and, yes - it's a problem with minimap. When I turn it off, the engine doesn't crash.
06/10/2006 (9:10 am)
Yep, I've faced this problem too. And since I don't try to play with rendering code... is there any way to fix this issue? Did someone work on that?What can I say about this bug is that it happens when waterblock is larger than mission area, i.e. area that is rendered on minimap.
Hopefully our Jedi-master, Stephen Zepp, will figure something out soon :)
EDIT: and, yes - it's a problem with minimap. When I turn it off, the engine doesn't crash.
#12
07/18/2006 (1:18 pm)
Any resolution yet?
#13
I found a problem with large waterblocks and traced it back to the way the fluid class is storing verts. It uses static members on the fluid class to keep a list of these verts. When there are too many... well it wasn't checking for that, so it would write to random memory.
I think the problem described in this thread with the minimap crashing is because the minimap renders another waterblock - doubling the number of verts that the fluid class needs to keep track of. It may also solve the holes in the terrain issue described above because it should prevent writing to random addresses [at least this case of it :-)]. Don't think it will do anything with the tiling/lighting issues on the minimap though.
Here is my fix for this - it applies to TGE 1.5.2, but may also apply to earlier versions of the engine.
In terrain/fluid.h:
In terrain/fluidQuadTree.cc:
If anyone is still here and gets a chance to try it out, please post here and let me know how it goes.
[Edit: fixed context code...]
09/13/2007 (4:23 pm)
[Necro-thread rise! I realize this is an ancient thread but this post was what a forum search turned up for me.]I found a problem with large waterblocks and traced it back to the way the fluid class is storing verts. It uses static members on the fluid class to keep a list of these verts. When there are too many... well it wasn't checking for that, so it would write to random memory.
I think the problem described in this thread with the minimap crashing is because the minimap renders another waterblock - doubling the number of verts that the fluid class needs to keep track of. It may also solve the holes in the terrain issue described above because it should prevent writing to random addresses [at least this case of it :-)]. Don't think it will do anything with the tiling/lighting issues on the minimap though.
Here is my fix for this - it applies to TGE 1.5.2, but may also apply to earlier versions of the engine.
In terrain/fluid.h:
...
static [b]u16[/b]* m_pIndex;
static [b]u16[/b]* m_pINext;
static [b]s32[/b] m_IOffset;
...In terrain/fluidQuadTree.cc:
...
[b]u16[/b]* fluid::m_pIndex = NULL;
[b]u16[/b]* fluid::m_pINext = NULL;
[b]s32[/b] fluid::m_IOffset = 0;
...
fluid::vertex* fluid::AcquireVertices( s32 Count )
{
...
m_IOffset = m_VUsed;
[b]AssertFatal( (m_IOffset >= 0 ) && (m_IOffset <= S32_MAX), "fluid::AcquireVertices: Invalid m_IOffset" );[/b]
m_VUsed += Count;
...
}
...
void fluid::AddTriangleIndices( s16 I1, s16 I2, s16 I3 )
{
if( m_IAllocated == 0 )
{
m_IAllocated = 100;
m_IUsed = 0;
m_pIndex = ([b]u16[/b]*)MALLOC( m_IAllocated * sizeof(u16) );
m_pINext = m_pIndex;
ASSERT( m_pIndex );
}
if( m_IUsed+3 > m_IAllocated )
{
s32 Next = m_pINext - m_pIndex;
m_IAllocated += 100;
m_pIndex = ([b]u16[/b]*)REALLOC( m_pIndex, m_IAllocated * sizeof(u16) );
m_pINext = m_pIndex + Next;
ASSERT( m_pIndex );
}
...
}If anyone is still here and gets a chance to try it out, please post here and let me know how it goes.
[Edit: fixed context code...]
#14
Thanks for this. Im adding it right now to the RTS Resource Index, Fixed bugs section (though I cant check it right now, someone there could give it a try?).
Edit: You already advised on the other threads affected about this one, but Im linking from here for future reference:
Waterblock Crash in RTS
Point3F vertPos(???) Fluidrender.cc
09/13/2007 (5:45 pm)
Well Andy, I must say, its so much good to see you over here! Really been thankful of seeing an GG employee overhere. Btw, I saw it, this cover 3 bug posts!Thanks for this. Im adding it right now to the RTS Resource Index, Fixed bugs section (though I cant check it right now, someone there could give it a try?).
Edit: You already advised on the other threads affected about this one, but Im linking from here for future reference:
Waterblock Crash in RTS
Point3F vertPos(???) Fluidrender.cc
#15
09/13/2007 (8:06 pm)
Thank you Andy. I haven't run in to this problem yet, but I'm really glad to see a GG employee fixing things ;) Especially RTS related things.
#17
This is actually an issue in stock Torque - it just wasn't designed with so many fluid verts in mind. I just happened to find posts about it here in the RTS forum, so I thought you guys would like to try it. If it's a good fix I'll apply it to the main TGE repo.
Glad to hear it helped on 1.3 too - I don't think the fluid code has been touched since Tribes II, so it should apply to all versions off TGE.
09/14/2007 (9:36 am)
Quote:...I'm really glad to see a GG employee fixing things ;) Especially RTS related things.
This is actually an issue in stock Torque - it just wasn't designed with so many fluid verts in mind. I just happened to find posts about it here in the RTS forum, so I thought you guys would like to try it. If it's a good fix I'll apply it to the main TGE repo.
Glad to hear it helped on 1.3 too - I don't think the fluid code has been touched since Tribes II, so it should apply to all versions off TGE.
#18
In fluid::AcquireVertices where say m_VUsed += inCount; have to say:
10/01/2007 (8:15 pm)
Just a little catch:In fluid::AcquireVertices where say m_VUsed += inCount; have to say:
m_VUsed += [b]Count;[/b]
#19
10/01/2007 (8:19 pm)
Thanks Novack - fixed it above. [I'd made some other changes which I was trying to work around here...] 
Torque 3D Owner Stephen Zepp