Why not placing big (indescructable) features in front of steep slopes? Even wih Spring board placement is a little painful, as you can not (or I do not know how-to) rotate features before pressing the mouse buttun and thus have the position fixed. However, the results are quite promissing so far (esp. with having normal mapping enabled for features). Maybe placement of defined features and terrain height cound be included in SpringBoard as "typicals" - think of a plateau including ramps and cliffs that can be placed by just one mouse-click.
LOD Detail ruined it.
Also if the features core is hidde from camera, the hills have no-eyes and i must scream.
Best approach in my opinion would be to generate the features, from the heigthmap.
Spring Map -> Export to Blender -> Blender Script/PlugIn Generates and Textures Terrain -> Reimport Heigthmap.
That would also avoid all the other Hickups this appraoch had (Clashing with terraindeformation, etc.).
Silentwings wrote:What do you think you are gaining by making them into features, by comparison to just including them in the map?
That ist pretty obvious, isn't it? Features' geometry allows to add lots details to cliffs than possible with heightmaps only. Maybe the shown example is not perfect to demonstrate that as it also a pretty plain slope only. You know, you could do cliffs like shown below.
I guess those features would have to come with a script freezing terraindeformation below- and extrapolating to the deformed terrain nearby. Which means- this type of feature has to come with a heightmap of its own- a relative heigthmap, that it applies to the surrounding terrain, so it fits.
Which gets us to the problem of overlapping terrain. Two features could try to "drag" the terrain to diffrent heigth, so they either have to have a order of execution, have to compromise .
all-terrain unit behavior would also seem weird even if the features are passable (unless they nearly perfectly hug the terrain)
I thought about using features to fake building walls (with windows,etc.) for city maps where you could walk or build on rooftops.
For garrisonable building blocks, some of the building walls could be actual neutral units instead of features and would act as transports that'd change owner to whoever gets there first.
I've been trying to do it for quite a long time, with varying and "promising" success. In the end, however, i stopped caring, for several reasons:
- Back then features were impossible to make always visible, so zooming out caused terrain to disappear
- Using units risked them turning into features
- Using units with huge radius parameter caused gunships to collide with them even when collisions were otherwise disabled
- Using units with low radius parameter caused the geometry to disappear the moment the center was out of view
- It is incompatible with terraforming unless you invest a ton of effort to somehow fix that
- Units and features used as terrain cannot receive explosion scars and track marks
- Units and features used as terrain cannot be shaded with Spring terrain shaders, including infomap shaders like metalmap, heightmap, and last but not the least, LoS. (yeah using volumetric fog as fog of war would still work for that)
- Units capable of moving *on* those cliffs still limit artistic freedom significantly if you think about it and there are no good tools to make that easy.
In general, i don't think it's worth it for the games that allow terrain deformation. For the rest, the amount of work that needs to be invested for this to be good could be spent on making it an engine feature instead.
My current dream-pipe idea for what would improve Spring terrain visuals is two-pronged:
1) Fully splatted materials - same as DNTS, but with stronger material support including diffuse, speculars and emissives, and with more materials per map
2) Triplanar mapping