Terrain Research Infodump

[thegoodperry]

I dont suggest you use auto smoothing. if you make some sort of mini modter for use with the minimap, you should let the map maker decide how they want the terrain to form. the minimap is basically an abstraction of the larger map, so if the person wants to modify details, you should just let them design generally on the minimap and then move over to the larger map and edit individual parts.

let minimap be the small model of the large map that you can edit
let megamap be the large, final product terrain map they are designing for

Example: maybe they want a 90 degree cliff with a tiny cave in the center. Let them design the cliff using like 1x1 plates or the mini modter equivalent and then let them move over to the megamap and cut the hole out of the mountain face for the cave, something that they can only do at the lower levels of abstraction. if anything doesn't fit, like for example maybe the cliff is 73 bricks high and the minimap to megamap is 1x1 to 64x64, maybe let them change the ratio to 4x4 to 64x64 so they can add smaller details, or just let them design the cliff at 64 bricks high and then they can manually elevate the cliff on the megamap

Auto map smoothing is definitely helpful but its unnecessary and it will save you a lot of time if you design the necessary features first, ie the minimap to megamap scaling, and sort out any issues, and then implement auto smoothing at a later iteration

[Ad Bot]

[Tendon]

Part of the current behavior is that leaving an empty spot on the minimap would leave an empty spot on the megamap. (nice word by the way)
I had planned for this to be used for cases where someone wants to build a custom piece of terrain such as a cave.

[Potatoh]

can we use .png files to get predetermined terrain generation

[thegoodperry]

Part of the current behavior is that leaving an empty spot on the minimap would leave an empty spot on the megamap. (nice word by the way)
I had planned for this to be used for cases where someone wants to build a custom piece of terrain such as a cave.

Even better reason not to use any kind of automation on the map.

If i left a spot blank on the minimap on a smoothed megamap it would look like a crater in the ground rather than just a missing chunk (preferrably you want it to look like a missing chunk or something so you can manually design that part of the map)

[Tendon]

can we use .png files to get predetermined terrain generation

That's the plan.  Sort of.  I don't have a way of decoding *.png files natively with Blockland.
But I have a tool for paint.net that can convert any image into an ascii *.ppm, which Blockland can then read like a text file.

If i left a spot blank on the minimap on a smoothed megamap it would look like a crater in the ground rather than just a missing chunk (preferrably you want it to look like a missing chunk or something so you can manually design that part of the map)

It looks like a missing chunk.  This method of smoothing is not influenced by cells that are lower than the current cell.

The code is messy, but the terrain now smooths itself.

[Smallguy]

One issue to note when trying to make static shape terrain maps:
players can easily fall through the map and vehicle collision will pretty much not work at all. Some research should be done into how static map collision could be improved either through overlapping collision planes at borders or adding depth to the planes. (not sure either of these would work, just a wild guess, i'm sure there are other methods to consider)

[--LegoPepper--]

One issue to note when trying to make static shape terrain maps:
players can easily fall through the map and vehicle collision will pretty much not work at all. Some research should be done into how static map collision could be improved either through overlapping collision planes at borders or adding depth to the planes. (not sure either of these would work, just a wild guess, i'm sure there are other methods to consider)

I got vehicle collision to work fine on my static map. The problem is the size of the static map can't be too big otherwise you'll get like 2fps.

But- maybe that's due to the large collision shapes?

What handles better, a lot of small collision shapes, or a small amount of large collision shapes?

[Tendon]

*sigh* Alright I guess I didn't publish that info very well.

Finished Research
Static shapes must be convex, or collision will be glitchy and not work for vehicles, projectiles, raycasts, etc.
      Player objects might work ok.  But that's it.
Static shapes must be scaled down by 0.5, or there is some probablility that vehicles or small/fast objects can glitch through them.
       Because the static-shapes must be scaled down, they must NOT have a visible mesh attached to them.  (The visibile portion will pop-in/pop-out when a camera turns it's view away.)
You must not force a client to keep track of a large number of static shapes.
       For my computer, the limit is about 2000 before performance drops noticeably.

Judging by my frame counter, TSStatic uses about half as many resources as Static Shapes, and it interacts better with the camera, blocking the camera from moving through it.
For visual aspects, Static Shapes can do some fancy visual tricks, such as turning transparent while shaders are on, or playing animations.

For best performance in making a StaticShape map, I would keep the number of collision shapes down below 2000, and I would use as few staticshapes for the visual aspect of the map.  Maybe just 1 or 2.

Current Research Project
The current project I'm doing involves making a terrain generating tool using modTer bricks.

But I plan to expand upon this project.  Instead of using modTer:
I will use unattached TSStatic for collision, so that I can get perfect collision.  I will use selective ghosting to force clients not to ghost TSStatic that is too far away from any moving objects to matter.
I will use hackneyed bricks w/no collision to display the terrain's shape.  So far as I can tell, bricks are much more efficient visually, than static-shapes.
Cool thing
A cool thing I did yesterday.  I needed to plant two modTer bricks in the same place.  Normally this causes one of the modTer to fail to plant, and thus not have collision.
To avoid that, I modified the planting function I'm using to convert the brick to a 2x2hNULL brick just before planting, and then convert it back to modTer after planting.
A 2x2hNull brick is just a 2x2 half brick with no brick grid collision.  It will never throw an overlap error when planted, but will always throw a float error.  I can ignore the float error.

I originally use this method to make a "Plant Anywhere" script.  While it did work, allowing me to plant bricks anywhere, this script introduced a few problems.  Problems such as accidentally planting extra bricks inside of each other, or forcing me to disable chain-kills so that killing a brick didn't destroy the entire building.

[thegoodperry]

remind me how static shapes fit into this? i thought this was being worked on exclusively with modter

[Redo]

Who says you can't make huge terrain out of bricks?
(Actual size, 102730 bricks, loads in 30 seconds using GhostAllBricks with no lag)

[Redo]

I suspect the issue with bricks causing client lag has to do with face hiding: Whenever a brick is placed adjacent to another brick, the game checks whether one brick completely obscures a face of the other brick, and if so, stops rendering the obscured face.
My terrain, as a result of trying to be brick efficient and not placing any bricks that can't be seen, hides relatively few faces, which may contribute to it not lagging while ghosting.

[--LegoPepper--]

I suspect the issue with bricks causing client lag has to do with face hiding: Whenever a brick is placed adjacent to another brick, the game checks whether one brick completely obscures a face of the other brick, and if so, stops rendering the obscured face.
My terrain, as a result of trying to be brick efficient and not placing any bricks that can't be seen, hides relatively few faces, which may contribute to it not lagging while ghosting.

Are you gonna release this?

[Redo]

Are you gonna release this?

No, but here's the save.
slopes.bls

[--LegoPepper--]

No, but here's the save.
slopes.bls

lol why not???

[Tendon]

I suspect the issue with bricks causing client lag has to do with face hiding: Whenever a brick is placed adjacent to another brick, the game checks whether one brick completely obscures a face of the other brick, and if so, stops rendering the obscured face.
My terrain, as a result of trying to be brick efficient and not placing any bricks that can't be seen, hides relatively few faces, which may contribute to it not lagging while ghosting.
-snip-

I believe that check may be the cause of lag as well.  I don't believe the act of hiding the face would cause any lag at all, but the act of checking a 64x160 cell face against another 64x160 cell face over many iterations, would.

Have you had problems w/chainkills destroying a piece of terrain, or do you have some method that allows people to build and delete on them without issues?