Let's Design a Terrain Sculpting Tool

[Rally]

I'm imagining it would be a laser (like port's new brick tool) that just kinda spams small mod-ter bricks wherever you're pointing, organizing them into a grid, and then filtering them down into the biggest possible bricks as bricks are being planted. That's how I'd design it if I were doing it at-least

Carving would be a little more complicated. Maybe the supercut feature from the new duplicator could provide some insight

[Ad Bot]

[Platypi]

I'm imagining it would be a laser (like port's new brick tool) that just kinda spams small mod-ter bricks wherever you're pointing, organizing them into a grid, and then filtering them down into the biggest possible bricks as bricks are being planted. That's how I'd design it if I were doing it at-least

Carving would be a little more complicated. Maybe the supercut feature from the new duplicator could provide some insight

Oh definitely. I remember talking with Draganoid Slayer about a problem he was having with a map he was helping develop. They were trying to figure out a way to merge bricks together to save on brickcount. They seemed to conclude that they, unfortunately, would have to size-down their map to make it playable.

Another thing we should consider is how we would handle texturing/coloring. I'm not sure how simple it would be to simply have a tool mode that colors cubes within a selected circle or sphere. If a larger brick is differentially colored (e.g. the top is selected to be recolored, but not the bottom) we would simply cut it up into different and appropriately colored cubes. If we're already writing code to combine bricks together and split them apart, this would be rather easy to implement I'd think.

I would also propose we have a mode for editing heightmaps and a mode for editing terrain at different angles. The heightmap mode would simply move terrain up and down, like most terrain editors. The other mode would allow you to extend and retract bricks in any direction. This would allow for the creation of caves, overhangs, and of the sort. The reason I would propose splitting these into two different modes is that most map makers are probably quite used to the standard heightmap method of editing terrain, and the ability to extend and retract terrain in directions other than just up and down could map this style of map editing more difficult, if not near impossible.

Finally, my other concern is latency issues. We've all seen how long it can take to duplicate something. It might be difficult to fluidly edit terrain when it takes so long for bricks to plant. Our tool will probably need to be designed with this consideration in mind. It probably won't function quite like most terrain editing tools in software where high latency is taken for granted. A synthesis of procedural generation and manual sculpting for fine tuning will probably end up being the most efficient. I'm not sure if everyone would be happy with that style of development, though. Overall, we'll probably have to do a lot of experimentation before landing on something fluid and usable.

[PhantOS]

Brush based sculpting via Raycast is perfectly reasonable as long as the brush size is limited. Ideally, rather than stacking bricks on top of each other, it would just delete the brick one height lower and create a new one on top, so it would resemble a plane rather than a solid terrain.

[Shift Kitty]

You'd want to keep enough bricks under so that no holes are made on the surface.

[HellHound]

what ever happened to that old terrain generator made by NiXiLL?

[Platypi]

Brush based sculpting via Raycast is perfectly reasonable as long as the brush size is limited. Ideally, rather than stacking bricks on top of each other, it would just delete the brick one height lower and create a new one on top, so it would resemble a plane rather than a solid terrain.

Yeah that should be doable. However, if we design the tool for more than just basic heightmapping, I could see some issues with this design. Perhaps I'll draw up some graphics (maybe tomorrow) to demonstrate my concern.

You'd want to keep enough bricks under so that no holes are made on the surface.

This wouldn't be necessary. You'd just add bricks underneath the surrounding bricks as bricks are shifted downwards.

Or do you mean that some measure needs to be taken to prevent users from shifting bricks below the base terrain? We could just prevent users from shifting bricks that far down, or just delete them past that point. Preventing them would probably be better, though, as there would be no way to shift bricks up again if they were moved past the base terrain's top. Ultimately, it would be up to the users to start their terrain higher up.

[Platypi]

what ever happened to that old terrain generator made by NiXiLL?

Here is what he's referring to, in case anyone is intrigued. I actually hadn't heard of this before. It's simplicity is quite charming.

[Platypi]

Just had a thought. Terrain editing could be a bit difficult with jets. Perhaps this should be done in an admin-orb.

However, there may be cases where a host wants non-admins to be able to edit terrain (e.g. a server for making terrain; a "terrain freebuild"). So I'm thinking the tool should put the player into a free-camera mode and allow them to operate from there. This would be great, too, since we could map something to the jet key, and we can still change paint colors while flying. This would also justify potentially including some sort of GUI alongside the terrain editor. Perhaps this shouldn't even be a tool, but a command that launches you into terrain editing mode. I like this, too, since it'd be a lot more like MissionEditor.

The terrain tool should also disallow players from editing terrain of players they don't trust. The amount of trust needed to edit the terrain of another player (full, build, or none) would be adjustable in the server preferences. I would also say that when you have permission to edit someone's terrain, and your terrain is right next to their's, they will be edited as one, continuous terrain. Also, when someone else's terrain is edited by another player, the created bricks will still be owned by the original player, not the editor.

And of course, we should have a preference that allows the host/admins to change whether or not non-admins, non-super-admins, and non-hosts can use the terrain tool.


On another note, I should start making a feature list.

[Platypi]

I sketched up a few proof-of-concept draws in Google Sheets. I suggest anyone who wants to propose a design feature try to illustrate their idea similarly. Excel/Google Sheets should be a lot easier to use draw squares on a grid in than Photoshop or Gimp.

The green represents the player's selection. You might want to zoom out for this (Ctrl-Scroll). I'll scale-down my images next time.

Extending Terrain


Extending Terrain Higher


Indenting Terrain


Raising and Splitting Terrain


Indenting and Splitting a Wall


Combining Multiple Times


Extending at an Angle


Indenting at an Angle


Please critique and suggest changes to this model. It is a first-draft, and I can already see some flaws (which I intend to detail and correct later when I have the time).

[Platypi]

I added a feature list to the original post. Tell me what you think about the ideas I've accumulated.

[Platypi]

Whostolemahcar suggested we have a tool that can add and take away spheres. I'll add it to the feature list.

He also suggested a mode that allows a player to specify a sediment coloring scheme, and apply that to terrain.

[portify]

Main challenge honestly would be doing the client-side calculations to translate mouse position values into positions on the brick grid.

use this

https://github.com/portify/projection