Terrain Research Infodump

[Tendon]

Hey there,  I've been looking into adding in some sort of terrain mod to Blockland.

Goal:
I want to be able to create large areas of terrain, with good collision, and no lag.  I want it to work on somewhat slower machines.

Bricks
Using bricks would be ideal.  It did not occur to me to try them at first, bust when I did... They don't lag while just on the screen.  But while flying over a piece of unloaded terrain, the client will receive a huge lag spike for each new section of terrain they encounter.  This is unacceptable.

This is an example piece of terrain, 4096x4096 studs of ModTer 64x bricks.
This terrain should not lag to load.  But It does.  I believe it is has something to do with the bricks being next to each other.  I have experienced this sort of lag before while trying to load a 3D maze I generated via script.  When the maze units are loaded while next to each other, there is a large lag spike.  But when I modify the script to place the maze units just one unit away from each other, they load almost instantly with no lag.

For bricks...  I believe it would be possible to still use them.  If I create a selection of modTer bricks that are 62x62x62, with a 62x62x62 collision box, but still retain the visual aspect of a 64x64x64 modTer cube.  The bricks should ghost without lag.  However, there would be... some work to make the 62x bricks act like 64x bricks.
It would require the use of a floating bricks mod to plant the bricks the proper distance apart.  It would require a StaticShape collision object to handle the gaps between bricks.  And then it would require a custom ghosting mod to prevent clients with lower end PCs from trying to track the large number of staticShapes in the scene.
Even after all of that, there would be some trouble using a separate staticShape as a collision object.  Events such as getting hit with a wrench or a PrintGun would have to be passed on to the brick.  This can be done for default items, but for custom Add-Ons, I have no guarantees.

Summary: lots of work, lots of dependency, requires DLL(for ghosting), possibly glitchy, and possible conflicts with other add-ons.  However, perfect collision, low lag, scale-able, and modifiable on the fly by anyone ingame.

Static-Shapes
StaticShapes lag when displayed in large numbers.  However, a single, large, and really complicated visual static-shape, and a thousand or so TSStatic shapes for collision, does not seem to lag the client at all.
16k collision shapes, and 4 visual shapes.... this DOES lag the client.
With the SelectiveGhosting DLL and some sort of custom ghosting mod, it is possible to load and unload sections of terrain at a time, on the fly, without adversely affecting the client.

It's possible to use static-Shapes, but.  This sort of terrain would not be easy to modify on the fly.  If the visual aspects of the terrain were modifiable in chunks, like bricks... sure.  But for the performance I'm looking for I believe it is prudent to abandon the concept of modifying StaticShape terrain in an impulsive and arbitrary way in the middle of a game.

Summary: lots of work, Requires DLL(for ghosting).  However, perfect collision, low lag, scaleable.


I am still... dubious over the use of bricks.  I have not done extended testing with that "seperate by one" thing.  It was a behaviour noticed in passing.  However, if possible, bricks would be the way to go, simply because they could be modified midgame.  If a host wants to add a cave to a hill- he can.  Whereas with pure StaticShapes, this would be impossible.

The only thing I'm bummed about is that both of these systems would require a custom DLL to run.  These custom DLLs require a special EXE that does not update with the base game.  I'm still on r1986, but Blockland itself has updated to r1988.

If clearScopetoClient() worked, I would not need a DLL at all.

[Ad Bot]

[Conan]

if you just ensure the bricks are ghosted to the client on load, there wont be any ghosting lag/freezing. most of that seems to be the fact the terrain is modter more than anything; it seems like the same as the lag that happrns clearing or loading a lot of big modter at once.

as for static shapes: iirc smallguy tried it: one REALLY MASSIVE shape with complex collision geometry seems to lag far far more than multiple smaller ones. note that the shape he was trying to get in was like a mountain and its slope down to some plains, so yeah. it seems that scaling up a smaller static shape still results in similar problems

neither of what ive mentioned requires dlls, and i suspect you really dont need them. what do you really need them for? ghosting happens without dll, theres server mods to allow clients to force ghost/reghost everything on the server, without the server or client needing a dll.

[Tendon]

I tested. http://leopard.hosting/dl/gpnci/BrickGhostingTest.zip
It appears brick loading, clearing, and ghosting of large bricks takes much longer if the bricks are next to each other.  Regardless of brick complexity.

one REALLY MASSIVE shape with complex collision geometry

Hahahaahahahahahahahahahahaha, yeah.  I tried that with BloodGulch from HALO:CE.  Same issue.  That was a long time ago though...

But yeah, that's why I need the SelectiveGhosting DLL to do anything.  To get accurate collision for a large complex piece of geometry, lots of concave collision shapes are needed.
But lots of concave collision shapes will lag the client.  The server handles these objects just fine.  But the clients... even if the objects have nothing to render, if the client knows that the object exists, it will impact the framerate.
But with SelectiveGhosting, I can limit the number of collision shapes the client is "rendering".

theres server mods to allow clients to force ghost/reghost everything on the server, without the server or client needing a dll.

I need to unghost these objects.  I do not currently know of any way to do that in a default copy of Blockland without reghosting everything else at the same time.

[thegoodperry]

i dont think large terrain is feasible on blockland. there are never any real cases where you need a massive map anyways, its not like its humanly possible to populate a giant map with interesting events and details with just a staff of one person.

if your map is giant but barren and includes no details, that's a sign you can definitely cut down on the size of the map. otherwise you're left with a giant uninteresting blob of colors that takes an hour to cross. even if your game is heavily vehicle-dependent, you can easily just cut down the speed of all vehicles

[datiel12]

i dont think large terrain is feasible on blockland. there are never any real cases where you need a massive map anyways, its not like its humanly possible to populate a giant map with interesting events and details with just a staff of one person.

if your map is giant but barren and includes no details, that's a sign you can definitely cut down on the size of the map. otherwise you're left with a giant uninteresting blob of colors that takes an hour to cross. even if your game is heavily vehicle-dependent, you can easily just cut down the speed of all vehicles

is 'that right 'eh?

[thegoodperry]

is 'that right 'eh?

yes. if you ever played wind waker for gamecube you'll see a prime case of where the 'open world' is way too loving big and you end up spending 5-10 minutes periodically doing nothing and seeing nothing as you travel from place to place

if your game, whether it be a AAA grand theft auto or some small project you're working on in blockland, has periods of time where you travel for more than one minute without encountering some interesting landmark or detail, its too big.

[Gytyyhgfffff]

is 'that right 'eh?

yes by far one of the worst and most common blockland server tropes is having a map that is way too big with forget all to do in it

Even after all of that, there would be some trouble using a separate staticShape as a collision object.  Events such as getting hit with a wrench or a PrintGun would have to be passed on to the brick.  This can be done for default items, but for custom Add-Ons, I have no guarantees.

just use the "CollisionShapeName" field on brick datablocks, this does what you're suggesting already

[datiel12]

yes by far one of the worst and most common blockland server tropes is having a map that is way too big with forget all to do in it

damn

[thegoodperry]

A lot of people misunderstand the good parts of games like grand theft auto and fallout and skyrim, which is the large, open world. They think that the reason why its fun is because you have a huge world to explore. In actuality, they're fun because you have a huge world to interact with.

Feel free to make a huge continent-sized map in blockland but it'll totally suck unless you populate every 200x200 square with some meaningful interaction, whether it be an interesting enemy or an interesting character, or maybe an interesting landmark. It sounds easy but it's absolutely unsustainable, open world games have about 50-100 staff members who handle populating their open world and even then it takes them like 2 years to complete

[Tendon]

just use the "CollisionShapeName" field on brick datablocks, this does what you're suggesting already

ModTer uses that.  That sort of collision works ok, but has... ehm...  To make the collision shape work correctly with vehicles, I must rescale the shape by "0.5 0.5 0.5".  I know of no way to do this when the shape is instantiated using the CollisionShapeName field.

i dont think large terrain is feasible on blockland. there are never any real cases where you need a massive map anyways, its not like its humanly possible to populate a giant map with interesting events and details with just a staff of one person.

if your map is giant but barren and includes no details, that's a sign you can definitely cut down on the size of the map. otherwise you're left with a giant uninteresting blob of colors that takes an hour to cross. even if your game is heavily vehicle-dependent, you can easily just cut down the speed of all vehicles

Mm, yeah.  A giant map just isn't very interesting by itself.
The point of a map in Blockland is to give a user a starting point.  Eh- to make them think- "I could put somesuch thing there."

Oh... I've an idea.  A feature complete map leaves no room for a client's imagination.  But an empty map is... empty and uninspiring.  So- some map elements should be removable.  Such as, like, a hill completely covered in trees.  It would be nice if an average user could just clear some of the trees and start building.
It sucks to have to ask an admin for everything, so that's why I would allow average users to delete map decorations.
But some users are complete and utter richards who would clear-cut an entire forest just for the lols.  That sort of stuff will happen, there's no helping that.  But It can be made easy to fix.  I could, say, make the trees and decorations part of a separate save file, and then the server could reload those in chunks.
If a bad client clears the forest, an admin could run a command to regrow the forest, and reload the default decorations on all chunks that have no bricks in them.
If the bad client plants little 1x1's all over the forest to prevent regrowing, it's a simple matter of clearing that client's bricks.

One sticky thing though, is... what if a client is using some of the trees as an element of his build? ... One could make it possible to claim the trees as thine own.  Or expect the client to replant the trees. ... It would be nice if it were automated.  But I don't know how to do that without adding overhead to all brick planting/loading.
Oh~  better.  Do a check when removing the decorative trees.  If the tree has a brick very close to it, do a trust check between the destroyer and the owner of the nearby brick.

Ehm, to summarize.  My additional idea is to add some map decorations in a way where they can be removed to make space for a building, and then reloaded later on if the building doesn't work out.

[Tendon]

I've turned a simple heightmap:



into 2x2's



using a script



Currently the script can load a portable pixel map(ANSI) and put it into an array.
Some post processing can be done to the array, and then the array can be written as a blockland save file.
The save file is then loaded, creating the bricks in the server.

I want to load the save file as a set of special 1x1s which represent the terrain.  When the 1x1s are planted or changed, the change will also be represented in a much larger version of the terrain.  This larger version will be made up of completely collisionless modTer bricks, and some collision staticShapes.

The 1x1s will load quickly, and will allow the terrain to be modified midgame.
The collisionless modTer bricks will load quickly, as they will essentially just be floating 2x2 half bricks (with a really big box around them).
The staticShapes shouldn't lag, as long as the server host is using selective ghosting.
   If the server host is not running selective ghosting, the collisionless modTer and staticShapes could be replaced by regular modTer.

[portify]

-snip-

[Tendon]

I can edit the minimap, and the changes are reflected in the large map.
The minimap pieces can be planted in midair.

[thegoodperry]

thats actually a pretty handy feature. you should make like mini modter and be able to plant that on the minimap and have it translate to larger bricks

[Tendon]

I've been working on terrain smoothing a little bit.  Not finished yet, but I've come up with a rule-set.  Maybe you can think of a situation where it would forget up and look weird.

First take the following case:
123
405
678

The four sides(N,S,E,W) will always result in at least a ramp.  So will two corners.  (NW & NE will reseult in a ramp up North)
Because of this, we can simplify the problem by replacing all sides with two corners.  Keeping the highest values we can obtain.
So after modifications we get:
405
000
708

From here we calculate the number of distict layers we have. (4)
We go through each layer, from the lowest to the highest, and calculate what to fill the space with.
We can place multiple bricks in the same space.

The rules for placement are:
101
000
101
=Cube Fill
101
000
100
=FillCorner
101
000
000
=Ramp
100
000
000
=CutCorner
100
000
001
=Two CutCorners

Now, starting with the first layer, which has a height of 4.

404
000
404

This turns into a cube running from height 0 to height 4.
Since it is a cube, it changes the base height of our calculation. To 4.

Now we do the next layer.

005
040
505

This turns into a fillcorner up SE from height 4 to height 5.
The depth of this brick is 1, so the result can be accepted.
If the depth is not 1,2,3,4, or 8, and the brick is not a cube we just skip the brick.
Also, because this brick is a fillcorner, and we can place a cutcorner over the raised corner, we can record the fillcorner data as such:
000
000
005

Next layer:

000
040
707

This results in a ramp up S from height 4 to height 7, depth of 3 accepted.

Next layer:

000
040
008

This results in a cutcorner up SE.  Since it is a cutcorner, we check the fillcorner data
000
000
005
The fillcorner data has an entry matching our corner, so we can use it and make the cutcorner up from height 5 to height 8, with a depth of (3)

With that our calculation is done.

So far as I can imagine it, following these rules... most things will look good.  But most cases where the height changes from 0 to 6, 7, or >8, will result in a cliff.  This is due to a limitation in bricks used.
If I locked cell size to a predtermined value such as 16, and removed modTer, I could make my own brickpack, similar to modTer, with more height options.  It would be... 17 datablocks per level(4 bricks, 1+(3*4) StaticShapes).
ModTer does like: 11*5*4 datablocks (220) (just a guess)
If I delivered a similar impact, I could do: 12 levels.
...
So If I were to cut out some of those weird corners, and all inverted modTer, and only use 1 cell size, I could have a terrain brickpack which has an impact smaller than modTer.  And then it would also have additional levels of 1&1/4, 1&1/2, and 1&3/4.
...
Probably not worth it.
Though... my current plan involves a custom brickpack which uses 85 datablocks.  This will be in addition to modTer.
I already have to make two versions of my script, one for a server with selectiveghosting, and one for a server without.
The one without, would not even load this custom brickpack, or the static shapes.  So ...  I could increase the brickpack datablock count to 132, and include heights 5, 6, & 7.  In this way it would be a simple rule:  Any terrain height changes higher than 8, will result in a tall cliff face.

So ehm, in summary:
Smoothing terrain is taking some time.
I could make the custom brickpack include heights for 5, 6, & 7.  To simplify the rules the builder has to follow.
I could allow a client to set a smoothing height limit, so any cliff face with X depth will not receive any smoothing from ramps.