Non-standard (smaller) terrain sizes... again.
by Kirby Webber · in Torque Game Engine · 05/24/2005 (7:07 am) · 16 replies
I realize that this topic has been addressed before, though in my searches I was not able to locate a definitive answer that suits the need I'm trying to address - I apologize if this has been covered and I somehow missed it.
I am trying to find a way to work with non-standard terrain sizes... that is to say, I need to find a way to work with terrains that are much smaller than what is available "as-is" within the engine.
I have incorporated the non-repeating terrain resource, and so far everything seems to be working as intended.
Additionally, I resized the terrain using a square-size of 2 (which seems to be the lower limit). Unfortunately, this does not produce a terrain as small as what I need for this particular project.
As I understand it (please feel free to correct any misunderstandings I may have on this, after all, knowledge is power. ;) the terrain engine uses a 256 x 256 height map to generate terrain, though the terrain that gets generated is calculated out to 1024 x 1024 tiles.
The problem I'm currently trying to address is that I need to work with about 1/2 to possibly 1/4 of that (even at a square size of two =\ ).
Let me explain what I'm trying to accomplish for clarity.
The project in question requires a terrain display as a sort of 3D tactical view. Basically, it will be a relief map housed inside a modeled table.
This entire scene will then be placed inside a very large interior room, so there is no need for additional terrain outside of this structure.
The terrain needs to be small enough that, given the origin of the terrain, an orbital camera can be generated such that when it is moved around the terrain, the entire map is viewable from any given angle or point on the map.
Clear as mud?
My current thinking is that I'll need to actually reduce the number of terrain tiles generated as well as the square size to get the overall effect I'm looking for.
Just as a quick caveat, collision is a non-issue with regards to this particular project. (C;
Now, I'll admit that I've only begun to scratch the surface regarding the terrain engine and how this might be accomplished, but knowing that there are many here in the community who have a much stronger understanding of the terrain code, I'm hoping that someone here can help point me in the right direction(s).
Thanks in advance - any and all help and/ or advice is appreciated.
I am trying to find a way to work with non-standard terrain sizes... that is to say, I need to find a way to work with terrains that are much smaller than what is available "as-is" within the engine.
I have incorporated the non-repeating terrain resource, and so far everything seems to be working as intended.
Additionally, I resized the terrain using a square-size of 2 (which seems to be the lower limit). Unfortunately, this does not produce a terrain as small as what I need for this particular project.
As I understand it (please feel free to correct any misunderstandings I may have on this, after all, knowledge is power. ;) the terrain engine uses a 256 x 256 height map to generate terrain, though the terrain that gets generated is calculated out to 1024 x 1024 tiles.
The problem I'm currently trying to address is that I need to work with about 1/2 to possibly 1/4 of that (even at a square size of two =\ ).
Let me explain what I'm trying to accomplish for clarity.
The project in question requires a terrain display as a sort of 3D tactical view. Basically, it will be a relief map housed inside a modeled table.
This entire scene will then be placed inside a very large interior room, so there is no need for additional terrain outside of this structure.
The terrain needs to be small enough that, given the origin of the terrain, an orbital camera can be generated such that when it is moved around the terrain, the entire map is viewable from any given angle or point on the map.
Clear as mud?
My current thinking is that I'll need to actually reduce the number of terrain tiles generated as well as the square size to get the overall effect I'm looking for.
Just as a quick caveat, collision is a non-issue with regards to this particular project. (C;
Now, I'll admit that I've only begun to scratch the surface regarding the terrain engine and how this might be accomplished, but knowing that there are many here in the community who have a much stronger understanding of the terrain code, I'm hoping that someone here can help point me in the right direction(s).
Thanks in advance - any and all help and/ or advice is appreciated.
#2
Just making the terrain smaller probably isnt such a great idea, since it will still have a lot of polys, and they probably arent going to want to render too badly.
05/24/2005 (7:15 am)
If you don't need collision, why don't you just create a dts of what you want to display? Just making the terrain smaller probably isnt such a great idea, since it will still have a lot of polys, and they probably arent going to want to render too badly.
#3
www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=5277
Thats the GuiCommanderHUD which does basically what you are wanting to do already.
@William, The custom shape mod works only on .dts objects, it wouldn't be appropriate for terrain.
05/24/2005 (7:30 am)
Umm even simpler solution...www.garagegames.com/index.php?sec=mg&mod=resource&page=view&qid=5277
Thats the GuiCommanderHUD which does basically what you are wanting to do already.
@William, The custom shape mod works only on .dts objects, it wouldn't be appropriate for terrain.
#4
I appreciate the feedback so far, but perhaps further clarification is required.
1) I did indeed look over the GuiCommanderHUD resource previously, though I don't feel it suits the needs of this project.
For one, we are looking for a fully 3D interactive map, whereas IIRC the commander map is essentially an overhead (only) view of the mission area and the outlying terrain.
Secondly, it still suffers the overall size problem though I suppose it would be possible to instantiate a "view window" using the resource and place inside the table... but there are other problems inherent in that solution.
2) I hadn't really considered using a DTS shape to create the terrain, but it is an interesting prospect. I only foresee one (rather significant) problem... customization.
You see, our intention is to allow the user to create there own maps and scenarios. We had hoped to use the terrain editor provided in the engine to allow this from within the application itself.
Think of this as a sort of "3D Chess" game. Perhaps a better description would be 3D Battletech... ala the tabletop game rather than a fully animated video game. (Not really, but it's the best way I can currently describe it. =\ )
While we have no need for ongoing collision tests, there will be objects (models and DTS shapes alike) placed on the terrain - some during run-time- and moved via cursor as the game goes on.
The use of DTS shapes would require significantly more technical expertise on behalf of the user, as well as requiring the use of an external editor.
For obvious reasons, this would be undesirable.
I certainly don't mean to be negative, as the suggestions provided would definitely be easier to implement from a development standpoint, but we are forced to view this from the perspective of the end-user, which requires an "all-in-one, easy to use" solution. This means (as far as I can see) a more difficult development approach.
05/24/2005 (8:03 am)
Hmmm...I appreciate the feedback so far, but perhaps further clarification is required.
1) I did indeed look over the GuiCommanderHUD resource previously, though I don't feel it suits the needs of this project.
For one, we are looking for a fully 3D interactive map, whereas IIRC the commander map is essentially an overhead (only) view of the mission area and the outlying terrain.
Secondly, it still suffers the overall size problem though I suppose it would be possible to instantiate a "view window" using the resource and place inside the table... but there are other problems inherent in that solution.
2) I hadn't really considered using a DTS shape to create the terrain, but it is an interesting prospect. I only foresee one (rather significant) problem... customization.
You see, our intention is to allow the user to create there own maps and scenarios. We had hoped to use the terrain editor provided in the engine to allow this from within the application itself.
Think of this as a sort of "3D Chess" game. Perhaps a better description would be 3D Battletech... ala the tabletop game rather than a fully animated video game. (Not really, but it's the best way I can currently describe it. =\ )
While we have no need for ongoing collision tests, there will be objects (models and DTS shapes alike) placed on the terrain - some during run-time- and moved via cursor as the game goes on.
The use of DTS shapes would require significantly more technical expertise on behalf of the user, as well as requiring the use of an external editor.
For obvious reasons, this would be undesirable.
I certainly don't mean to be negative, as the suggestions provided would definitely be easier to implement from a development standpoint, but we are forced to view this from the perspective of the end-user, which requires an "all-in-one, easy to use" solution. This means (as far as I can see) a more difficult development approach.
#5
05/24/2005 (8:07 am)
Maybe we could help more if you told us exactly what features this thing is supposed to have? Sounded to me like you wanted a rotating 3D representation of the terrain.
#6
Basically, I'm hoping to use the terrain as a tactical "table" that the user can rotate the camera around.
That being said, I wish to limit the terrain accordingly to eliminate unwanted/ unused space. Unfortunately, I'm not enough of a Torque guru to know how to go about it.
[EDIT] P.S.
I meant to ask you earlier:
If I did manage to find a way to limit the number of terrain tiles used, why would it still have the same number of polygons?
I'm not sure I understand?
05/24/2005 (8:11 am)
Yes Chris, exactly.Basically, I'm hoping to use the terrain as a tactical "table" that the user can rotate the camera around.
That being said, I wish to limit the terrain accordingly to eliminate unwanted/ unused space. Unfortunately, I'm not enough of a Torque guru to know how to go about it.
[EDIT] P.S.
I meant to ask you earlier:
If I did manage to find a way to limit the number of terrain tiles used, why would it still have the same number of polygons?
I'm not sure I understand?
#7
What if I were to create a "default terrain" from which the user could create custom derivatives, and then simply delete the "unwanted" tiles from the terrain?
Any forseeable road blocks to a solution like that?
05/24/2005 (8:22 am)
I've just had a thought...What if I were to create a "default terrain" from which the user could create custom derivatives, and then simply delete the "unwanted" tiles from the terrain?
Any forseeable road blocks to a solution like that?
#8
Your best bet is to rewrite the terrain part of the code. Size it how you want it. Then allow the user to create a new terrain, edit it, and save it.
05/24/2005 (8:27 am)
Well, when you change the block size of the terrain, it just squishes or stretches it... THere are still the asme number of polys. Your best bet is to rewrite the terrain part of the code. Size it how you want it. Then allow the user to create a new terrain, edit it, and save it.
#9
The problem is, I have no idea how the engine arrives at 1024 (squared?) tiles in the first place! =\
Any thoughts on where to start looking?
I've gone through terrData.h, terrData.cc and terrRender.cc - at this point I'm thinking that it will be culmination of several functions rather than all in one place. =(
Nothing ever seems to be "easy" in Torque, but that's the price we pay for professional quality. (C;
05/24/2005 (8:34 am)
Yeah - that's what I was hoping to do - basically force the terrain to generate fewer tiles.The problem is, I have no idea how the engine arrives at 1024 (squared?) tiles in the first place! =\
Any thoughts on where to start looking?
I've gone through terrData.h, terrData.cc and terrRender.cc - at this point I'm thinking that it will be culmination of several functions rather than all in one place. =(
Nothing ever seems to be "easy" in Torque, but that's the price we pay for professional quality. (C;
#10
05/24/2005 (8:42 am)
Sorry - I dont have any code here. I can look into it whern I get home, if I remember.
#11
Even if you can just point me in the right direction, I'd be forever in your debt.
I appreciate your help so far - you're patience is greatly appreciated as well. (C:
05/24/2005 (8:55 am)
Hey, any help is appreciated.Even if you can just point me in the right direction, I'd be forever in your debt.
I appreciate your help so far - you're patience is greatly appreciated as well. (C:
#12
05/24/2005 (9:22 am)
I would just read thorugh the source. That is the best way to find what you are looking for. Look in the scenegraph folder as well. That is where the lighting is done. The lighting might give yo ua clue as to how static hte terrain tile size is.
#13
For ThinkTanks I did do basically what you want, but it isn't a pretty solution. What you have to do is change the block shift (not block size) on the terrain code to a different value (right now it is 8, meaning that there are 256 tterrain squares on a side). In ThinkTanks we used block shifts of 6 and 7 (the playfield was fully within the inner part, so low detail setting used a block shift of 6 while high detail setting used a block shift of 7 to get extra mountains in the distance).
I'll send you the terrain files from ThinkTanks, but the easiest thing to do is probably to just scale everything else up. I promise you that if you try to integrate the changes I'm sending you , you'll be pulling your hair out trying to get it to work (and I cant' take the time to support the files).
05/24/2005 (9:30 am)
@Kirby, can you simply scale everything else in the world up 2-4 times? You seem willing to have a lot of polys in the scene, so that might be the easiest thing. You'd also have to scale the visible distance and fog distances, but that should be easy enough to do.For ThinkTanks I did do basically what you want, but it isn't a pretty solution. What you have to do is change the block shift (not block size) on the terrain code to a different value (right now it is 8, meaning that there are 256 tterrain squares on a side). In ThinkTanks we used block shifts of 6 and 7 (the playfield was fully within the inner part, so low detail setting used a block shift of 6 while high detail setting used a block shift of 7 to get extra mountains in the distance).
I'll send you the terrain files from ThinkTanks, but the easiest thing to do is probably to just scale everything else up. I promise you that if you try to integrate the changes I'm sending you , you'll be pulling your hair out trying to get it to work (and I cant' take the time to support the files).
#14
05/24/2005 (9:31 am)
@Kirby - Doh! But you'll have to send me an email first since your email isn't listed.
#15
Email sent. (C:
The only forseeable problem with scaling everything else up is the veiwable range.
I realize that I can push the fog back, but at a certain distance, what you can see would be relatively meaningless in the context of usability - not sure if that is very clear. =\
I am definitely willing to give it the old "college try" though. And thank you for your willingness to help - I'm sure those resources would be invaluable even from a purely informational standpoint.
05/24/2005 (10:10 am)
Thanks Clark - Email sent. (C:
The only forseeable problem with scaling everything else up is the veiwable range.
I realize that I can push the fog back, but at a certain distance, what you can see would be relatively meaningless in the context of usability - not sure if that is very clear. =\
I am definitely willing to give it the old "college try" though. And thank you for your willingness to help - I'm sure those resources would be invaluable even from a purely informational standpoint.
#16
I have been searching for threads with the "blockshift" variable listed and wow - there is certainly a lot of information to be had - now that I know what I'm looking for. (C;
Strangely enough, most of it is in the engine forum though. Heh.
05/24/2005 (10:25 am)
@ Clark -I have been searching for threads with the "blockshift" variable listed and wow - there is certainly a lot of information to be had - now that I know what I'm looking for. (C;
Strangely enough, most of it is in the engine forum though. Heh.
Associate William Lee Sims
Machine Code Games