Seemless terrain/mission transitions?
by Travis Vroman · in Torque Game Engine · 03/15/2007 (5:01 pm) · 13 replies
Okay, I've been searching for days on end for a possible answer to this before posting, found nothing thus far. I've found some posts from very old versions of TGE asking the same question, but they all contained dead links and the topics are dead, without answering the topic at hand.
What I need to know is how to get multiple missions/terrains to blend seamlessly in TGE 1.5 (not TSE). To clarify, I'm looking for continuous terrain functionality similar to that of World of Warcraft. In theory what I'd like to accomplish is to be able to walk freely between missions/terrains seamlessly, without loading screens or loading time, or use of portals. For instance, here's a layout example of what I'd like to accomplish, in a simplified grid form:
Each square here represents a seperate mission/terrain with its own texture sets and waterblocks. Say that you were standing in square 13, for instance. From there, you should be able to see squares 7, 8, 9, 12, 14, 17, 18 and 19. Say that now you move north to square 8, which would load squares 2, 3, and 4 so you could see them, but squares 17, 18 and 19 would now be destroyed in memory to conserve system resources.
I'm sure that there has to be a way to do this, I just haven't been able to figure it out yet. Agian, I'm not looking for one big terrain file here, I'm only looking to merge together a bunch of terrain files to form a world. Any help with this would be greatly appreciated. Has anyone else out there found anything out on how to do this?
Thanks,
-Barzahd
What I need to know is how to get multiple missions/terrains to blend seamlessly in TGE 1.5 (not TSE). To clarify, I'm looking for continuous terrain functionality similar to that of World of Warcraft. In theory what I'd like to accomplish is to be able to walk freely between missions/terrains seamlessly, without loading screens or loading time, or use of portals. For instance, here's a layout example of what I'd like to accomplish, in a simplified grid form:
Each square here represents a seperate mission/terrain with its own texture sets and waterblocks. Say that you were standing in square 13, for instance. From there, you should be able to see squares 7, 8, 9, 12, 14, 17, 18 and 19. Say that now you move north to square 8, which would load squares 2, 3, and 4 so you could see them, but squares 17, 18 and 19 would now be destroyed in memory to conserve system resources.
I'm sure that there has to be a way to do this, I just haven't been able to figure it out yet. Agian, I'm not looking for one big terrain file here, I'm only looking to merge together a bunch of terrain files to form a world. Any help with this would be greatly appreciated. Has anyone else out there found anything out on how to do this?
Thanks,
-Barzahd
#2
There was a pretty good article on gamasutra about this recently.
Streaming for Next-Gen Games
My suggestion is to figure out how to get torque to load/unload different terrains on the fly in the background (no small feat), and then connect them with DIF interiors (so for example, you have to walk through a cave or a canyon or something between each terrain, then put some kind of trigger in the connecting DIFs to cause the terrains to load/unload as needed. A continous "open world" terrain like you describe would be much harder.
Let me know if you get something working. I'm also interested in trying to figure out how to do this with Torque, I might try to add this myself sometime this fall after my current project is done.
Joel
03/15/2007 (10:21 pm)
This is usually called "streaming". It typically works pretty much like you describe. It's not that big a deal if you're writing an engine and keep streaming in mind, but it's pretty hard to add to an exisiting engine. I don't know if anyone has tried adding this to torque.There was a pretty good article on gamasutra about this recently.
Streaming for Next-Gen Games
My suggestion is to figure out how to get torque to load/unload different terrains on the fly in the background (no small feat), and then connect them with DIF interiors (so for example, you have to walk through a cave or a canyon or something between each terrain, then put some kind of trigger in the connecting DIFs to cause the terrains to load/unload as needed. A continous "open world" terrain like you describe would be much harder.
Let me know if you get something working. I'm also interested in trying to figure out how to do this with Torque, I might try to add this myself sometime this fall after my current project is done.
Joel
#3
4 months later, I decided to wait for Atlas...because it's a huge amount of work.
There are many, many hidden aspects of what the engine does for you that you don't realize until you get to trying a major change like this, and like what was mentioned, the engine was built around a single terrain, of a set size (I'm speaking the height grid points). From ray casting across boundaries to collision bin systems that are on separate terrain blocks to stitching heightmaps together during editing to writing a multi-threaded background loader for the streaming terrain blocks to re-lighting to...well, you may get the picture :)
Atlas actually took on 90% of the major tasks for this already, and for the target market hardware TGE 1.5 is designed for, it's ultimately not worth the effort in my personal opinion.
That being said if you have success I would sincerely love to hear about it!
03/15/2007 (10:29 pm)
It's been tried--many times. I tried it myself before I was an employee, and I had a 5,500 line patch file across 20+ files that did a lot of grunt work.4 months later, I decided to wait for Atlas...because it's a huge amount of work.
There are many, many hidden aspects of what the engine does for you that you don't realize until you get to trying a major change like this, and like what was mentioned, the engine was built around a single terrain, of a set size (I'm speaking the height grid points). From ray casting across boundaries to collision bin systems that are on separate terrain blocks to stitching heightmaps together during editing to writing a multi-threaded background loader for the streaming terrain blocks to re-lighting to...well, you may get the picture :)
Atlas actually took on 90% of the major tasks for this already, and for the target market hardware TGE 1.5 is designed for, it's ultimately not worth the effort in my personal opinion.
That being said if you have success I would sincerely love to hear about it!
#4
Here's a thought though. Stemming off of Joel's DIF idea, I wonder if it would be simpler to have a transitional area the player can walk through while the next mission loads up. Meaning, for instance, that if you were walking off of a field into a city, then perhaps this would be done through a curved tunnel, where at some point you could no longer see either of the stages for smooth transition abck and fourth. And while in that tunnel (obviously with a mid to low amount of details and polys to conserve resources) the next mission would load in the background? I mean, is there any reason whatsoever that there needs to be a loading screen past the first one when you load up the game? Is there anything stopping us from being able to render a simple scene while another is loading in the background? Is it possible to stream stage loading by using this tunneling technique? This would avoid the issue of rendering more than one terrain at once, and would also save (at least in part) having to mess around with re-coding the TerrainManager class. At least I think so. Would that be possible using TGE 1.5? I'm just trying to figure out the best idea to get the most results without having to rip out TGE's insides. Thanks for the help guys,
-Barzahd
03/16/2007 (8:40 pm)
Hm. Perhaps it's back to the drawing board for me... >.>Here's a thought though. Stemming off of Joel's DIF idea, I wonder if it would be simpler to have a transitional area the player can walk through while the next mission loads up. Meaning, for instance, that if you were walking off of a field into a city, then perhaps this would be done through a curved tunnel, where at some point you could no longer see either of the stages for smooth transition abck and fourth. And while in that tunnel (obviously with a mid to low amount of details and polys to conserve resources) the next mission would load in the background? I mean, is there any reason whatsoever that there needs to be a loading screen past the first one when you load up the game? Is there anything stopping us from being able to render a simple scene while another is loading in the background? Is it possible to stream stage loading by using this tunneling technique? This would avoid the issue of rendering more than one terrain at once, and would also save (at least in part) having to mess around with re-coding the TerrainManager class. At least I think so. Would that be possible using TGE 1.5? I'm just trying to figure out the best idea to get the most results without having to rip out TGE's insides. Thanks for the help guys,
-Barzahd
#5
Best of luck with your hunt for transitions.
03/16/2007 (9:06 pm)
By what I understand about the Torque's Game engine platform, Even if you mannaged to wipe out the loading screens between mission, There would be lag, and lag time would depend on how large the next mission is. In use of the default size, adding in all th eparts to the mission, interriors, placables, map ellevations, caves (if any) and thier interiors, would cause a minute of lag. What might be better is to change the loading screen to just as you were talking about, a tunnel, where the length of the tunnel is determined by the time spent loading the mission, with 3 AVIs, A start into the tunnel, Walking/running threw the tunnel, then exititing the tunnel, The entrance and exit should be obscured, so that no actual detail can be decerned, so it automatically looks like just about any mission you load, then it takes the eyes a moment to focus, and the new mission is loaded... Unfortunatelly, there would be no way to turn around durring the tunnel transition to the next mission.Best of luck with your hunt for transitions.
#6
One possible way to get a zero loading time would be to run two instances of the Torque exe, the second one would prefetch the mission as you approach the portal, then swap all your character data when you enter the building.
Another long-shot possibility is to not tile the terrain directly. Torque tiles the exact terrain and objects endlessly, but it could possibly be modified so it uses only one terrain and mission file but they get modified each time it gets tiled. That should be easy to do to the terrain but might be a problem with all the scene objects.
03/17/2007 (9:13 am)
It seems to me that the only way to do this in torque would be to use buildings as portals to the next mission, which would cause a big delay as the mission loads. One possible way to get a zero loading time would be to run two instances of the Torque exe, the second one would prefetch the mission as you approach the portal, then swap all your character data when you enter the building.
Another long-shot possibility is to not tile the terrain directly. Torque tiles the exact terrain and objects endlessly, but it could possibly be modified so it uses only one terrain and mission file but they get modified each time it gets tiled. That should be easy to do to the terrain but might be a problem with all the scene objects.
#7
Communication and dual-ghosting across GameConnections is not impossible, but it is not trivial either.
03/17/2007 (10:36 am)
Quote:
It seems to me that the only way..
Communication and dual-ghosting across GameConnections is not impossible, but it is not trivial either.
#8
Rather than have a separate copy of Torque or something, just start a worker thread when the player enters the "green zone" that unloads the first terrain and all of it's object and loads the second terrain, and the connector DIF for it.
I think portals could be used to create seamless transisions from one side of the map to another. Only one terrain would be loaded at any time and there wouldn't need to be too much modification done to the terrain stuff.
This would still be a lot of work, and I'm pretty sure it wouldn't be feasable in multiplayer situations .. what does the server do when one player stays in map one and the other goes to map2?
Keeping track of what is loaded and making sure a script object doesn't try and refer to stuff that is being unloaded, or hasn't been loaded yet can be a huge pain. I think that would be as much work (if not more) as the mechanics of loading. In any case, it's going to be a huge amount of work.
Anways, I'm not going to try and do this anytime soon, but that's what I was thinking. If you wanted to do this for real, and support multiplayer and stuff, I agree that Atlas sounds like a much better option.
joel
03/17/2007 (1:49 pm)
Here's how I was thinking about doing it. Rather than have a separate copy of Torque or something, just start a worker thread when the player enters the "green zone" that unloads the first terrain and all of it's object and loads the second terrain, and the connector DIF for it.
I think portals could be used to create seamless transisions from one side of the map to another. Only one terrain would be loaded at any time and there wouldn't need to be too much modification done to the terrain stuff.
This would still be a lot of work, and I'm pretty sure it wouldn't be feasable in multiplayer situations .. what does the server do when one player stays in map one and the other goes to map2?
Keeping track of what is loaded and making sure a script object doesn't try and refer to stuff that is being unloaded, or hasn't been loaded yet can be a huge pain. I think that would be as much work (if not more) as the mechanics of loading. In any case, it's going to be a huge amount of work.
Anways, I'm not going to try and do this anytime soon, but that's what I was thinking. If you wanted to do this for real, and support multiplayer and stuff, I agree that Atlas sounds like a much better option.
joel
#9
03/20/2007 (7:54 am)
In concept this would work perfectly. Only problem here is how much the framerate would suffer as mentioned before during the transition. It looks like I'm going to have to sit down and go through that part of the engine line by line to understand its logic. As it stands, it looks like I'm going to have to re-do a lot of parts of the engine. I mean, TGE is a FPS engine and I'm trying to make it run an RPG. I'm not going to deny it's going to be a stupid amount of work to get what I want, but I know TGE can do it. If the Unreal engine can run games like LineageII(Unreal v.2) and Vangard(Unreal v.2.5), any engine should be able to, as Unreal isn't the most stable engine out there. Torque is. :)
#10
A) Adjust field of vision distance...
B) Adjust Fog distance...
C) Create "portals" between rooms within the transit from one mission to the next...
Torque's abillities well surpases the abillities of many engines, and is easilly updated if you know how to code in C++... (Easilly for advanced users... Ultra hard for noobs such as myself who don't know C++...)
03/21/2007 (1:03 pm)
The frame rate would only suffer if you did not:A) Adjust field of vision distance...
B) Adjust Fog distance...
C) Create "portals" between rooms within the transit from one mission to the next...
Torque's abillities well surpases the abillities of many engines, and is easilly updated if you know how to code in C++... (Easilly for advanced users... Ultra hard for noobs such as myself who don't know C++...)
#11
03/21/2007 (3:20 pm)
Ok so what if the player decides to turn around in the middle of the corridor (Phase 2) and walk back to area they just left (Phase 1)? With this scheme...that area would have to be reloaded.
#12
As far as framerate goes, Mogartin is right about maintaining the framerate when drawing large terrains, but I think what Travis is worried about is what the all the background file IO would do to your framerate. I'm on a dual-core system, so it wouldn't be a big deal to just put the loading on a separate thread, but for a single core system this could be very tricky. I haven't looked at Torque's IO closely enough to tell how big a project this would be. It might be hard enough just to get Torque loading in another thread!
Joel
03/21/2007 (6:25 pm)
Yeah, that's kind of an oversimplification. You'd have to put artist-placed triggers in your level for when you want to load what. I'd probably put some kind of "safety" too, like doors that refuse to open if the load is not complete. As far as framerate goes, Mogartin is right about maintaining the framerate when drawing large terrains, but I think what Travis is worried about is what the all the background file IO would do to your framerate. I'm on a dual-core system, so it wouldn't be a big deal to just put the loading on a separate thread, but for a single core system this could be very tricky. I haven't looked at Torque's IO closely enough to tell how big a project this would be. It might be hard enough just to get Torque loading in another thread!
Joel
#13
03/27/2007 (8:11 pm)
Would it be simpler perhaps to make a bunch of mini missions and have them load up as needed? In other words, what if each "mission" were significantly smaller and less detailed, just more of them? Each mission would take less time to load, making it seem like streaming. Bleh, I am so lost on the logic to get this to work right. Once the logic is down pat, I could figure out how to code it eventually. But as any programmer knows, no logic, no program, just crap. I might just have to give up and go with loading times >.< 
Torque Owner Bill Blaiklock
http://www.garagegames.com/mg/forums/result.thread.php?qt=3414
Although it is a bit too simplified for me to make code out of, so I was looking for code from older attempts people made at this. I will probably go back to hacking at it considering I've not found the code.