Changing Terrain size?

#1 Sphere's wouldn't be possible at this point with the engine. To have a true sphere you need to manage uneven tiles, (ie. create a sphere in Max and see how the poly's change shape depending on lat.), and you would also have to change gravity to be a fixed point in the center of the spere or you would fall off when you got a certain point on the sphere with the current engine = )

You could trick the user by displaying tiles in a certain order and calling it a sphere, but in reality the tiles wouldn't reall map out to a sphere.

Just some random thoughts.
,Aaron

#2 What about creating a large square world with one spare tile around the circumference for "visual continuity" only, and when the player reaches a specific coordinate you simply "beam" them to the appropriate opposite side so that they appear to be walking back into the same area.
Perhaps a bit difficult to implement, but it would do what you like.

David

#3 no I mean it to emulate a spherical world but it would still be straight. the same tile would just repeat itself with the objects in sync with how they are on the original tile, making the user think it's sphereical.

alos the main piont of this post is about how i would go about increasing tile size a lot!

#4 The code for the terrain tile size is in the Terr* source files (as noted elsewhere in the forums).

If you are planning on creating a special terrain data file that simply repeats itself [say] 10 times for a 10 square world, your resultant file won't load into anything anyone is running for a PC these days. You would be instancing all of the object repeatedly in every direction, PLUS every player would have to be instanced in all tiles of the same area.
I would think it would be easier just to wrap around by moving the player to the opposite end of the map when you hit a specific location on the edge tiles, much like the old tile-based games did.

P=Player walking ->

____TT____TT__P_TT____TT____TT____ = lots of ram


____TT__P_
^
beam me (player=P) back to here when I get to the edge would be easier.

David

#5 OK let me clarify. these are 2 DIFFERENT QUESITONS.

1)Emulating spherical means like what you said by transporting them back but i want it to be smooth! V12 automatically Repeats tiles anyway so the first method you said wouldn't take up much more RAM.

2)I NEED TO KNOW THE CODING WHERE IT HAS THE TERRAIN TILE SIZE LIMITS AND/OR HOW HARD IT WOULD BE!!!! That's my main point of this message but noone seems to be answering it!

#6 Hi Matt,

1. It should be smooth so long as you perform the player coordinate update in less than one frame time. It should be some simple math to pull it off if you place a "virtual" rectangle around the map area -- you hit the edge x or y coordinate, and move the player to the proper coordinate on the other edge.
The V12 automatically repeats just the tiles of the terrain, it does not repeat the location of the objects (buildings, players, etc.) within each tile -- that is what would require a lot of processing power and ram -> instancing all of those items on each repeated area. Fire up T2 and hop into the Shrike and fly in one direction, the terrain repeats, the objects do not (at least I've never seen them do so).

2. Go to the V12\Engine\Terrain folder, it's in the terr*.cc code. I've not looked at any of these files yet... but for example, terrData.cc at line 51 is: "squareSize = 8;", this is probably the place to start.
You will probably find all of the code you need to modify in the terr*.cc files, however, you will probably have some major coding to get it all working. I believe they are using QuadTrees (created on each frame?) plus other coding techniques, which may have to be mod'ed depending on what you are changing, not for the feint of heart. [Tim would know more on this subject].

David

#7 1) Yeah i might do that.

2) well i changed the squaresize to 20 but it didn't look any difference, at least with the v12 test levels. any ideas? maybe i have to start from a blank....?

#8 Okay i'm guessing it has something to do with the this function:

Quote:
TerrainBlock::TerrainBlock()
{
squareSize = 8;

mBlender = NULL;
lightMap = 0;

for(S32 i = BlockShift; i >= 0; i--)
gridMap[i] = NULL;

heightMap = NULL;
materialMap = NULL;
mBaseMaterialMap = NULL;
mMaterialFileName = NULL;
mTypeMask = TerrainObjectType | StaticObjectType | StaticRenderedObjectType;
mNetFlags.set(Ghostable | ScopeAlways);
mCollideEmpty = false;
mDetailTextureName = NULL;
mCRC = 0;
flagMap = 0;
mVertexBuffer = -1;
}

I tried changing the squaresize to 20 but it didn't seem to do anything. any ideas or is this function wyayy off?

#9 That's a template.

The terrain specification in the .mis file tells what block size to use.

#10 oh ok how do i open the .mis?

#11 *smacks himself*
lol it's right there in the .mis file
area = "-360 -648 720 1296";
lol that's it right?

*update
hmm no that's for the mission area...

#12 Okay i got it. you edit the Squaresize = 8; in the .mis but the only problem is it spreads the terrain out so... lets just say in the test level i was only supported by a floating building with floating water hehe. any ideas how to fix that?

#13 Anyone mind if I reopen this thread?

I have also been playing with larger terrains as (256x256) is not suitable for our needs. I have toyed with the squaresize in the mission file and found that it just stretches the map which you'd expect.

I have been pulling in GIS data for more realistic maps and and these invariably are large chucks of data, and fairly detailed too.

I'm assuming I'd have to do some nitty gritty tweaking to get the larger maps (1024x1024+)in to the v12. I'm not interested in maintaining the ability to loop back to my starting position.

Anyone got any ideas where I should start my search through the code?

Thanks heaps

-Jason

#14 re-open away :)

Not sure how I missed this one.

Must go play with this.

#15 Well I can think off one more problem with this "teleport" to the opposite edge when you exits the mission area. And it goes like this:

Lets say you walk towards the top edge and when you cross it you will get dumped at the bottom edge still facing north. No probs so far, but.....

What if you pass a building or a tree or whatever 20 meters before you reach the top edge.
You then cross it and are dumped at the bottom edge and you walk 20 meter into the mission area from the south.

Now here's a problem:

If you turn around 180 degree and look out over the sought border you cannot see the buildong you just passed 40 meters back, cos its still at the top of the mission area.
This will also happen if 2 or more players are walking in a line with maybe 10 meters between them.
When the first reaches the border he will disappear in front of the second player walking behind him.

Just though I might as well add this to your other problems :)

// Clocks out.

#16 I'm re-opening this too.

Has anyone done it yet? I tried but failed miserably. I tried to double it to 512, but it crashed way too much.

It would be really cool if someone figured this out. It would be even cooler if it was semi-dynamic. You could put a terrain size variable at the top of terrData.cc to make it easier to tweak. Then everyone's needs would be met.

I'm going to keep trying this...

I don't think I understand it enough to do it though.


Dark

#17 I have two comments about this.
ONE why would you be teleporting within the same map why don't you have two servers working on one map(northpole & south pole)
if you hit the end of the map you will be transfered to the next server. Ulitma Online does this in order to have it's expansive worlds.
TWO If you have two servers you can also have a DMZ aound your equator. that will provide you with overlaps on your maps.
IF I was doing this I would improve the ability for two servers to run off of one dataset. So they could share the processing of the world.

+{__"P___}+ (north pole)
p = player
" = buliding
{ } = playarea
+ = overlap
' = plane
+{____'_}+ (south pole)

the main proble is player lag in the shared area.

PLEASE COMMENT

#18 What if we were to make the engine randomly create the terrain after the mission boundaries. or have it mixed up so that it doesn't repeat, then make the mission area larger?