next-gen maps
Moderator: Moderators
next-gen maps
Out of curiousity, is it possible with the current Spring version to create maps that are partly or entirely made out of custom geometry and textures (as seen in most current RTS games)?
Re: next-gen maps
Yes.
Though the custom geometry and texture will be just for looks.
Though the custom geometry and texture will be just for looks.
Re: next-gen maps
Do you mean that tactical advantage of height differences cannot be applied with custom geometry?
I'd like to create maps with custom geometry like, for instance, this:



I'd like to create maps with custom geometry like, for instance, this:



Re: next-gen maps
The custom geometry will be intangible or solid features overlaid on top of the primitive landscape-map that is the true face of a Spring map.
Re: next-gen maps
In other words I should ask for a feature request to get this kind of functionality?
Re: next-gen maps
No, you can't do that in Spring atm.
However.
If we turned off map drawing, we could have arbitrary geometry and an invisible heightmap, like zxswg's latest experiment.
However.
There are no supported model formats that can make use of multitextures per face on this engine atm, other than a few demos by the leet, who have never released any working code, to the best of my knowledge. And building that kind of scene geometry by hand is really impractical.
And there would only be the crudest shadowmap support, no terrain damage, and no real support for decals, and generally no interactivity of any kind, unless you want to write all of this from scratch.
Basically, we can't have this sort of terrain without an entirely new map format and other major changes. Just drawing the map's surfaces isn't enough- I'm sure I could build a really gee-whiz demo of what our maps could look like, using shaders, etc., but it's pointless right now.
My guess: most of these engines use low-poly meshes for collision detection and 3D pathfinding. Really, the guy to ask about that one is Kloot, I'm just guessing.
But, my guess is that the pathfinders don't worry about height, they merely worry about collisions in a discrete arc of ray-tests, and map out short-term pathfinding(the expensive stuff) that way, like shining a flashlight in the dark. If they can't find a path upwards, they stop, if they hit a collision with a cliff, they stop. Otherwise they probably raycast in an arc to find a valid path.
This would explain why most of these mesh-format maps have such big, broad ramps (for easier pathfinder behavior) and otherwise use very steep cliffs, for the most part. And why they're very low poly, if you actually look at what's geometry.
But basically, the methods they use are completely different than Spring's current methods, I suspect, and have some pretty big advantages, in terms of beauty, but probably perform less well than Spring does, for massive unit-counts and long paths, and really depend on very strict camera control for best planned-for performance, I suspect.
However.
If we turned off map drawing, we could have arbitrary geometry and an invisible heightmap, like zxswg's latest experiment.
However.
There are no supported model formats that can make use of multitextures per face on this engine atm, other than a few demos by the leet, who have never released any working code, to the best of my knowledge. And building that kind of scene geometry by hand is really impractical.
And there would only be the crudest shadowmap support, no terrain damage, and no real support for decals, and generally no interactivity of any kind, unless you want to write all of this from scratch.
Basically, we can't have this sort of terrain without an entirely new map format and other major changes. Just drawing the map's surfaces isn't enough- I'm sure I could build a really gee-whiz demo of what our maps could look like, using shaders, etc., but it's pointless right now.
My guess: most of these engines use low-poly meshes for collision detection and 3D pathfinding. Really, the guy to ask about that one is Kloot, I'm just guessing.
But, my guess is that the pathfinders don't worry about height, they merely worry about collisions in a discrete arc of ray-tests, and map out short-term pathfinding(the expensive stuff) that way, like shining a flashlight in the dark. If they can't find a path upwards, they stop, if they hit a collision with a cliff, they stop. Otherwise they probably raycast in an arc to find a valid path.
This would explain why most of these mesh-format maps have such big, broad ramps (for easier pathfinder behavior) and otherwise use very steep cliffs, for the most part. And why they're very low poly, if you actually look at what's geometry.
But basically, the methods they use are completely different than Spring's current methods, I suspect, and have some pretty big advantages, in terms of beauty, but probably perform less well than Spring does, for massive unit-counts and long paths, and really depend on very strict camera control for best planned-for performance, I suspect.
Last edited by Argh on 28 Aug 2009, 20:04, edited 1 time in total.
Re: next-gen maps
I predict that it isn't likely to happen.
It probably would have to be done with models placed over map geometry. I do not see such a thing existing as it would require the creation of said tiles and a system to support them.
It probably would have to be done with models placed over map geometry. I do not see such a thing existing as it would require the creation of said tiles and a system to support them.
Re: next-gen maps
Thanks for your excellent explanation Argh! 
I'll do a feature request and hope for the best

I'll do a feature request and hope for the best
Re: next-gen maps
o_OArgh wrote:Wall of text
It has nothing to do with the map format...
How do you think those maps are generated? No, the aren't mesh-format maps, this would cost too much for a RTS. They are doing the same thing Spring is doing (+sometimes extra code for bridges), they are using a heightmap and on top of it they place models/features for more detail.
Sure their editors make it easier to place such features on the map, so you can easily make walls and align them correctly or even manage entire geometries in tiles.
But still it has nothing to do with the map format.
So you just need to be a modeler and create such map features as Pxtl said.
Last edited by jK on 28 Aug 2009, 20:46, edited 1 time in total.
Re: next-gen maps
I woulnd't be surprised if the SC2 maps really were tiled meshes... they could restrict the zoom and perspective to avoid showing the user the whole map and thrashing the framerate. A modern computer could probably handle a few hundred mesh-based tiles at a time.
But either way, Spring is designed for landscapes. The best approach would be to use landscapes and lots and lots of meshes, like a UT2k4 map would. You'd have to turn off terrain deformation no matter what, so losing this feature is no biggie. Losing other effects would be a problem, so you'd want to make sure that all the stuff units actually stand on is just landscape - you just use models for the edges - for walls and cliffs and whatnot. You could probably make something that looks a helluvalot like those StarCraft maps that way.
Imho, a nice feature to make this stuff easier would be an alpha-channel for terrain, imho... although I don't know how that would interact with groundflashes and shadows and whatnot.
But either way, Spring is designed for landscapes. The best approach would be to use landscapes and lots and lots of meshes, like a UT2k4 map would. You'd have to turn off terrain deformation no matter what, so losing this feature is no biggie. Losing other effects would be a problem, so you'd want to make sure that all the stuff units actually stand on is just landscape - you just use models for the edges - for walls and cliffs and whatnot. You could probably make something that looks a helluvalot like those StarCraft maps that way.
Imho, a nice feature to make this stuff easier would be an alpha-channel for terrain, imho... although I don't know how that would interact with groundflashes and shadows and whatnot.
Re: next-gen maps
you don't have to turn off deformation. just make areas that the tiles are on super hard.
Re: next-gen maps
http://www.sc2blog.com/wp-content/uploa ... hot023.jpgPxtl wrote:I woulnd't be surprised if the SC2 maps really were tiled meshes... they could restrict the zoom and perspective to avoid showing the user the whole map and thrashing the framerate. A modern computer could probably handle a few hundred mesh-based tiles at a time.
-> check the cliffs
Re: next-gen maps
Good point. Performance would get a big hit when handling pure geometry maps. I'll try to create a "next-gen" map pretty soon.
How about pathfinding? Can it handle this complexity?
How about pathfinding? Can it handle this complexity?
Re: next-gen maps
Pathfinding would ignore your geometry and read the landscape, with the usual avoidance for the footprint of any features you declare as solid obstacles.V1ntage wrote:Good point. Performance would get a big hit when handling pure geometry maps. I'll try to create a "next-gen" map pretty soon.
How about pathfinding? Can it handle this complexity?
Re: next-gen maps
I don't see what's next-gen about those games. Starcraft II and Red Alert 3 are both rehash of first-gen RTS. The tiles are now 3d, and these maps are prettier than the average Spring maps because an army of designer was paid to draw/model all the pretty details, but technologically, I'd say they are inferior to Spring maps. No terrain deformation, no interaction with the map geometry and the features, it's the same old flat levels seperated by cliff and joined by ramps that we had back in the C&C1 era.
Which is why you can do them right now, in Spring. Just add tons of features to your map. Or, harder but better, draw any custom geometry you want with some OpenGL Lua.
Have you tried playing the game you posted pics of? The complexity of the map is just powder to the eye, pathfinding and all the rest of calculation ignore them. When I'll see mini-spiders climbing around the polygons of DoW boxes or SC2 advert-panels or RA3 palm trees, I'll be impressed, but nowadays, games are about prettier graphics but less interaction with what they represent.V1ntage wrote:Performance would get a big hit when handling pure geometry maps.
How about pathfinding? Can it handle this complexity?
Which is why you can do them right now, in Spring. Just add tons of features to your map. Or, harder but better, draw any custom geometry you want with some OpenGL Lua.
Re: next-gen maps
Ok, thanks for pointing that out zwzsg and Pxtl :)
There is some more interaction with new elements and height differences in SC2 than in the original SC though. For instance, smoke blocks FOV. Some units can jump off and on a relatively high cliff. Just look at a battle report video (http://www.youtube.com/watch?v=W6tjnC3hFN0)
We'll see how it goes if we ever get to implementing something similar.
There is some more interaction with new elements and height differences in SC2 than in the original SC though. For instance, smoke blocks FOV. Some units can jump off and on a relatively high cliff. Just look at a battle report video (http://www.youtube.com/watch?v=W6tjnC3hFN0)
We'll see how it goes if we ever get to implementing something similar.
Re: next-gen maps
Jumping between arbitrary height levels is not really that advanced behavior, for things much more interesting, look at the all terrain units in the *A mods (CA in particular), or the jumpjet units (again in CA). Hell, take a look at the jetpack or the surfboard in CA. While I enjoy playing SC and co., I have to say that their maps, while beautiful, are simple in concept.V1ntage wrote:Ok, thanks for pointing that out zwzsg and Pxtl :)
There is some more interaction with new elements and height differences in SC2 than in the original SC though. For instance, smoke blocks FOV. Some units can jump off and on a relatively high cliff. Just look at a battle report video (http://www.youtube.com/watch?v=W6tjnC3hFN0)
We'll see how it goes if we ever get to implementing something similar.
We could argue that this simplification (tiers connected by ramps) makes the game more enjoyable for a lot of people, but it is a simplification. The only gripe I have with our mapping system is that atm REAL caves and bridges are more or less impossible on our maps (yes i know about that bridge unit zw), but those things are done by workarounds in these other games too.
Re: next-gen maps
Seem a split happened:
There are 3 methods of feature placement beyond the old fashioned bitmap.
World builder(it is a feature placer not a level editor)
Spring map editor(map editor with feature placemet)
featureplacer(which is just some lua I am working on)
There are 3 methods of feature placement beyond the old fashioned bitmap.
World builder(it is a feature placer not a level editor)
Spring map editor(map editor with feature placemet)
featureplacer(which is just some lua I am working on)
- Sindwiller
- Posts: 46
- Joined: 30 Jul 2009, 14:01
Re: next-gen maps
As a matter of fact, the mapping tools and pipeline for Spring is a bit of a mess and due to the way you create maps results are often clunky. There isn't even any information on how the map format actually works, e.g. what Mapconv actually does, which is not really a good sign either. I thinkt that all should be cleared up. A mapper's life should be made easier before making radical changes. Despite the advantages you get from having one big heightmap, it also comes with a lot of losses, doesn't it? In fact, I can't even make a simple bridge, which would actually change the gameplay in a way, or a concrete area with buildings and a terrain area. Furthermore, you store the coordinates of level geometry/models in a image file? :S
Re: next-gen maps
It's all in the sourcecode(s) son.Sindwiller wrote:As a matter of fact, the mapping tools and pipeline for Spring is a bit of a mess and due to the way you create maps results are often clunky. There isn't even any information on how the map format actually works, e.g. what Mapconv actually does, which is not really a good sign either. I thinkt that all should be cleared up. A mapper's life should be made easier before making radical changes. Despite the advantages you get from having one big heightmap, it also comes with a lot of losses, doesn't it? In fact, I can't even make a simple bridge, which would actually change the gameplay in a way, or a concrete area with buildings and a terrain area. Furthermore, you store the coordinates of level geometry/models in a image file? :S