HeroEngine Forums
Welcome, Guest. Please login or Register for HeroCloud Account.
Pages: [1] 2

Author Topic: Making a Large Area work (Yes i know it shouldn't be large...but...)  (Read 6849 times)

BenCrossems

  • World Owners
  • ****
  • Posts: 16
    • View Profile

First let me state, that my challenge, is creating a historically accurate environment, set in the south eastern plains of Texas in the 1800's.  Not a lot of trees, very little mountains, and very little structures.  This limits my ability to take a too many freedoms with artistic licensing by adding mountains and forests to limit area linking and visibility where there were none historically to begin with.

I'll be relying a lot on LOD and fog to help with FPS, but here's my question.

I have my starting zone built out (30 square miles at 1/3 scale), and all works fine.  Like most though, when first laid out I did the grid pattern:

A - B
| X |
C - D

and as others experienced, the area that is diagonal is a real bugger to line up.  I plan on hiding any bad seams with instances, (brush lines, fences, and so forth) but I would like to have it as seamless as possible.

My question is :
How bad would it be to create one large Area of 256 Rooms (each 256x256), allowing rooms to control visibility?  I know the ending map would be huge!  (4096x4096).  But would each room not only control visibility but also memory load on the server?


Why?-Using rooms allows for much better control on the seems.

I've also done a lot of experimenting on seamless linking and have found a few things that work to reduce bad diagonal seams. (provided for background in an attempt to qualify my question on large areas with lots of rooms)

1. Reset all height maps to a Y axis of 0 (vertical axis)  I have 4096 height maps and had to do this manually, it pays off though.  (from this point on, i'll always ensure my height map starts at a 0 register on the Y axis)

2. When setting the 'Edit Offset' for an area, don't work on corners.  Align it to both sides, and somewhere in the middle (assuming that the areas you're aligning contain multiple height maps).  Use your smoothing tool, to even out the seems and repeat the aligning process, until holding down shift and dragging along the Y axis results in the area no longer moving up and down.

3. work in a line (don't even worry about the diagonal areas).  Line up all 'adjacent' areas first, then return later and 'tweak' the diagonal areas.  If you line up all adjacent links first, chances are the diagonal areas will fall into place very  nicely.  (in the example above, link and line up A-B, A-C then B-A, B-D, then C-A, C-D, then D-C, D-B, then go back to A and add D...it should fall into line automatically...then do the same for B, adding C)

4. If you can't get a diagonal to work at all...revisit the area...in most cases, i've always found something that wasn't lined up correctly with it's adjacent areas.  If everything was aligned correctly first, it should 'fall' into place with no alignment necessary.

Depending on if one Large area built of 256 rooms each 256x256 for a total area of 4096 would work, will determine whether I pursue 'offsetting' alignment or not.
Logged

keeperofstars

  • General Accounts
  • *
  • Posts: 998
    • View Profile
    • StarKeeper Online

Should never go past 1k by 1k in an area.
Doing so adds extra resource "waste" as the coordinate system has to adapt to manage the added area / space. It will do it, but things get sticky, also the SAS system has to work extra hard on dealing with larger math for the coordinates system.

Also rooms aren't much better than a seamless area edge. Only slight advantage is not having to proxy the data of players between the two areas.

In regards to having things line up, as long as your areas are always the same size, and you make sure you are snapping to the grid it should work out fine with always lining up.

Now when using 1/3 resolution on the terrain you save a bunch of polys, but you do so by removing about 70% of the verticies to work with, this can make stitching much harder as you have so few verts to work with.

However on flat ground with grid on, and same size areas they should be easy to line up every time.
Logged
[img]http://screencast.com/t/x7btcSSyp3h0[\img]

BenCrossems

  • World Owners
  • ****
  • Posts: 16
    • View Profile

Hmm...Makes me consider a few things...when you say 1K, do you mean 1000 or 1024?

I may experiment with area maps at 1024 with rooms of 256 to ease the diagonal issues.

Rebuilding my world at this point in time, with staggered areas, seems counterproductive for our first test.

My areas, are current 512x512.  I was considering breaking them down to 256x256, but if I follow you, it's a wash.

Might be better to import 4 areas into one, creating one area at 1024x1024 (assuming you mean 1024 and not 1000), to even out some of the seams, and provide a bit more latitude in artistic licensing, so I can create better seams between areas.

Logged

HE-Cooper

  • *****
  • Posts: 2221
    • View Profile

If you're having issues lining up seamless 2.0 areas, then it's likely you're misunderstanding the process, as diagonal areas will simply appear in the correct place as soon as they are added, unless you went out of your way to create and then add areas in an obscure order. In which case, just unlink them and use the autosnap.
Logged

BenCrossems

  • World Owners
  • ****
  • Posts: 16
    • View Profile

I keep seeing a mention that diagonals should auto-snap, but in practice I can't get that to work...even with clean areas (new instances with no modification).

I'll try and post some screen shots tonight, but in my experience, the auto-snap only works if there is an edge to auto-snap to...and only to the area your currently editing.

I saw mention of ctrl+Shift and will try that tonight as well.
Logged

keeperofstars

  • General Accounts
  • *
  • Posts: 998
    • View Profile
    • StarKeeper Online

There is a toggle button that forces snap to grid.

If the areas are same and you line up in a row A,B,C
Then next row D,E,F with A,D next to each other, and b,E next to each other, then all the diagonals will line up correctly.

In regards to the 1000 by 1000 I mean a 1000 by 1000 if you create an area in HE that is larger than that it even marks the dimensions in red as a warning notice. I think it might do a popup can't remember.

Also note the dimensions are a bit off in regards to what you think vs what number of nodes comes up.

But uneven nodes not that big of a deal.

Logged
[img]http://screencast.com/t/x7btcSSyp3h0[\img]

HE-Cooper

  • *****
  • Posts: 2221
    • View Profile

Snap to grid doesn't affect area auto snap, as areas have no common grid.
The common confusion for new world builders around "diagonals" is the relative concept of area links. Any edge of a heightmap of an area will autosnap to any other edge, but of course, if you've linked a to b and b to c, when you try to link a to c, they will gain a relative offset, which may not be what you want.

If you link North to Center, and then link East to Center, the diagonal at NE then needs to be linked to North or East using autosnap. After that when you link NE to center, it will automatically appear in the correct relative position with regards to center, and then to any of center's links.

But truth be told, if you are just gridding out an even X Y grid of world, then you're going to regret it later from a performance and gameplay point of view, but I'm unable to convince most new world builders of that fact. :-)
Logged

BenCrossems

  • World Owners
  • ****
  • Posts: 16
    • View Profile

Thank you for clarifying the 1000K.

http://wiki.heroengine.com/wiki/Snap_to_grid

Can't wait to get home and try this tonight. 

Logged

BenCrossems

  • World Owners
  • ****
  • Posts: 16
    • View Profile

But truth be told, if you are just gridding out an even X Y grid of world, then you're going to regret it later from a performance and gameplay point of view, but I'm unable to convince most new world builders of that fact. :-)

I am a believer!  just working with mosaic height maps created over the last 5 years, that I'm reluctant to 're-create'.  This project started in Multiverse, using Earth Builder as the terrain tool...

For our dev platform I'm okay with the grid...but final will be staggered, so no more than 7 are loaded at one time.
Logged

BenCrossems

  • World Owners
  • ****
  • Posts: 16
    • View Profile

So, I think i may know where a lot of people, including me are having a disconnect on why diagonal areas aren't snapping....

here's what I did this evening.

1. create 4 new areas, 32x32 at 0,0,0, and just painted A,B,C,D on each respectively.


2. I then created the linking between areas that share a common edge only (not the diaganals), with snap on.  (everything worked as expected.)


3. After linking all common edges only for each of the four areas, I then went to area D, and added it's diagonal A.


4. Area A fell into position just as planned.  but...if I work on adjusting the heightmap at all, and need to adjust Area A again, the diagonal snap will not work, like it does for those with shared edges.

-note: with Area B...i can drag the 'Move Marque' up and down and area does not move, because it's snapped.


-However: with Area A (the diaganol area)...the area moves with the 'Move Marque' regardless of snap settings


-Same thing with difference Snap Settings:



So...two conclusions :

1. Staggering areas, is the only good way to line up areas...stay away from diagonals...(duh!):


2. It appears that you need to lay out your area map first, before adjusting ANY heights or working with the terrains, for the best results.  (this is where I went wrong with my first attempt)

so...I will try to create copies and stagger them to get some better results.  I have a new grid area/room combo i want to try tonight anyway.

I hope some of this might help.
Logged

BenCrossems

  • World Owners
  • ****
  • Posts: 16
    • View Profile

So far very happy with the re-work of my main starting area map.

Snapping is working much better, and I am now seeing how you have to smooth the seams only between the instance your in, and those areas adjacent to it.

Nice Snapping :


A little final smoothing to line up edges :


And a finished very nicely lined up seamless map :
Logged

BenCrossems

  • World Owners
  • ****
  • Posts: 16
    • View Profile

So, after a LOT of work, in importing modified terrains into new areas, to create a splice of two areas, I'm now able to stagger my grid!

And I like the result!  It's a lot smoother just in the HeroEngine tools, alone.

I also created 4 rooms in each area, and used the visibility of each to create nice squared off rooms.

Here's the grid I'm using


Each area only has a Seamless link to 6 others, and rooms control visibility.

In the image above, the red area shows would be visible if you were in room (rm-2-2-sw). 

Took a lot of pre-planning and had to play with the rooms to get them to work.  Basically you have to define each room in the area it exists and in the area it's visible from. (I'll send screen shots of that later)
Logged

HE-Cooper

  • *****
  • Posts: 2221
    • View Profile

Looks like you're still over thinking a bit there. You've created a standard grid that will still have issues around 4 point intersections unless you build gameplay around them. There's no need to set up rooms when setting up seamless links, as the default room in each area will handle visibility. Nowadays, most games don't make use of additional rooms at all, except for interiors, or dungeons, or isometric views.
Logged

keeperofstars

  • General Accounts
  • *
  • Posts: 998
    • View Profile
    • StarKeeper Online

As cooper points out still got same issue with gridding.

Now with that said, it's often easiest to start with a grid, and then start cutting chunks or holes into it to keep from running into a true grid, but still having an open world feel.

For example if you look at GW2 everything takes place in a valley just about. With mountains playing edge barriers, with only a few places to make the jump across to the neighboring area's. Then they take it another step and break those area chunks into zones / instances.

However trying to build your whole world out like that mentally and visually is nearly impossible. Yes you can pre-draw and map everything out, which is something you should do where it's easiest to make changes.

So an idea is for example if you converted the Red areas to a mountain range, that the player can't traverse, you add a ton of size to your world, cause the player now has to go around, the range, to get from one to the other end, you cut down from having to possibly have 9 to 16 areas loaded at a time a few areas will have more loading than others, but you make those more of your scenic travel spots, and put the fighting in the areas with less connected areas.

Also as Cooper points out rooms, aren't meant to be used for asset occlusion, except in cases of houses or dungeons, castles, forts, etc. Using them for open area asset occlusion is no different then just making smaller areas that are linked together in a grid.
Keep in mind the goal is to minimize the "load" shock of assets and data, when a player steps across the area line and into a new area. Then on the flip side it's about keeping the areas proxy data down. Pushing player action away from 4 corner intersections, etc.

Like I said it's a hard thing to pull off mentally till you really lay down the terrain. Helpful to get your world map finished before building areas out in a final aspect. Use the world map as a backdrop for your grid and start making holes and paths for the players to play in. Seems to be an easier method to doing it. You will probably run across a "brick wall" grid pattern option on the forums here as well, once again not much better off, than a standard grid. It does save you like 2 areas loaded at a time, but only a small savings. When I get home and if I have time tonight I'll make you an example setup of an area with a hole in the middle. etc.
« Last Edit: Dec 20, 13, 01:04:19 PM by keeperofstars »
Logged
[img]http://screencast.com/t/x7btcSSyp3h0[\img]

BenCrossems

  • World Owners
  • ****
  • Posts: 16
    • View Profile

Quote
When I get home and if I have time tonight I'll make you an example setup of an area with a hole in the middle. etc

No need to do that as I am a big believer in limited area usage, and using mountains, forests and water to limit player movement. 

As mentioned in the beginning though, the real challenge is in creating a historically correct map, based on Texas History.  This is a very niche market I'm working with (think reenactors who play mmos), so I can't through a big mountain in the middle of Texas rolling plains, just to control player movement.

That's a key challenge I'm faced with. 

To give you an idea, our terrains are based off of actual 1850 geological surveys of what Texas looked like before rail roads.



I also understand completely on using rooms, for me its an eye sore however, when the staggered area maps don't align in the distance (see below in the far distance where the hills 'stagger')


So, given the scope limitations of the map, (already worked for artistic licensing as much as possible), I'm working to try to create an environment that works well without being taxing.

I played with test versions done like the Current NeverWinter (which I think is perhaps a great example of limited small areas), but lacking the design elements of no mountains, cliffs or man made dwellings, I'm unable to create the map in that way. 

So instead, we're going for the look and feel of DAOC (Dark Age of Camelot).

Logged
Pages: [1] 2