IGHTC (In-Game Huge Terrain Creator) Part 2

Submit your own resources!

Darrel Cusey   (May 25, 2006 at 05:25 GMT)

Comments and questions are always welcome!

Mincetro   (May 25, 2006 at 11:35 GMT)

Does the IGHTC allow realtime deforming of terrain, or is it fixed like Atlas?

Maxwell Marsh   (May 25, 2006 at 14:23 GMT)

Does it do water?

Ed Averill   (May 25, 2006 at 18:05 GMT)

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

Ben Garney   (May 25, 2006 at 18:19 GMT)

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?

Darrel Cusey   (May 29, 2006 at 04:11 GMT)

@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 :-)

Ben Garney   (May 29, 2006 at 04:20 GMT)

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?

Darrel Cusey   (May 30, 2006 at 03:27 GMT)

@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!

Josef Jahn   (Jun 06, 2006 at 20:59 GMT)   Resource Rating: 5

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 ;)

Jason Burch   (Jun 26, 2006 at 04:31 GMT)   Resource Rating: 5

Any new news? Sorry just can't wait to get this working in my game :)

This resource will be HUGE when it comes out

Darrel Cusey   (Jun 30, 2006 at 12:49 GMT)

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

Jason Burch   (Sep 15, 2006 at 17:55 GMT)   Resource Rating: 5

Any News?

Jeff Loveless   (Sep 23, 2006 at 19:50 GMT)

I'm curious as well, i didnt have any luck pulling up Cusey.org either

Darrel Cusey   (Sep 24, 2006 at 03:17 GMT)

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.

Ben Garney   (Sep 24, 2006 at 19:43 GMT)

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

Darrel Cusey   (Sep 25, 2006 at 05:38 GMT)

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 <darrelcusey@gmail.com> 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!!!!

Ben Garney   (Sep 25, 2006 at 08:18 GMT)

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

Jason Burch   (Sep 26, 2006 at 01:31 GMT)   Resource Rating: 5

please don't give up on this , this will be so awesome if we can get it working :)

Darrel Cusey   (Sep 27, 2006 at 15:51 GMT)

@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 :)

Jason Burch   (Sep 28, 2006 at 05:09 GMT)   Resource Rating: 5

Awesome I wish you all the luck

Bill "Black Manatee" Pomidor   (Nov 17, 2006 at 11:46 GMT)

This would be a fantastic resource, something that would make a big difference in terms of realism and the range of games that can be programmed (and give TGE another boost vs other game engines!). I hope you are able to figure it out and get the help you need. Between the excellent 1.5 update, things like the lighting pack and showtool, and the eventual Constructor (and the great new tutorials), TGE is turning into a user-friendly yet sophisticated and feature-rich platform.

And the prospect of TorqueX is just icing on the cake (actually, more than that--it's the *presents* too!). Good luck!

Jason Burch   (Nov 17, 2006 at 15:49 GMT)   Resource Rating: 5

@Darrel Cusey

Any new news on the progress of IGHTC?

Darrel Cusey   (Nov 30, 2006 at 23:28 GMT)

Hey Jason and others,

Well, as you can imagine, the terrain system in TGE is bit complex. I've gotten help from a community member (and I'll leave it up to him if he wants to reveal his identity :D ) and we're building on top of the terrainManager code. Currently, we're still using terrain "blocks" since the entire engine is hardwired assuming the terrain blocks are there (and many parts of TGE access the block data directly instead of through an accessor method unfortunately). I don't want to yet say that we've got the terrainManager code doing 100% of what it was initially intended to do, but it seems very close. Plus, we've got the pattern layer system supplying the height data. Here's some highlights of the parts that _are_ currently working:

1. We can currently load up terrain that's 49 times larger than the stock TGE (a 7 x 7 grid of different terrain blocks). There are currently no issues with collision and no issues with the seams between terrain blocks (they are seamless and fit together perfectly). Also, the issue that I was experiencing earlier with "sawtooth terrain" has been solved. The plan is to use a 3x3 or 5x5 grid in the final version and "forward build" as you move across the terrain. This second part isn't in place yet, but that's the direction we're heading in.

2. The terrain that's built uses the pattern layer system I described in earlier posts so that no pre-generation of terrain is required (you just feed the system 2 pattern seeds and it does all the rest).

3. In-line smoothing of the generated terrain is working (it's not blocky anymore like you saw in the first DEV screenshots). I've got a couple algorithms in place that are very very fast (as you can imagine they have to be) and am working on a couple of other ones.

4. We can currently edit the terrain blocks built by the pattern layer system, save them, and re-load them. This includes editing textures, colors, heights, everything you can do in stock TGE. Edits that cross terrain block boundaries work fine as well.


So, things are going pretty good. It's taking awhile because every time we touch 1 part of the system, 20 different things break... but, we're working through it :)

Jason Burch   (Dec 01, 2006 at 00:17 GMT)   Resource Rating: 5

@Darrel

Thanks soo much for your hard work!!!!

I am glad to hear the good news 5x5 or even 3x3 is better than what we have now :)

can't wait to see this working!!

Josef Jahn   (Dec 01, 2006 at 09:28 GMT)   Resource Rating: 5

Indeed, your work is very much appreciated. Torque's terrain code is, frankly, complicating things a lot.

BTW, did you read John Carmack's interview about his megatexture thingy, where he disregarded the many years of research that went into adaptive terrain LOD as "wasted"? ;)

Darrel Cusey   (Dec 01, 2006 at 16:27 GMT)

I read the megatexture thingy. I don't know why he's calling it "wasted" since the technology currently fuels several AAA game engines and several new games currently in development.

Plus, adaptive LOD is definitely the direction Microsoft is heading with DirectX 10 -- you can see it's support has been expanded for vertex buffers, meshes, and even in some of the new curved geometry functions.

Also, maybe I'm just not seeing them yet, but I currently don't see any graphic cards (or upcoming ones) that will natively support texture sizes of 1 gigapixel -- so, you're still swapping textures into and out of the GPU -- but with the megatexture technology, you're just swapping in slices of 1 big texture that's (hopefully) in main memory. At least, that's the only way I can think of that they're accomplishing this. For example, if you look at the ATI Radeon X1650 (one their current top of the line models), it only supports texture sizes of 4k x 4k -- so, you wont' be loading that megatexture into the GPU anytime soon :D

I mean, ETQW looks great and all, but IMHO I think it's not the best direction for the industry to go in since it is making the coupling between your terrain geometry and your texturing even tighter than it already is.

Game worlds are only getting bigger (ie. Dark and Light), and the demand for larger and larger free-form exploration worlds is growing much faster than the technology to support it. And, the "clamping" effect that DirectX 10 is going to have on the introduction of new hardware features will only increase that gap. I predict that the demand for sophisticated procedural generation of terrain geometry, texture, lighting, even content is going to grow as the gap increases and the cost of content development increases.

But, that's all just my opinion, of course :)

Ben Garney   (Dec 02, 2006 at 00:39 GMT)

Quote:

---

I don't know why he's calling it "wasted" since the technology currently fuels several AAA game engines and several new games currently in development.

---

The basic idea is a fine one. The academics spending years refining their ROAM algorithms to support deferred updates on 16-CPU compute nodes are a little off track if their purpose is to advance the quality of terrain rendering. I want a terrain system that renders in < 10% of frametime and takes a minimal amount of RAM. It needs to be easy to debug and hard to break and it HAS to degraded gracefully on someone's shitty fragmented HD.

Multithreaded iterative LOD updates that can't deal with teleporting or warping cameras are great if you have 100% of CPU to burn, no misbehaved services in the background, and plenty of debugging time.

The techniques outlined here are a nice refinement on a pretty solid and VERY simple CLOD implementation, though I'm still not convinced they're sufficiently performant in a real game scenario.

Using DX10's programmability to implement more complex terrain schemes is a bit narrowsighted IMHO. :)

Darrel Cusey   (Dec 03, 2006 at 05:21 GMT)

@Ben:

WOW! Hey, I'm not here to pick a fight with anyone. Josef just asked me if I'd read the Carmack interview, and I was just offering my opinion on it, that's all -- and who am I? Nobody. I don't believe I've ever insulted you, so I don't know where the "narrowsighted" comment is coming from. Man, this community is getting harsher and harsher every day :(

Ben Garney   (Dec 03, 2006 at 22:17 GMT)

I'm not being harsh at you, I'm being harsh at academics who don't have anything better to do than pursue useless technology paths. Have you seen the volume of research on ROAM-relatives vs. the volume on helpful things like practical LOD scemes, or effective texturing for large objects?

Well, OK, maybe I snapped a little bit on using DX10 for CLOD terrain. :) No harm meant. But I do have some strong opinions on terrain tech. ;)

Darrel Cusey   (Dec 04, 2006 at 00:55 GMT)

Ahhh, yeah ok, I see what you're saying now. I brought up the DX10 example because I've been thinking a lot about the effect DX10/Vista is going to have on the gaming community lately - that's probably not the best example :)

Terence Tan   (Dec 21, 2006 at 01:44 GMT)

Darrel,

I can't say how useful this code/product might be to TGE developers out there. I have been struggling to figure out how to give more terrain texture detail for our game. Since I am the only programmer and scripter and producer and level designer and game designer on my team, it makes it hard to spend any time at all try to figure something like that out. So far our solution has is to reduce the squareSize to 2 for now, which works for current starter levels but may pose issues with later levels. We have TSE, but don't want to use it as our game is a fairly simple one which should run on fairly lowspecced graphics cards(like my home Ti4200, which is my default MUST run well platform)

I am assuming there should be no issues using the default Terrain engine and/or IGHTC in the same CodeBase.
Edited on Dec 21, 2006 01:47 GMT

Darrel Cusey   (Dec 24, 2006 at 19:48 GMT)

Our implementation strategy for IGHTC is to make as few changes to the existing codebase as possible and "farm out" new functionality to new classes (like the AreaManager and the PatternManager) wherever possible.

There _shouldn't_ be any reason at all why you couldn't create a new class variable in the AreaManager class that you could use to wrap an if/else block around the old code and the new code calls. However, since the "terrain data" (deltas) under IGHTC are stored completely differently, you wouldn't be able to use IGHTC terrains under the default terrain engine or vice-versa.

Matthew Peychich   (Dec 30, 2006 at 14:38 GMT)

Hey Darrel,

I saw your plan here in the resources and found it extremely interesting. I am curious as to how far along it is in relation to your planned design goals.

Darrel Cusey   (Jan 09, 2007 at 19:54 GMT)

Hehe, well considering I started in May, 2006 -- a bit slower than I initially planned. Of course, at the time I didn't think I'd have to re-write the terrain system from the ground up (which is pretty much what we're doing at this point). Looking at it another way, considering it's just me and another community member working on it in our spare time, faster than I could ever ask for :)

My initial design goals were to add a patternManager class to the engine, and from that derive a patternTerrain class, which would contain the getHeight() method to replace the getHeight() in the various terrain* classes suing the IGHTC pattern layer system. My initial design goal was to work on this for one month. This took me all of about a month to do in a very simplistic way (no console interface for the class variables or arrays for example).

Then I discovered the "dagger mountains" problem and found out that the non-primary terrain blocks aren't handled the same way as the primary (0,0) terrain block. That's when I started really digging into the terrain classes... and it was all "downhill" from there :) I started making a list of all the things that I'd need to change to fix this. It was like a stack of dominoes falling. The list kept growing and growing and growing....

At this point a community member with more experience in the terrain classes than I stepped in and volunteered to help and began to resurrect the AreaManager class which did things almost exactly the way we wanted. After a few weeks of work the "dagger mountains" issue was solved and full integration of the AreaManager system with the patternManager system began and we've been working on that every since.

Currently, we are still using "terrain blocks" to present the terrain data to the system, but we've solved the seam issues that were present in the original AreaManager system, and have the data being derived from the IGHTC pattern layer system. This is a huge accomplishment, but our final design goal is to do away with the "block" system altogether - which will greatly simplify things in the end, but will just take a lot of work to accomplish.

Jason Burch   (Jan 09, 2007 at 20:42 GMT)   Resource Rating: 5

@Darrel

Great work on getting it this far!!!

Can we see an example of what it looks like now with the block system?

Just using the block system for now would be a great start for some of us :)

Darrel Cusey   (Jan 09, 2007 at 23:09 GMT)

Currently, we're still working out a few bugs. It's not currently stable enough for a beta release or even a technology preview release.

Darrel Cusey   (Jan 09, 2007 at 23:39 GMT)

I've had enough people ask the "reverse engineer a terrain" question that I thought I'd better post a response before my e-mail responses start sounding like form letters :D

Essentially, the question goes like this: "Would it be possible to create a heightmap and then reduce it into a set of patterns, and therefore reduce those into a set of seed values?" Another version of this question concerns reducing terrain edits into seeds so that a delta file would be unnecessary (edits would only require changes to the seeds).

Unfortunately, the answer is no. It is so close to statistically impossible to reduce a given heightmap (or a single terrain edit) into a set of pattern layer patterns that is might as well be considered impossible.... To understand why, it may help to understand a little more about how the pattern layer system works.


Each terrain pattern is represented internally as a single 64-bit number (representing an 8x8 matrix). Currently the system uses just 64 such 8x8 patterns. The system takes as input two 32-bit numbers (the X and Y coordinates of the terrain for which you are requesting the height). From these 2 sets of 32 bits, the following are extracted: a pattern selection (6 bits representing a number from 0 to 63), and a pattern coordinate (3 bits for the x coordinate within the chosen pattern (0 to 7) and 3 bits for the y coordinate within the chosen pattern (0 to 7). The result is either a 1 or a 0 indicating whether the terrain is on or off at that coordinate at that layer. If it is on, the layerheight for that layer is added to the final height. The bits are then shifted right and the sequence is repeated until all the input bits are used up. As the input bits increase in significance, the layerheight values increase representing the fact that larger geographic feature cover more terrain.

So, what this means is that for every possible combination of 64 bits (1,844,674,407,370,9551,616 possible combinations), we are only using 64. Therefore, the probability that any given "terrain edit" (which would represented as a pattern change) or input terrain point matching one of the patterns defined in the system is exactly 1 in 288,230,376,151,711,744. So, there's a very slim chance that the change that is made (or an input terrain given) would match an existing pattern and could (therefore) be reprented by an existing pattern.

But that's just for one layer. The system currently uses 28 pattern layers. So, the probability that any given edit would find a match on all 28 layers is something like 1 in 7.4595556511816583890366001320902e+488 (note the e+488).

Now, one solution to this problem would be to greatly increase the size of the base patterns to increase the chance of a match. Taking this to the extreme, you would be left with only 1 available pattern layer, but 1,844,674,407,370,9551,616 base patterns each taking a DOUBLE of memory. So, if your system had 34,359,738,368 GIGS of RAM to store these patterns, and if you were "ok" with having a single layer terrain that looks terrible, you'd have a 100% chance to find a match. Since computers don't have this much memory, let's find what the probablility would be at a more reasonable solution. Let's say you devoted 1 GIG of RAM to your patterns. Doing so would bring your chance up to a "stellar" 1 in 536,870,912 :D

So, the answer unfortunately is no - a single set of seeds cannot be derived from a giving input terrain because the system only uses 64 patterns in 28 layers to build the terrain and the probability that the input terrain could conform to any given pattern combination is so minutely small that you'd never find a single input terrain that could be reduced as such even if you spent your entire life searching.

Paradoxically, the small number of base patterns is actually the system's true strength. Using just this small number of base patterns, the system is able to generate over 18,446,744,073,709,551,616 unique terrains that could theoretically cover an area of 4,294,967,296 x 4,294,967,296 terrain points with no repetition (if you had a rendering system that could render that much terrain all at once).

Jason Burch   (Jan 10, 2007 at 18:44 GMT)   Resource Rating: 5

@Darrel

Ouch my brain hurts....


A 4,294,967,296 X 4,294,967,296 terrain that is insane!!!

Thanks for the lengthy explanation.

Jason Burch   (Feb 09, 2007 at 16:33 GMT)   Resource Rating: 5

Screens?

Updates?

Darrel Cusey   (Feb 10, 2007 at 21:11 GMT)

Alright... I've reached 3 points with IGHTC:


1) I'm at the point where I can release code to the community. The AreaManager is stable enough that it reliably loads/edits/save multiple terrain blocks. The PatternManager is 100% stable, but I wasn't able to successfully expose the layerHeight array or the pattern array to the console (hence the large number of class variables).

2) I'm at the point where any further development of this code is simply beyond my coding capabilities. This is, basically, the best that myself (and the community member who has been helping me) have been able to do given the available time to do it.

3) I'm at the point where I cannot develop the code any further given other responsibilities in my life, and available time.

So... this is what I'm going to do:

a) I'm releasing the full AreaManager code _FREE_ to the community. The 2 bugs that we have not been able to resolve are : Collission Detection on the outer edges of the terrain blocks sometimes doesn't work correctly and; Full Dynamic loading of terrain blocks is not yet complete, but the full framework is there.

b) I'm releaseing the full PatternManager code _FREE_ to the community. This is really incredibly simple code when you look into it. Let me apologize in advance for the sore foreheads that many people may get from all the ::palm-slapping-forehead:: that'll happen when people see how easy this was.

When this resource passes through moderation, you should be able to get it here:

IGHTC Code Release STABLE

IGHTC STABLE Sample mission files

...and...

IGHTC Code Release HEAD

IGHTC HEAD Sample mission files
Edited on Feb 10, 2007 22:17 GMT

Jason Burch   (Feb 12, 2007 at 14:58 GMT)   Resource Rating: 5

Awesome, Can't wait to try it out finally


Great work Darrel!!

Josef Jahn   (Feb 12, 2007 at 16:34 GMT)   Resource Rating: 5

Thanks a lot, I will integrate it into our MMOFPS project and share any improvements or additions that we come up with.

Ooooh this reminds me of my old DerangedRaid project, where all I needed to do to transmit a map to a client was to send him one long value, and that was it. Diamond-Square FTW ;)

Jason Burch   (Feb 12, 2007 at 17:05 GMT)   Resource Rating: 5

Josef that would be awesome...

I'm going to implement this into a MMO as well.

Josef Jahn   (Feb 13, 2007 at 20:34 GMT)   Resource Rating: 5

Jason, what are your experiences with the code so far? I've hit a problem, which I detailed in a resource comment on the stable version.

Jason Burch   (Feb 13, 2007 at 21:15 GMT)   Resource Rating: 5

I haven't had time to look at the code yet just downloaded it and that's it so far.

Will give it a try hopefully tomorrow

Jason Burch   (Apr 11, 2007 at 15:01 GMT)   Resource Rating: 5

@Darrel are there any changes to this ?

I haven't been able to get time to test it in 1.4 since I'm creating 2 games right now.

Will this ever be ported to 1.5?

Tom Honaker   (Sep 02, 2008 at 19:17 GMT)

Another bump out of the archive zone to ask if anyone has ported this into 1.5.x sucessfully. Between this resource and the Modernization Kit TGE will be a force to be reckoned with...

You must be a member and be logged in to either append comments or rate this resource.

Home | Products | Solutions | Downloads | Support | Search | About Us
Copyright © GarageGames.com 2000 - 2008 All Rights Reserved