Spring RTS Engine

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.).

http://zero-k.info/Maps/Detail/27337

Also cliff is so sexy- people would jump-jet to death just for the eye candy.

What do you think you are gaining by making them into features, by comparison to just including them in the map?

Your picture looks to have a problem with alignment between the map and the feature-cliff, btw.

With heightmaps, top-down planar projection causes unsightly texture stretching on steep surfaces.

The idea to hide them under automatically placed features isn't new (alas, dead screenshot links) and should be more feasible in 104+.

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.

viewtopic.php?f=13&t=33627&p=571092&hil ... ry#p571092
viewtopic.php?f=13&t=30548&hilit=black+mescaline

PS: Anarchid had a really nice working example of geometry generated to fit a cliff.

PS: Azaremoth is right, because extending artist freedom == always a good thing.

INB4 Kloot ranting in Bug Reports about wankers throwing out Polygon and Texture-Ram as if it where not hard earned.

You'd need to handle terrain deformation for those areas, somehow.

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 .

Everything gets messier from here on.

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.

But damn they are sexy - and essential for city maps. As long as we dont have it - we will never have this:

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

I'm sure Sinbad was the first to do this, pre-2010, going as far as making the entire map out of features

Picasso made an attempt at this as well: https://springfiles.com/spring/spring-m ... escalin-v3

Drag net fishing the past..

Let me leave this here. Post if you want the code that does it.

viewtopic.php?f=13&t=32228

If you can share it under an open source license i'd like to see it - potentially many uses out of it

Check edger.py in this zip (like 700MB) , license: PD

http://imolarpg.dyndns.org/spring/alter ... onghold.7z

@ BARherith:

Did you use Zwzsgs hexfarm code for this?

Also sorry for the still WIP foliage, i got no photoshop where i am. No 3dsmax either.

Nope, purely my own.

Srill have had no sucess with it. After i update my gundam game beyond bitrott i may revisit this.

This is exactly what i was on about last night gajop