Terrains - best practice ?

[acocq]

What - in your opinion - is the "best practice" when working with terrains to create "large" worlds (since we don't have any "terrain stitching":

1. adding a single terrain object and "stretching it" to gain more "real estate" to manimpulate ?

or

2. adding several terrain objects and manually aligning the terrain edges ?

In addition, the question how large a terrain is really sensible ?  What if I decided to create an area that is several square kilometers in size (to, let's say, build a sizable city ... maybe a few hundred buildings, all in all) ?

Cheers,
Andreas

[zknack]

Sensible is really a matter of personal taste Andreas

My current build's worldmap has 32 terrain tiles, at max size and
max divisions working smoothly. I do strongly use LOD in my maps,
including for terrain though.

On top of the terrain are (depending on location) 4-8 command blocks
that pass on weather or condition information to affect speed (and
cloud movement). Then there's trees, cities, etc.

As Squat brought up, it's a great idea to have at a certain point whole
*groups* of objects- trees, houses, etc, drop down to a simple alpha
mapped 2-10 poly plane or cube.

Forests can then look truely epic in size, without being proportionately
epic resource hogs. Cities can tower in the distance- their tops brushing
the clouds- without system specs needing to be the same...



The engine *is* solid. Just as much as anything else out there- and honestly
about as well, if not better documented for it's age (although that's always
been a pet peeve with me-engine documentation).

So to answer your question- I use # 2.

Often though, I'll create my terrain, and if having trouble with alignment, I'll export
the heighmaps, and bring them into Gimp, photoshop or paint, and adjust
the edges manually there by copy pasting the tiles into one large, matching edges
and then re-exporting.

It's fast, it's fairly painless, and it looks good, works good- and it doesn't make me
want to throw my computer through the window.

My 2cents. Hope it helps

[Squat]

Heightmaps are really the only viable link between two completely separate pieces of terrain. In the editor, all you can do is bring the edges to be at the same height, but it will restrict you to having flat edges on all your tiles, which removes it as an option. It would take entirely too long to manually adjust all verts to match proper heights if there's any kind of realistic variation going on. As we all know, the verts have to be mathematically identical to avoid a seam that breaks up the smoothing.

My best suggestion at this point is to go with the method of creating one extremely large heightmap and breaking it up into image tiles that you then apply to a large grid of terrain blocks. It will also take quite a bit of time, but it will work and look great. The largest hurdle is how your system handles very large image sizes so if you have a small scratch disk or low memory, you'll chug while doing it. However, unless your machine outright refuses to process it, it will still be lightyears faster than manually editing the terrain.

BTW, no terrain stitching and not being able to adjust multiple terrain objects together is a HUGE detriment to the notion that it's fast and easy to build worlds as large you like. I was under the impression we were afforded the ability to actually create infinitely large worlds, ones that go on forever if you travel in a straight line. With LOD's and zone streaming, this is also supposed to work fluidly but it does less for us if it's next to impossible to work in that environment.

Part of this problem is only solvable by the developers themselves. I believe it's in their hands to make this a truly universal tool and they're extremely close to having it perfect at this stage. Here's my list again of the 'minor' fixes terrain editing needs.

1. At least one level of undo. In fact, JUST one level is ok.
2. Terrain stitching
3. Multiple terrain editing with automatic stitching
4. Automatic generation and in-game management of terrain LOD's. (Honestly, I can click "more" or "less" easy enough, but we do not want to create 6 copies and go through all the .opr settings when it could very well be automatic).

5) Slope based opacity. TRUST ME!

In keeping with my tradition of always adding too many requests, too much info and generally being annoying as if I'm complaining (when I'm actually conceptualizing for the future); I have another idea.

6) Custom terrain painting brush shapes. Yes, a 256x256 black and white bitmap image that we can use for both height adjustments aswell as (and what it's designed for) painting layer alphas. This is an IMPORTANT feature for anybody who wants to make a double tiretrack dirt road or any other kind of area that they don't want to stroke back and forth over with the potential for mistakes and no undo. They can lay out both tracks with a single brush that's merely an image of two separate spheres instead of doing it twice. Brush fade would be ignored on this, only size would retain. Want more faded control? Blur the brush!

Just a note, this requires the brush to align itself with the direction of the stroke. I hope that doesn't kill it in 3D, but it shouldn't since I've used this tool before in multiple other editors, including very old RTS games.

[zknack]

I sort of agree with you on terrain stitching Squat, but I'd lean towards loving to have
the ability for grouped terrain to act as one piece of terrain- that way we don't run into
the utterly disturbing issues that can arise with terrain stitching systems that try to
automate fixing the elevation differences.

I know you kind of noted this between #2 and 3, but just my opinion.

I think it was you who hoped for being able to toggle a grid overlay- and to that I
agree, it's something that does feel a little like it's missing.

I'd LOVE LOVE LOVE to see even ***one*** level of undo.

Custom brushes (even ones that don't follow the terrain direction) would be very
nice, or support for terrain layers that are mostly transparent to begin with (this
may be in now, been awhile since I tried).

I'd like to see auto-LOD for terrains, but I've gotten fairly quick with it anymore

* zknack shrugs

I still don't think there is any issue creating insanely large worlds. I'll be seeing if
I can double the amount of tiles here soon-ishk, and I think we can, easily. It's
just all about asset management, and remember the KISS rule: keep it silly simple..

Players don't care if it *looks* like there's a dynamic economy & NPC lives going on,
or if there actually is.  I think many of us forget that at times?

All that being stated, I'm loving the discussion today guys :-)

[Architex]

I'd say number 2 would be your best bet for large worlds, that's what I'm currently doing.  If you have multiple tiles though, you'd probably want to make them low poly in divisions.  If you're going to use 1 tile, and you've got mountains in your world, a good tip would be to have another terrain object under the main 'ground' terrain' and raise the terrain underneath to create mountain sides.  But my current project really only has hills so that's not a big deal.

Having multiple tiles, though, is a pain if you're painting your roads into the terrain, but it works!

[zknack]

Worldmap at 128 full terrain tiles at max size (with Levels of detail, but at max divisions on any given 3x3 block)
is now working.

This with 9 command blocks per tile is working fine thus far. Just getting insanely hard to track everything.

I'll begin posting stuff when I have texturing enabled, and the tiles seemless (not hard, just time consuming).

Each map has approx. 8 textures thus far (all dummy textures currently)

So, my conclusions are:

MASSIVE worlds are readily possible.

Also: I've been taking the idea of not just LOD'ing individual objects, but towns, trees, forests, etc. as far as
I can- Like Squat said, never underestimate a plain or box with alphas.

[zknack]

Also,

The lego-man looks ****amazingly**** small now on it

* zknack laughs a bit

Wish I could increase the view range in the editor.

[karmacomposer]

Ummm, I have had zero chance to play with the editor, so I am just going to ask:

To align terrain 'tiles', is there a SNAP TO mode?  It seems logical to me, beign that I work with graphics apps all the time, that a snap to function would allow us to align terrain tiles so that the lowest point matches up with the previous.

Does that at all make sense?  Is that already a capability or one to put on the wish list?

I feel deforming terrain painting is essential - painting that allows you to deform the terrain as you paint over it so that you can paint dirt roads and other stuff.

Another really useful feature in terrain painting is to be able to paint zones so that you can define clusters of objects that then go in these 'painted' areas (like trees, houses, etc).

Does Gamecore have any of this yet?

Mike

[zknack]

Question 1 on terrain snaping:

The terrain tiles themselves snap to each other, they do not yet allow you to paint across multiple tiles- there are several work arounds for this. Also - Gekido's mentioned that they have plans to change this.

Deforming terrain painting is definitely in. It is incredibly powerful. There is also a 'road' tool that lets you use
textures or models to 'paint' a road on very quickly.

There is no 'zone' painting per-say, but you will find that the terrain spawner is nutty powerful. You can have
spawners based on jussssssssssssssst about anything about the textures being used in that area. Watch the
videos- there's some good examples as to what can be done with the terrain spawners.

So- in a nutshell, most to all of what you're asking about is in already. If you're good at painting you'll have no
real issues aligning seamlessly the terrain tiles- I know I have little to no problems with it.

I'm not trying to glamourize it, just stating what's in there- it's a fun, flexible program, try the demo :-)

My 2 cents, hope it helps.