IGHTC (In-Game Huge Terrain Creator) Part 2
by Darrel Cusey · 05/24/2006 (10:25 pm) · 47 comments
So, the lesson learned is to wait until GG approves a resource before announcing it :-)
Here's just a quick update on the IGHTC project:
What I've Been Up To
All original pattern-layer code was successfully ported into TGE 1.4 HEAD, tested, and got a screenshot up. The test harness system will no longer be updated, and I'll be working strictly in TGE from this point forward.
I decided that it was going to be critical to have this as a wholly separate class, and so began development of the patternManager class, from which various other classes (like patternTerrain, for example) can be derived. For many of you out there, the Good Thing (tm) about this is that you'll be able to just drop a couple files into the /core directory and the /terrain directory, make a couple edits to some of the terrain classes and call it a day -- none of this mucking around with patch files. At least, that's my goal...
I've completed the implementation of the patternManager class, doing everything "the GG way" including figuring out how to instantiate the class without directly calling a new() method on it -- very nicely done, BTW. The first rendition of the patternManager has only these console variables available (since they are most critical): patternTerrainSeedX, patternTerrainSeedY, and patternTerrainLayers.
Currently, the system uses 5 terrain pattern layers by default, but you can go as high as 20 with minimal impact on performance. The vast majority of the getTerrainHeight() function uses bitwise operators and shift functions, so it's very fast -- it's about as close to Assembly code, I think, as possible. And is it ugly :-)
Unfortunately, if I want it to be possible to edit layer heights via the console, I'll have to create a separate variable for each ... it's either that or implement an ArrayType in the consoleTypes class, which I'm just not up for this year :-) So, you'll probably be seeing ugly variables like this patternTerrainLayerHeight1, patternTerrainLayerHeight2, patternTerrainLayerHeight3... etc :P ick
I've now got 3 slope functions that (a) work well in TGE and (b) create slopes that actually look nice in TGE. I was surprised at how much the rendering engine affects the look of the terrain being rendered. An identical terrain rendered as a mesh in DirectX 9.0c SDK looks a lot different than it does in TGE. Ideally, this will lead to something that will allow a developer to choose the types of slopes to use at the various layers. So, for example, you'll be able to select nice rounded hills for the lower layers, induction lines for the middle layers and jagged peaks for the top layers. No code behind this bit yet, but that's where I'm going with it. Of course, this means uglier console variables like patternTerrainLayerSlope1, patternTerrainLayerSlope2, patternTerrainLayerSlope3... ah well.
What's Soon
Re-building all the hooks to the various patternTerrain functions from a clean set of terrain source code files.
Clean up all the slope code.
Adding in the 20 patternTerrainLayerHeightX console variables (for now, I'll just use the same slope formulae for all layers).
Once I have the layer heights available to the console, it'll make it really easy to being tweaking the heights and the number of layers I'm using to make some better screenshots.
Posting and updated Development Screenshot, this time with more than 1 screenshot :-)
What's Next
Start working on the GUI to allow editing of the patterns and the layer heights. Dev Screenshot of that once it looks nice and is easy to use (and works).
Start digging into the process of "repurposing" the original heightMap array. My "crazy idea" at this point is to simply expand the size of the heightMap array (change BlockSize) so that it is equal to (viewDistance x 2) +1 so that only 1 rep of the texture is ever seen and then using setHeight to dynamically change the current heightMap to exactly match whatever happens to currently be on the screen. Then the various and sundry texturing, blending and lighting functions can do what they'd normally do -- not knowing that they are performing their functions on a heightMap that was just dynamically generated. That should get texturing, blending and lighting to work with IGHTC just like it works now with stock TGE -- at least, that's the theory.
Record a movie of flying across the terrain and another movie of doing standard height- and slope-based texturing to show how those editing functions now work normally with IGHTC.
... that's probably as far as I want to plan for now.
Thanks again everyone for your interest and support!
Here's just a quick update on the IGHTC project:
What I've Been Up To
All original pattern-layer code was successfully ported into TGE 1.4 HEAD, tested, and got a screenshot up. The test harness system will no longer be updated, and I'll be working strictly in TGE from this point forward.
I decided that it was going to be critical to have this as a wholly separate class, and so began development of the patternManager class, from which various other classes (like patternTerrain, for example) can be derived. For many of you out there, the Good Thing (tm) about this is that you'll be able to just drop a couple files into the /core directory and the /terrain directory, make a couple edits to some of the terrain classes and call it a day -- none of this mucking around with patch files. At least, that's my goal...
I've completed the implementation of the patternManager class, doing everything "the GG way" including figuring out how to instantiate the class without directly calling a new() method on it -- very nicely done, BTW. The first rendition of the patternManager has only these console variables available (since they are most critical): patternTerrainSeedX, patternTerrainSeedY, and patternTerrainLayers.
Currently, the system uses 5 terrain pattern layers by default, but you can go as high as 20 with minimal impact on performance. The vast majority of the getTerrainHeight() function uses bitwise operators and shift functions, so it's very fast -- it's about as close to Assembly code, I think, as possible. And is it ugly :-)
Unfortunately, if I want it to be possible to edit layer heights via the console, I'll have to create a separate variable for each ... it's either that or implement an ArrayType in the consoleTypes class, which I'm just not up for this year :-) So, you'll probably be seeing ugly variables like this patternTerrainLayerHeight1, patternTerrainLayerHeight2, patternTerrainLayerHeight3... etc :P ick
I've now got 3 slope functions that (a) work well in TGE and (b) create slopes that actually look nice in TGE. I was surprised at how much the rendering engine affects the look of the terrain being rendered. An identical terrain rendered as a mesh in DirectX 9.0c SDK looks a lot different than it does in TGE. Ideally, this will lead to something that will allow a developer to choose the types of slopes to use at the various layers. So, for example, you'll be able to select nice rounded hills for the lower layers, induction lines for the middle layers and jagged peaks for the top layers. No code behind this bit yet, but that's where I'm going with it. Of course, this means uglier console variables like patternTerrainLayerSlope1, patternTerrainLayerSlope2, patternTerrainLayerSlope3... ah well.
What's Soon
Re-building all the hooks to the various patternTerrain functions from a clean set of terrain source code files.
Clean up all the slope code.
Adding in the 20 patternTerrainLayerHeightX console variables (for now, I'll just use the same slope formulae for all layers).
Once I have the layer heights available to the console, it'll make it really easy to being tweaking the heights and the number of layers I'm using to make some better screenshots.
Posting and updated Development Screenshot, this time with more than 1 screenshot :-)
What's Next
Start working on the GUI to allow editing of the patterns and the layer heights. Dev Screenshot of that once it looks nice and is easy to use (and works).
Start digging into the process of "repurposing" the original heightMap array. My "crazy idea" at this point is to simply expand the size of the heightMap array (change BlockSize) so that it is equal to (viewDistance x 2) +1 so that only 1 rep of the texture is ever seen and then using setHeight to dynamically change the current heightMap to exactly match whatever happens to currently be on the screen. Then the various and sundry texturing, blending and lighting functions can do what they'd normally do -- not knowing that they are performing their functions on a heightMap that was just dynamically generated. That should get texturing, blending and lighting to work with IGHTC just like it works now with stock TGE -- at least, that's the theory.
Record a movie of flying across the terrain and another movie of doing standard height- and slope-based texturing to show how those editing functions now work normally with IGHTC.
... that's probably as far as I want to plan for now.
Thanks again everyone for your interest and support!
About the author
#2
05/25/2006 (4:35 am)
Does the IGHTC allow realtime deforming of terrain, or is it fixed like Atlas?
#4
And yeah, what Mincetro and Maxwell asked. ;-p
05/25/2006 (11:05 am)
Can't wait for this to be released! Well, I mean I have to, but it will prove *very* useful for something I'm tinkering with right now...And yeah, what Mincetro and Maxwell asked. ;-p
#5
Neat project, do you have any screenshots? :)
What happens when something collides past the horizon?
05/25/2006 (11:19 am)
Incidentally, you can have $foo[0], $foo[1], etc. although I believe it's easier if you do it as a member of a class, not a global.Neat project, do you have any screenshots? :)
What happens when something collides past the horizon?
#6
Currently, the IGHTC doesn't have the ability to edit terrain in realtime. However, I am planning on putting this in using a sparcely-populated deformation array. I talked a little about this in the comments of my previous blog -- basically, it's just a matter of finding a method of storing very sparse data that won't return an "undefined" value if you try to access a value with an invalid key (which is what will be happening 99% of the time). So, short answer -- right now, it's fixed, but in the future you should be able to edit it just like stock TGE.
@Maxwell:
Water is a bit tricky -- waterblock technically work with IGHTC right now, but not 100% correctly. I have spent probably a total of 5 minutes looking at the waterblock code, so can't really say how much re-tooling is going to be needed in that area.
@Ben:
Right now, I'm setting up all the variables that effect rendering as class variables, and it seems easier this way and better for self-documenting code :-)
I've only posted 1 screenshot right now -- you can see it here: IGHTC First Dev Screenshot
Hmmm, not sure what you mean by "collides past the horizon"?? If you want, you can e-mail me, and we can discuss more technical details....
Again, thanks everyone for your support and interest!
BTW: I've finished my first "What's Soon" objective and have all the hooks in from a stock TGE 1.4 HEAD and it's working exactly as it was before... I was really concerned about this one because at the time I was using a pretty heavily modifed TGE 1.4 to test some of the more popular add-ons (Advanced Camera, Object Selection, etc...). But, it's working just fine now with no changes against the current HEAD, so that's 1 less thing to worry about :-)
05/28/2006 (9:11 pm)
@Mincetro:Currently, the IGHTC doesn't have the ability to edit terrain in realtime. However, I am planning on putting this in using a sparcely-populated deformation array. I talked a little about this in the comments of my previous blog -- basically, it's just a matter of finding a method of storing very sparse data that won't return an "undefined" value if you try to access a value with an invalid key (which is what will be happening 99% of the time). So, short answer -- right now, it's fixed, but in the future you should be able to edit it just like stock TGE.
@Maxwell:
Water is a bit tricky -- waterblock technically work with IGHTC right now, but not 100% correctly. I have spent probably a total of 5 minutes looking at the waterblock code, so can't really say how much re-tooling is going to be needed in that area.
@Ben:
Right now, I'm setting up all the variables that effect rendering as class variables, and it seems easier this way and better for self-documenting code :-)
I've only posted 1 screenshot right now -- you can see it here: IGHTC First Dev Screenshot
Hmmm, not sure what you mean by "collides past the horizon"?? If you want, you can e-mail me, and we can discuss more technical details....
Again, thanks everyone for your support and interest!
BTW: I've finished my first "What's Soon" objective and have all the hooks in from a stock TGE 1.4 HEAD and it's working exactly as it was before... I was really concerned about this one because at the time I was using a pretty heavily modifed TGE 1.4 to test some of the more popular add-ons (Advanced Camera, Object Selection, etc...). But, it's working just fine now with no changes against the current HEAD, so that's 1 less thing to worry about :-)
#7
The specific case I'm thinking of can be summarized by this: I am driving a car around. I send it rolling down a long incline. Then I run rapidly away in the opposite direction, until it's outside the area of terrain I have stored in memory. What happens?
05/28/2006 (9:20 pm)
Darrel,The specific case I'm thinking of can be summarized by this: I am driving a car around. I send it rolling down a long incline. Then I run rapidly away in the opposite direction, until it's outside the area of terrain I have stored in memory. What happens?
#8
Thanks for the clarification - now I understand. Your question intrigued me, so I tested it.
Executive Summary: The buggy will roll down the hill and come to rest in the same way it does as if I were sitting there watching it.
Full Test Summary: Started the starter.racing game. Went into World Editor Inspector and selected the player buggy. Changed its z axis to 360 and watched it fall back to the ground normally (control test). Recorded the "at rest" position of the buggy in notepad. Selected one of the spawn spheres and changed its position to 100000 100000 360, then selected "Camera to selection" so my camera was now far enough away from the buggy so that the terrain under the buggy (or anywhere even near the buggy) was no longer in the scenegraph. I then selected the buggy from the Simgroup list. I then changed the buggy's z-axis again to 360 (exactly like I did in the control test). I then waited a minute to allow the buggy to either fall through the terrain or to collide with the terrain. I then selected "Camera to selection" again to take my camera back to the buggy since it was now selected. Result: The buggy came to rest on the terrain normally.
In addition, I have observed the following in starter.fps:
Kork will continue running around his paths even when I move my player and camera to location 10000, 10000 (or -10000, -10000), either in single or multi-player game with either 1 human player or multiple human players. In a multi-player game with multiple human players, the human players can go out to diverse locations (10's of thousands of coordinates apart) and when they come back, Kork is still doing his thing.
Since I'm only replacing the various and sundry getHeight functions, the rest of TGE is doing "whatever it would normally do" without ever knowing that I've done the switch :-)
Let me know if you'd like me to run any other types of tests, as they are very valuable to add to my testing regimen.
Thanks!
05/29/2006 (8:27 pm)
@Ben:Thanks for the clarification - now I understand. Your question intrigued me, so I tested it.
Executive Summary: The buggy will roll down the hill and come to rest in the same way it does as if I were sitting there watching it.
Full Test Summary: Started the starter.racing game. Went into World Editor Inspector and selected the player buggy. Changed its z axis to 360 and watched it fall back to the ground normally (control test). Recorded the "at rest" position of the buggy in notepad. Selected one of the spawn spheres and changed its position to 100000 100000 360, then selected "Camera to selection" so my camera was now far enough away from the buggy so that the terrain under the buggy (or anywhere even near the buggy) was no longer in the scenegraph. I then selected the buggy from the Simgroup list. I then changed the buggy's z-axis again to 360 (exactly like I did in the control test). I then waited a minute to allow the buggy to either fall through the terrain or to collide with the terrain. I then selected "Camera to selection" again to take my camera back to the buggy since it was now selected. Result: The buggy came to rest on the terrain normally.
In addition, I have observed the following in starter.fps:
Kork will continue running around his paths even when I move my player and camera to location 10000, 10000 (or -10000, -10000), either in single or multi-player game with either 1 human player or multiple human players. In a multi-player game with multiple human players, the human players can go out to diverse locations (10's of thousands of coordinates apart) and when they come back, Kork is still doing his thing.
Since I'm only replacing the various and sundry getHeight functions, the rest of TGE is doing "whatever it would normally do" without ever knowing that I've done the switch :-)
Let me know if you'd like me to run any other types of tests, as they are very valuable to add to my testing regimen.
Thanks!
#9
06/06/2006 (1:59 pm)
I can't wait to get my filthy hands on this code. Incidentally, a random seed was all I needed in my old game, "Deranged Raid", to generate the whole terrain. That was especially nice since it reduced the map data to be transferred to the network clients to a simple number ;)
#10
This resource will be HUGE when it comes out
06/25/2006 (9:31 pm)
Any new news? Sorry just can't wait to get this working in my game :)This resource will be HUGE when it comes out
#11
Thanks for your patience, and sorry for not posting sooner. I've been working on a thorny problem with the IGHTC around terrain reps. Here's a brief overview of the bug: basically, what's happening is that for some terrain reps (haven't figured out the pattern yet), the terrain just goes completely "jagged" -- every other height point is zero, so you get a terrain of "dagger mountains" as I've come to call them.
This bug doesn't happen all the time, or even very frequently, but it's happens in the same terrain reps for a given set of seed values (and the reps where it happens changes when the seed values change).
I'm 99% certain this is happening because some piece of code (I'm looking through terrainConvex class currently) is using TerrainBlock's getHeightAddress in a "Unique and Interesting" way :-)
I've also been working on my Cusey.org website - getting the coppermine gallery to work (a) correctly with PHP-Nuke and (b) patch all the bugs and security hole - so that I could post many many many screenshots there and not leech GG's bandwidth.... and I just got everything working as of last night (hurray!!!)
Anywho, again, sorry for not posting earlier everyone -- I've been a bit "heads down" in the code for awhile now. If there's anyone out there's who's intimately familiar with the TGE terrain code who'd like to help... :-D
06/30/2006 (5:49 am)
Hey everybody!Thanks for your patience, and sorry for not posting sooner. I've been working on a thorny problem with the IGHTC around terrain reps. Here's a brief overview of the bug: basically, what's happening is that for some terrain reps (haven't figured out the pattern yet), the terrain just goes completely "jagged" -- every other height point is zero, so you get a terrain of "dagger mountains" as I've come to call them.
This bug doesn't happen all the time, or even very frequently, but it's happens in the same terrain reps for a given set of seed values (and the reps where it happens changes when the seed values change).
I'm 99% certain this is happening because some piece of code (I'm looking through terrainConvex class currently) is using TerrainBlock's getHeightAddress in a "Unique and Interesting" way :-)
I've also been working on my Cusey.org website - getting the coppermine gallery to work (a) correctly with PHP-Nuke and (b) patch all the bugs and security hole - so that I could post many many many screenshots there and not leech GG's bandwidth.... and I just got everything working as of last night (hurray!!!)
Anywho, again, sorry for not posting earlier everyone -- I've been a bit "heads down" in the code for awhile now. If there's anyone out there's who's intimately familiar with the TGE terrain code who'd like to help... :-D
#12
09/15/2006 (10:55 am)
Any News?
#13
09/23/2006 (12:50 pm)
I'm curious as well, i didnt have any luck pulling up Cusey.org either
#14
Basically, in terrain rep 0,0 ( in the example FPS, this is where you spawn in) everything works perfectly -- but on every other terrain rep only every _other_ terrain point was correct, so you would get what looks like a field of enormous daggers. I figured out pretty quickly that this was due to the fact that there is no single authoritative class (no "expert" in OO terms) as to what was the exact terrain height at any given point. At last count, I had found 12 separate functions in 5 separate classes that each could, in one form or another, provide the terrain height at a given point. Testing the functions in isolation, they all seemed to give completely different answers as well. I obviously needed to learn more...
So, I visited the IRC channel, sent e-mails to Ben (and a couple other associates) and asked for help generally wherever I thought it was appropriate. I made sure to ask for explanations to get a better understanding of how the terrain system worked, and I never once asked anyone to write code for me or anything like that (I've always written my own code). All my requests, however, were met with either rude responses like, "I'm not a walking information board," or were completely ignored.
After a month of code tracing and another month of asking for help and getting completely "stone walled," I shelved working with Torque generally and GG specifically. The whole experience just left a bad taste in my mouth. GG had always been very helpful and supportive in the past (like for the simplification project), so I don't know what happened here.
In any case, I'm now working in my free time doing QA on contract for a AAA game developer -- so, I'm extremely busy and haven't looked at Torque since August.
What I _did_ have working I handed over to Vincent Billet (DragonHead Studios)... but I don't know if he'll be able to use it or not.
09/23/2006 (8:17 pm)
Through July and August, I spent much of my free time trying to track down an issue the IGHTC was exhibiting where the terrain would look normal in terrain rep 0,0 -- but on every other terrain rep it looked like "dagger mountains." Basically, in terrain rep 0,0 ( in the example FPS, this is where you spawn in) everything works perfectly -- but on every other terrain rep only every _other_ terrain point was correct, so you would get what looks like a field of enormous daggers. I figured out pretty quickly that this was due to the fact that there is no single authoritative class (no "expert" in OO terms) as to what was the exact terrain height at any given point. At last count, I had found 12 separate functions in 5 separate classes that each could, in one form or another, provide the terrain height at a given point. Testing the functions in isolation, they all seemed to give completely different answers as well. I obviously needed to learn more...
So, I visited the IRC channel, sent e-mails to Ben (and a couple other associates) and asked for help generally wherever I thought it was appropriate. I made sure to ask for explanations to get a better understanding of how the terrain system worked, and I never once asked anyone to write code for me or anything like that (I've always written my own code). All my requests, however, were met with either rude responses like, "I'm not a walking information board," or were completely ignored.
After a month of code tracing and another month of asking for help and getting completely "stone walled," I shelved working with Torque generally and GG specifically. The whole experience just left a bad taste in my mouth. GG had always been very helpful and supportive in the past (like for the simplification project), so I don't know what happened here.
In any case, I'm now working in my free time doing QA on contract for a AAA game developer -- so, I'm extremely busy and haven't looked at Torque since August.
What I _did_ have working I handed over to Vincent Billet (DragonHead Studios)... but I don't know if he'll be able to use it or not.
#15
I have no messages from you. (Searched my inbox for "Darrel Cusey.") It's possible it got lost when our e-mail was switched over about a month ago to new servers, or possibly it got spam filtered (although I think even that should have shown up in my search - we're using gmail).
So I guess it got lost in the ether... either way, we didn't intentionally ignore you, and would love to see you succeed here, my initial somewhat prickly reception notwithstanding. :)
Vincent is also very bad at sending me e-mail, for whatever reason (maybe the e-mail servers in France don't like talking to GMail?), so he might not be the best choice to hand off to. ;)
Anyway, I'd like to make things right here. If you can resend your mail, I'll gladly look over your changes and offer you what advice I can. Have you considered using modulo instead of bitmask operations? The latter tend to mess up on negative numbers.
Regards,
Ben Garney
09/24/2006 (12:43 pm)
Hey Darrel,I have no messages from you. (Searched my inbox for "Darrel Cusey.") It's possible it got lost when our e-mail was switched over about a month ago to new servers, or possibly it got spam filtered (although I think even that should have shown up in my search - we're using gmail).
So I guess it got lost in the ether... either way, we didn't intentionally ignore you, and would love to see you succeed here, my initial somewhat prickly reception notwithstanding. :)
Vincent is also very bad at sending me e-mail, for whatever reason (maybe the e-mail servers in France don't like talking to GMail?), so he might not be the best choice to hand off to. ;)
Anyway, I'd like to make things right here. If you can resend your mail, I'll gladly look over your changes and offer you what advice I can. Have you considered using modulo instead of bitmask operations? The latter tend to mess up on negative numbers.
Regards,
Ben Garney
#16
Here's the original e-mail. I'm using gmail too, so not sure what went wrong -- unless of course gmail is the culprit :-)
Everything in the e-mail below is still correct except for the links -- the domain is no longer running, so if you see this post, I can send you the screenshots and the code in a zip file via e-mail.
From: Darrel Cusey Mailed-By: gmail.com
Reply-To: darrelcusey@gmail.com
To: beng@garagegames.com
Date: Jul 7, 2006 10:21 AM
Subject: In-Game Huge Terrain Creator (IGHTC)
Reply | Reply to all | Forward | Print | Add sender to Contacts list | Delete this message | Report phishing | Show original | Message text garbled?
Ben,
I've been putting off this e-mail as long as I can because I've been
trying as hard as I can to solve this issue myself -- but, I'm stuck
and would really appreciate any assistance you could provide.
I've been working on the IGHTC for some time now, and am stuck on this
issue where the terrain renders perfectly at Terrain Rep 0,0 (where
the player origin is), but will "dagger" on any other terrain reps.
It seems like the TerrainBlock::getHeight function is getting called
to create Terrain Rep 0,0; and something else is being used for all
other Terrain Reps.
I've got screenshots here:
Terrain Block 0,0 (works fine):
http://www.cusey.org/modules.php?name=coppermine&file=displayimage&album=2&pos=8
Outer Terrain Blocks (dagger bug):
http://www.cusey.org/modules.php?name=coppermine&file=displayimage&album=2&pos=9
My implementation was to create a new class called "PatternManager"
and I've called its function PatternManager::getHeight(x,y) from
various places in the TerrainBlock class (effectively overriding the
TerrainBlock functions).
Attached is a file describing the changes I made to the TGE 1.4 HEAD.
Any advice, insight, comments, you can offer would
be greatly appreciated.
Thanks!!!!
09/24/2006 (10:38 pm)
Ben,Here's the original e-mail. I'm using gmail too, so not sure what went wrong -- unless of course gmail is the culprit :-)
Everything in the e-mail below is still correct except for the links -- the domain is no longer running, so if you see this post, I can send you the screenshots and the code in a zip file via e-mail.
From: Darrel Cusey
Reply-To: darrelcusey@gmail.com
To: beng@garagegames.com
Date: Jul 7, 2006 10:21 AM
Subject: In-Game Huge Terrain Creator (IGHTC)
Reply | Reply to all | Forward | Print | Add sender to Contacts list | Delete this message | Report phishing | Show original | Message text garbled?
Ben,
I've been putting off this e-mail as long as I can because I've been
trying as hard as I can to solve this issue myself -- but, I'm stuck
and would really appreciate any assistance you could provide.
I've been working on the IGHTC for some time now, and am stuck on this
issue where the terrain renders perfectly at Terrain Rep 0,0 (where
the player origin is), but will "dagger" on any other terrain reps.
It seems like the TerrainBlock::getHeight function is getting called
to create Terrain Rep 0,0; and something else is being used for all
other Terrain Reps.
I've got screenshots here:
Terrain Block 0,0 (works fine):
http://www.cusey.org/modules.php?name=coppermine&file=displayimage&album=2&pos=8
Outer Terrain Blocks (dagger bug):
http://www.cusey.org/modules.php?name=coppermine&file=displayimage&album=2&pos=9
My implementation was to create a new class called "PatternManager"
and I've called its function PatternManager::getHeight(x,y) from
various places in the TerrainBlock class (effectively overriding the
TerrainBlock functions).
Attached is a file describing the changes I made to the TGE 1.4 HEAD.
Any advice, insight, comments, you can offer would
be greatly appreciated.
Thanks!!!!
#17
Hey Darrel,
Well, first thing I would look into is whether this issue occurs on negative reps but not positive ones.
Beyond that your changes look fine, but w/o seeing more of your implementation I couldn't speculate as to what might be up there.
I'd recommend writing some quick tests to find out if you're getting stuff that's reasonably continuous for an arbitrary rect of terrain heights (say, that the slope for a given section of height is never over some value, being careful to make your math proof against wrapping), then trying that on some different possibilities.
Or just dumping out known bad areas, if it turns out you can reproduce the issue from your pattern manager directly. Sawtoothing like you describe could result from bad values, or it could result from the downconvery to U16 that happens in the height queries (ie, you have a value bigger than S16_MAX and it's overflowing into a very negative value).
Regards,
Ben
09/25/2006 (1:18 am)
My Reply (also sent via e-mail)Hey Darrel,
Well, first thing I would look into is whether this issue occurs on negative reps but not positive ones.
Beyond that your changes look fine, but w/o seeing more of your implementation I couldn't speculate as to what might be up there.
I'd recommend writing some quick tests to find out if you're getting stuff that's reasonably continuous for an arbitrary rect of terrain heights (say, that the slope for a given section of height is never over some value, being careful to make your math proof against wrapping), then trying that on some different possibilities.
Or just dumping out known bad areas, if it turns out you can reproduce the issue from your pattern manager directly. Sawtoothing like you describe could result from bad values, or it could result from the downconvery to U16 that happens in the height queries (ie, you have a value bigger than S16_MAX and it's overflowing into a very negative value).
Regards,
Ben
#18
09/25/2006 (6:31 pm)
please don't give up on this , this will be so awesome if we can get it working :)
#19
Ben has been contacting me offline and giving me some excellent suggestions for things to check out. So, I'm working on it again with Ben pointing me in the right directions :)
09/27/2006 (8:51 am)
@Jason:Ben has been contacting me offline and giving me some excellent suggestions for things to check out. So, I'm working on it again with Ben pointing me in the right directions :)
#20
09/27/2006 (10:09 pm)
Awesome I wish you all the luck 
Torque Owner Darrel Cusey