Command or Map View
by Daniel Neilsen · in Torque Game Engine · 01/21/2002 (6:41 pm) · 19 replies
Just wondering if anyone out there has already done code for a command or map view ??
About the author
#2
i didnt tried but maybe it could be used
01/21/2002 (6:51 pm)
you can use the terraformer view ctrli didnt tried but maybe it could be used
#3
I'm currently trying to do something like this but I'm running into performance issues.
06/09/2002 (11:57 am)
Sorry to bump this but has anyone done any work on this?I'm currently trying to do something like this but I'm running into performance issues.
#6
06/09/2002 (12:34 pm)
Wow, looks very cool! Are these the actual buildings in your level rendered scaled down to fit into this GUI?? If so, mind to share the code... ? ;-)) What is the performance hit (fps) you get displaying this?
#7
There is really nothing fancy about it.
This is what you would actually see if you were to enter camera fly mode and position yourself above the map's mission area.
The only difference is there is no fog in this view.
Unfortunately I'm seeking a way to increase the framerate as the decrease in performance is drastic!
=)
I'm currently getting about 9 average fps when in this view.
I get to this view by doing Canvas.setContent("MapView"); in the console. This effectively stops the drawing of the playGUI content so that I can focus all of the cpu and vid card drawing power to this screen. But even then the fps stays low.
Like I said, nothing fancy is being drawn. I only move the view camera to middle of the mission area and at a height determined by how huge the mission area is. This lets me view the entire mission area at once. I then draw the mission area bounds in a red with some transparancy, as you can see.
I believe this is how Tribes 2 is doing it. But if this is the case, then what else are they doing in Tribes 2 to increase the framerate?
I need help/suggestions on what I can enable/disable as far as gl commands go. Or what I can do to squeeze more performance out of this baby?
06/09/2002 (12:42 pm)
Yes, all those buildings are the actual buildings from the map.There is really nothing fancy about it.
This is what you would actually see if you were to enter camera fly mode and position yourself above the map's mission area.
The only difference is there is no fog in this view.
Unfortunately I'm seeking a way to increase the framerate as the decrease in performance is drastic!
=)
I'm currently getting about 9 average fps when in this view.
I get to this view by doing Canvas.setContent("MapView"); in the console. This effectively stops the drawing of the playGUI content so that I can focus all of the cpu and vid card drawing power to this screen. But even then the fps stays low.
Like I said, nothing fancy is being drawn. I only move the view camera to middle of the mission area and at a height determined by how huge the mission area is. This lets me view the entire mission area at once. I then draw the mission area bounds in a red with some transparancy, as you can see.
I believe this is how Tribes 2 is doing it. But if this is the case, then what else are they doing in Tribes 2 to increase the framerate?
I need help/suggestions on what I can enable/disable as far as gl commands go. Or what I can do to squeeze more performance out of this baby?
#8
Have it rendered at the start of the level, or even better: with the creation of the level.
That way, you can guarantee that a crummy video card wouldn't choke on loading the entire level then zooming way out to take a screenshot.
Easiest way to do it would be to take a screenshot in a fairly high resolution of what you have there (the sky viewing thing) and then save the image, and load it up as the map. It'll look like a 3d map, but just be a simple 2d image which won't affect performance at all!
So basically, what you have there could be a development tool. Use it to take pictures of the level and then use the produced image as the map for the players.
06/09/2002 (1:18 pm)
Easy enough. Just export that 3d image as a png or something. Then, use it in game.Have it rendered at the start of the level, or even better: with the creation of the level.
That way, you can guarantee that a crummy video card wouldn't choke on loading the entire level then zooming way out to take a screenshot.
Easiest way to do it would be to take a screenshot in a fairly high resolution of what you have there (the sky viewing thing) and then save the image, and load it up as the map. It'll look like a 3d map, but just be a simple 2d image which won't affect performance at all!
So basically, what you have there could be a development tool. Use it to take pictures of the level and then use the produced image as the map for the players.
#9
06/09/2002 (1:19 pm)
I guess that you could/should change the textures to lower versions, for example remove the detail texture from the terrain, etc.. viewing all the terrain at once with a detail texture will slow it very much!
#10
I like your idea very much and believe you me I have thought of doing that.
Hell, Tribes 1 does that for thier command screen.
There is a flaw in that decision though. Of which I don't know how to work around.
Idealy I would want to save the image to a bitmap handle in memory, which is fast. But there is a problem of which you can see in the current picture I provided.
I want to be able to zoom in and out. The current picture shows what the map would look like fully zoomed out.
I certainly would like to maintain at least a recognizable image when fully zoomed in, which doing it completely in 3d allows me to do. But if I were to just save that view that I have provided to a bitmap handle in memory and used that for display purposes in game, then if and when a user zoomed in, a lot of detail would be lost.
So much in fact, that the buildings would no longer be recognizable.
That is why I'm currently trying to do this in 3d instead of saving it to an image.
Xavier:
Yes, but how do I do that ? =)
06/09/2002 (1:35 pm)
Matt Webster:I like your idea very much and believe you me I have thought of doing that.
Hell, Tribes 1 does that for thier command screen.
There is a flaw in that decision though. Of which I don't know how to work around.
Idealy I would want to save the image to a bitmap handle in memory, which is fast. But there is a problem of which you can see in the current picture I provided.
I want to be able to zoom in and out. The current picture shows what the map would look like fully zoomed out.
I certainly would like to maintain at least a recognizable image when fully zoomed in, which doing it completely in 3d allows me to do. But if I were to just save that view that I have provided to a bitmap handle in memory and used that for display purposes in game, then if and when a user zoomed in, a lot of detail would be lost.
So much in fact, that the buildings would no longer be recognizable.
That is why I'm currently trying to do this in 3d instead of saving it to an image.
Xavier:
Yes, but how do I do that ? =)
#12
06/10/2002 (10:12 am)
@Robert: no idea :)
#13
I think the performance could be answered with proper use of LOD on the building's.
06/24/2002 (3:11 pm)
hmm ..I think the performance could be answered with proper use of LOD on the building's.
#14
Phil.
06/24/2002 (3:43 pm)
Robert, why not do what Matt says and render it, but simply re-render it if you change resolutions/zoom.Phil.
#15
I must have misunderstood him.
Just so I'm on the same page here :)
Render the scene to a bitmap, and then just
display the bitmap unless there is a state
change. A state change being that of the
user zooming in/zooming out/ or some other
form of interacting with the map itself?
Good idea :)
06/24/2002 (3:49 pm)
Ahh Phil,I must have misunderstood him.
Just so I'm on the same page here :)
Render the scene to a bitmap, and then just
display the bitmap unless there is a state
change. A state change being that of the
user zooming in/zooming out/ or some other
form of interacting with the map itself?
Good idea :)
#16
When I zoom in, I want the ability to "scroll" the map so the player can look at sections of the map not immediately visible in the current view.
How would I accomplish this using the method described above?
Unless there is a way to render the entire scene to a bitmap even if its not visible in the view frustum?
06/24/2002 (3:56 pm)
One question though..When I zoom in, I want the ability to "scroll" the map so the player can look at sections of the map not immediately visible in the current view.
How would I accomplish this using the method described above?
Unless there is a way to render the entire scene to a bitmap even if its not visible in the view frustum?
#17
09/26/2002 (7:28 pm)
what about if you have fog will it still work?
#18
if you made a specific lod for this on each building and set your control to render that mode ..
I would think that the performance hit would be minimal.
09/27/2002 (4:57 pm)
Im curious what kind of LOD is on these hard hitting building's ..if you made a specific lod for this on each building and set your control to render that mode ..
I would think that the performance hit would be minimal.
#19
I think they just rendered the terrain on the very, very lowest possible detail setting, as they did for the buildings, and turned off all the dynamic light stuff (ie, realtime shadow calculations and weapon light sources) as well as not rendering any non-static objects such as players, vehicles, or other weapon fire.
That let 'em render the level very quickly, because they didn't have to do culling, they didn't have to deal with any network stuff beyond drawing a little icon at the right position, and they didn't have to do collision detection or LODing.
They just had to splat a few thousand polygons onto the screen. They may have had fog; I'm not sure. I'd imagine that with a vertex buffer, you could apply all sorts of complex fog effects without losing any performance...
09/27/2002 (7:05 pm)
I agree; the Tribes2 command view was 3d, more or less. If you panned it, the terrain would parallax as expected, and buildings were 3d as well.I think they just rendered the terrain on the very, very lowest possible detail setting, as they did for the buildings, and turned off all the dynamic light stuff (ie, realtime shadow calculations and weapon light sources) as well as not rendering any non-static objects such as players, vehicles, or other weapon fire.
That let 'em render the level very quickly, because they didn't have to do culling, they didn't have to deal with any network stuff beyond drawing a little icon at the right position, and they didn't have to do collision detection or LODing.
They just had to splat a few thousand polygons onto the screen. They may have had fog; I'm not sure. I'd imagine that with a vertex buffer, you could apply all sorts of complex fog effects without losing any performance...
Torque Owner Architecture@Uni Melbourne
we are looking at getting into that also.