Map edges, how can they be fixed?

[knorke]

I opened the code and it was so sickening I threw up this to my keyboard.

yea i have no idea what i am doing with gl and i think kingraptor is still learning too
So I am glad someone with better knowledge quickly (i guess?) made this in a proper way!

naively thinking.. if you speed up rendering the main area by 100% with ROAM, and add an other 8 areas rendered without roam.. it should be pretty slow.

I only tested on 2 maps and did not play a real game but the fps kind of stayed the same with Pako's widget.

Btw, anyone else noticed how many (all?) maps have a black line around the bottom & right edge on the texture? Is that something mapconv creates?
Normally it does not matter but with the mirroing it is quite obvious because you get long unnatarual lines across the terrain:


I think the tearing between "real/fake" terrain is because of detail level? If you press end/pos1 to change terrain LOD you can see the gaps change etc.

What I as a mapper always dreamed was that I could have total control over how the unplayable area would look like

At the start of the widget there is this loop:
For x=...
For y=...
You could put any formular for noise/height fading or whatever there or have it read from a bitmap that you include with the map.

Also I think the question whether this should be in engine, game or map is worth thinking about.
Smoth can probally safely put it in gundam because he is the only creator of grts_ maps and so knows none of his maps will include a conflicting widget.
zeroK and other games will probally include the widget with the game but that migt be problematic in the future, if mappers include their own tweaked versions with the map? (ie making a map with a flowing river that extends past map borders or a space/asteroid map that uses Lua to draw space or an island in an endless sea of lava)
So it would be maybe good to have some way to tell the widget to turn off? Maybe a WG.variable?

[smoth]

I can safely do it because grts uses:
games/gundam/widgets...

at least the dev version does.

[smoth]

what distortion effects? Clear difference is that KR's widget draws in DrawWorld callin and mine in DrawWorldPreUnit.

interesting, the terrain starts strobing and seems inverted, as though I am looking at back faces.

why would the change from drawworld to drawworldpreunit cause this?

[smoth]

other stuff.

Pako, your widget'd terrain does not received fog. If it could do this and have a tiled texture(like king raptors) that would be awesome. The lack of fog on your terrain really hurts it imo.

[[LOeT]Zinn]

IMHO there are two different aspects to this topic:

A) How to fix in a general way, working with every map and every mod?

as well as

B) How to enhance the map file format on a long term to fix it in a non-legacy manner?

A: I think we should just put a small box around the whole map. From the very bottom to a lil bit above the map level. Which would be the biggest problem. One should still see a flea in the very south using standard camera angle. So the border should not go to high above the map at that position.
The benefit would be a very general approach working with almost every map I can imagine. No problem with water, features, fog, etc. No watching the map from below. No (visible) water under the ground.
For the texture of the boxes walls I think of a static selection (wood, stone, marble, etc. - whatever works) and some algorithm to decide on one of them based on an analysis of the given map colors.

For I am no artist here is the next best* thing I found to illustrate what I am talking about:
Where the Spring-solution needs to have the walls adapted to the maps height so there are no blind spots while watching from a low angle.

B: Some extendable enhancement of the existing map file format to incorporate every good of the ideas from this thread. From the ppl I think I can judge, SirArtturi would be the most competent to think about how to get a working and feature-proof implementation. Yet I dont want to lessen the ideas and implementations from ppl I can not judge that well, like knorke et al. :)

* I hate the whole Battlefield series. It fucked up my image search. Searching for 'battlefield -bf3 -"battlefield 3" sandbox -"bad company" museum' all I got was Battlefield3 and Bad Company screen shots

[hunterw]

Yeah this thread is much better...

I opened the code and it was so sickening I threw up this to my keyboard.

I don't prefer this method. It is confusing as to which areas are playable.

Now with heightmap mirroring!



Would probably look heaps better if combined with a fog effect in some way.

This is in my opinion better. It gives a clear border, still gives a sense of being in a bigger area than the map actually is, and fits the tech theme of nearly all the mods.

Naturally it could just be a LUA which could be turned on and off to taste.

I would recommend a thinner "line" texture, and the grid squares could be smaller.

[Pako]

other stuff.
The lack of fog on your terrain really hurts it imo.

I fixed it and few other bugs but now engine(84.0) fog shaders are all fogged up.

[PicassoCT]

combine always win:

http://www.youtube.com/watch?v=FIYkV2t6o4M#t=3m35s

[Mr. Bob]

Well from a modeling perspective, I would simply make an outside model that replicates the interior of the map. Then have some sort of border structure in the mesh itself (cliffs, walls, or even trees etc). This way you aren't dealing with any bit of the literal map itself. I believe someone in an earlier post mentioned R.U.S.E. It would be somewhat like that, but taken further (aesthetically anyway.)

The model itself could promote non-square borders. Simply have the edge based border structure be within the map itself. So if you had a round map, you'd have the border structure be a circle within the square/rectangle edges. Anything beyond the borders could be blocked off using whatever preventing pathing map spring uses. (I forget what that is.)

Once the model is done, you'd scale it and center it to the map. In my mind, I don't see any reason to even look to the map structure itself for anything outside of the walkable map. The map structure works the way it does because it needs to function with the units itself, so when you take out the functionality, why look to the structure with that function if it is so limiting?

EDIT: For reference, look at what supreme commander 2 had. Though, it's a bit different, as the pathing is based on predefined and separated mesh structure. From the artist's perspective, in terms of practicality, it would be the same process without having to model/texture the interior.

Using alpha channels, it would be extremely easy to transition between the mountains and the terrain. The mountains would all be separate mesh.

And for everyone about to ask the obvious, "what about texture tiling": isn't it fairly easy to implement uvw tiling?



And furthermore, note the blackened edges. This would be faded out the closer you get to the ground with the camera. (It's a really helpful art asset.)

I think we may be making maps in general wrong. Personally, I think the map should be modeled along with the outside model; then separated later, and baked for heightmaps etc.

[Johannes]

For I am no artist here is the next best* thing I found to illustrate what I am talking about:
Where the Spring-solution needs to have the walls adapted to the maps height so there are no blind spots while watching from a low angle.

Something like that seems cool to me. It's simple and very intuitive as to where the playable area ends. And have the board edge be of a angle <90° so it won't hide units on the map edge.
Sure it doesn't make it look like realistic terrain anymore than before, but I don't care about that per se. A gaming board floating in space is a great aesthetic improvement over piece of terrain with ugly edges floating in space, even if some maps might want a different look.


Though there really shouldn't be anything forced by the engine or games into old maps I think, just include the mapedge beautifiations into new maps so it can be decided on a map to map basis, what kind of look the mapper wanna go for.

[knorke]

I opened the code and it was so sickening I threw up this to my keyboard.
http://springrts.com/phpbb/download/fil ... ew&id=6636

I don't prefer this method. It is confusing as to which areas are playable.

Ingame I did not find this to be a problem.
The unplayable areas have no detailtexture, no grass, no features, no shadows etc, all that is subtile but makes it easy to see where the playable area ends.

[Sprang]

I like the blackbox widget by Argh.



Makes the borders look nice and neutral on any map.

However, there's a problem with hills in the map edges:



Looks quite horrible. If this was fixed though, the widget would be an elegant solution imo.

The blackbox widget is attached below.

[Forboding Angel]

Look at the latest stable version of evo (v1.9) for how I fixed the problem (I don't have the ability to load it up and take a screenie right this moment).


Edit:

[Das Bruce]

Do y=y/(distance from map).

[knorke]

Beside texture, what is different to
http://i5.photobucket.com/albums/y195/K ... egrid3.jpg and
http://h4.abload.de/img/noise_map_edges_29ogl.jpg ?

[PicassoCT]

beautifull .. Forb.. do those white lines have a gradient from mapcolour to white?

[Das Bruce]

Beside texture, what is different to
http://i5.photobucket.com/albums/y195/K ... egrid3.jpg and
http://h4.abload.de/img/noise_map_edges_29ogl.jpg ?

Forb picked a more aesthetic texture, which is important. He's also better at taking screen shots.

[danil_kalina]

a fence

[Forboding Angel]

beautifull .. Forb.. do those white lines have a gradient from mapcolour to white?

No, no gradient, but it's all just an illusion. The extent of what I did was take that map gadget that does that grid texture, and change the texture so that the grid was much larger and instead of transparency, made it solid black.

It looks the best out of any solution I have seen so far, and I'm very happy with it. Have a look at it ingame and see for yourself. It works really really well.

[smoth]

looks pretty good to me

It looks the best out of any solution

same shit different day


still didn't fix the main issue, still probably not done at preunit.

I need to sit down and:
- write code to cover the holes(fence or underlying color)
- fix it to be preunit(not a simple switch something wierd is going on)

the black box code fails because:
- has distortions at angles..
- is not preunit(as in effects and stuff are rendered beneath it such as the lasers coming up from the evo mexes)
- when changed to preunit the black outside goes away.
- doesn't follow contours.