#1 This is great, Chris! I've been playing around with 3DEM for a while now, myself, but in a totally different way. I don't really see real world environments being very friendly in terms of level design, so I use the output files inside World Machine to add realism to my maps. Ron Kapaun's Africa Pack map was done in this way, from geo (height) data of Kenya generated via 3DEM and streamed through my WM->T3D pipeline.

Your solution here with T3D Terrain Master looks like a fantastic breakthrough for projects requiring huge real world terrains; like flight sims. Not sure what I can contribute to it though. Still, I'll be keeping an eye on this.

#2 WOW, now this is great Chris, thank you for sharing!!!!

#3 WOW and even Yeepee! I dreamed about terrain paging system and I read you work about it? This is amazing! Thank you for sharing.

#4 Very cool. Paging terrain would be great to see in T3D, though of course if you have paging terrain, paging objects are nice, too... ;P.

Any reason your repository isn't a fork of the main T3D repo?

#5 Wow! I am deciding right now if I want to limit my missions to one terrain or looking for a paging solution. This might be just perfect.

Are you planning to have this worked with networked connections?
Can the terrain be limited to a number of terrains on a per client basis according to view distance?

#6 Nice!

#7 Awesome project, Chris!

#8 Thanks everybody! To get to the questions one at a time...

@Daniel: why it isn't a fork of the main T3D repo... well... because unless I'm understanding it wrong, it seems that github only allows you to have one fork of any given repo. This project is actually fitting into a chain of forks, or projects, which are intended to go increasingly farther and farther away from the main T3D dev branch. I couldn't figure out how to do exactly what I wanted, except by making new repos and creating remotes pointing upstream to wrap everything in. Here's my complete plan, and I would welcome any help from Those Who Know More:

1) I want to have my own direct fork of T3D, which I can use to add any bug fixes or general improvements that I think should be pulled back into the engine. That is ChrisCalef/Torque3D, my first and only actual fork of GarageGames/Torque3D.

2) Next I want to have the T3DTerrainMaster. I could make it a fork of my fork, but really I think I'd rather have it be a direct fork of GarageGames/Torque3D - but here I am asking for two forks already, and github seems to only allow one. However, as I understand it, anyone who grabs a copy of TerrainMaster can manually create an upstream remote pointing at the original GarageGames repo, and still pull changes from there...?

Now, just to spill the beans a little bit, I'm actually planning two more projects, for which I'm already gathering volunteers, even though they are entirely vaporware at this point so don't call the media yet. ;-)

3) the first one is a project I've wanted for ever and ever and ever, and it's about the most ridiculously ambitious thing you've ever heard anyone say, so go ahead and laugh in my face now and get it over with. :-) The repo is already up there waiting for all the work to be done, and it's called ChrisCalef/T3DEarthSim. (The repo is empty, don't bother cloning it.) I want this project to be a fork, or otherwise downstream from, the TerrainMaster project, so as to easily inherit all the work done on that, but this is where I would like to store any and all logic relevant to making a working simulation of the surface of the planet, starting with relatively easy things like vegetation, but working up to importing GIS data for roads, rivers, weather, rainfall patters, soil patterns, etc etc etc. Obviously far more than any one man or small team could ever pull off, but with T3D in the glorious sphere of Open and Free, MIT, I would very much like to gather interest from the halls of academia in order to make this particular dream come true. Not my very topmost priority this week or anything, but on my list.

4) Finally, all of this including parts of the EarthSim project are building up to my GAME, which is intended to be a post apocalyptic model earth where players can see examples of functional, sustainable small scale community design amidst a shattered post-industrial landscape (based in the Southern Willamette Valley). More on that later.

If someone knows how to handle the cascading fork problem on github better than I'm already doing it, I'd love to hear about it!

Now re: the problem of paging objects, I'm way ahead of you, but I actually took that part out for this release because I wanted to keep it simple. I didn't get it all solved or anything, but my test build actually had an SQL connection, and I started saving objects to the database instead of to the mission. The trick is going to be working out a good search method so we're not querying all the bloody time, and storing different visible distances for different kinds of objects (you should see a building from across the valley, but maybe not a stop sign, for example.) Still working on that part, and open for debate as to whether it should go in the TerrainMaster proper or not.

@Frank: Yes, I do want it to work with networked connections, but I haven't worked out exactly how yet. It does run multiplayer right now, but only selects terrains for one player. It would be relatively easy to make it load terrains for both players, but the part I'm not clear on is how to make one player's terrains visible only to him, and not the other player, if they are in different parts of the world. (Ie, only ghost loaded terrains to the client they are relevant for.) Accepting suggestions.

Re: the view distance, yes, they do load by distance right now, the TerrainMaster object has a loadDistance and dropDistance parameters. (make sure the dropDistance is significantly greater than the loadDistance, so you don't get into a drop/load/drop/load/drop situation if you're standing on the line.)

#9 Re: using this for your game right now, Frank, do keep in mind that it DOES NOT WORK right now! That crash bug is really bugging me... hopefully it will be resolved before long however.

#10 Oh wow, the gears in my mind are whirring like crazy!

#11 So, to get right to the point among all of these long term Torque wizards (maybe I should make a forum post about it, but while I have your attention..) does anyone know why the following would not work, to delete a terrain and all of its associated memory? I always struggle with deleting things on the engine side, making sure all the i's are dotted and t's are crossed, so I skipped it this time and just went for script side, assuming that the engine would do what was necessary that way without me having to deal with it.

I have a TerrainGroup simset for storing terrains, and they are also in the MissionGroup, so to delete one, I do the following:

TerrainGroup.remove(%terrain);
      MissionGroup.remove(%terrain);
      %terrain.delete();

However, while the object disappears, it does not seem to have an impact on my memory usage, and the "no more, she's full, captain!" crash comes at more or less the same time whether I do the terrain delete or not... implying that I have not actually cleared the memory.

(Confession, however, this is all theory, I have not checked my actual RAM usage however, that should be the next step...)

Any great ideas out there?

#12 Chris, this looks fantastic :)

Instead of forking forks, maybe use branches instead?
Fork the T3D repo, then create a Terrain Master branch from your forked T3D Master/Development branch.
You can then branch from the Terrain Master branch, or branch again from the T3D fork for some other project.
Once Teraain Master was stable for single player for example you could branch from it to work on multiplayer .... or branch from it to work on EarthSim ;)

I use GitHub for Windows, it makes branch management pretty easy.
windows.github.com/

Sorry if you knew all this, I am figuring out GitHub at the moment ;)

Cheers,

Andy

#13 Hm, yeah I considered branches instead, but in my googling I found some people discussing that solution but finding problems committing up to just a the branch they were aiming at (they could have been total newbs, though.) (And no, I'm very much still figuring out github as well, I don't know much.)

Thanks for the suggestion. It may be that I should switch to the GitHub for Windows client, I'm using TortoiseGit at the moment. Clearly some more experimentation on small test repos is in order...

#14

Quote:Believe it or not, I am actually writing a GG blog which is not about Ecstasy Motion!!!

Shame on you!

Lol but seriously, I have been toying around with an Idea for a FPS that uses real world data.

Fragging your friends in your own back yard, sniping out your bedroom window or taking them on at there own home.

I haven't got it much past the concept stage as I spent a week trying to make sense of the DEM data for Yorkshire England, couldn't seem to get any high enough resolution data and was then left with a lot of gobbledygook I couldn't get into Torque3D.

This however looks much better than I had envisaged, I will take a look at geocomm.com see if they have any UK DEM data.

I do always enjoy your blogs now one that's not about ecstasy motion... whatever next!

#15 Just one thought which I have always found when picking up the paged terrain idea. When you start to create huge worlds and move away from the origin, floating point inaccuracy kicks in and you are more likely to get collision bugs, like falling through terrain.. Have you had any issues with this and do you have any idea for fixing it?
What I thought of was to have a world origin for each terrain, and set the object coordinates relative to the terrain it was stepping on.
(Btw great job, curious as to how you will fix the black borders, shading issue aswell :) )

#16 Ah yes, the black borders... I was under the impression at first that they were an artifact of doing the lightmapping in L3DT, one terrain at a time... but then I realized they are also present on the raw terrains that have not been run through L3DT yet, so NOPE. Hence, I am also curious as to how I am going to solve that problem...

#17 I know someone had a seamless joining of terrains blog, but unsure if they fixed the black borders on the edges of the terrain
www.garagegames.com/community/forums/viewthread/112185/2#comments

#18 Ha, well, here's some good news... the crashing problem actually seems to have... gone away. Not the best way to fix a bug, but I just flew from one corner of the map all the way to the other, loading and dropping all the way, and this time things seemed to be fine. Um... anyway, I'll take it for now!

#19 Hey Chris, looking great, will pull this down tonight and have a proper look tomorrow.
Jump onto vent sometime.

#20 If the terrain sections are ghosted, then they'll only appear to players who are aware of them. That means that terrain segments should "disappear" if they are wholly hidden from the player's view or outside of the specified range. Just like other players.

There is a short overview of ghosting in the docs under Reference Guide->Modules->Networking->On Ghosting and Scoping. The relevant section is fairly terse and is about a third of the way down the page, but it should help explain what I was trying to say.