Modifications to defensive building models needed

[Per]

A simple solution to the problem of the deeper structures blowing up the GUI is to duplicate the model when importing it into the game, with one for GUI and one for map drawing, and dropping all vertices below zero depth for the GUI model. If the artist knows that all vertices below zero are going to be dropped for the GUI, then I suppose it would be easy to make the model in such a way that this would not cause ugly artefacts.

[MaNGusT]

New PIE flag 0x1000 added which prevents a model from being stretched to terrain, useful if it has its own deep foundation

I think that this is more a hack than a fix for this problem. I want to suggest a better solution. At least I think that it's better.

At this moment flag 0x1000 can be used with buildings which have its own deep foundation but It causes 2 bugs:
1) building with deep foundation will intersect borders in construction menu.
2) defensive structures like bunker will be unkillable because the new "center" of a model will be under the zero height, units will shoot the terrain instead of a building model.

A simple solution to the problem of the deeper structures blowing up the GUI is to duplicate the model when importing it into the game, with one for GUI and one for map drawing, and dropping all vertices below zero depth for the GUI model. If the artist knows that all vertices below zero are going to be dropped for the GUI, then I suppose it would be easy to make the model in such a way that this would not cause ugly artefacts.

This is almost what I was thinking about.
I suggest to use a special foundation model for an each building. This model will be in a separate pie file and will be connected to its main model through the stats(i.e. foundation gfx):
-it will be easy to show only main model in construction menu, so it will not inersect borders
-units will shoot only main model

what do you think Per?

[Per]

It has been a year since I wrote that post. In the meantime I've had some time to think, and to implement. What is currently in master uses shaders to stretch models, I think I described how in another post here somewhere. However, I have lately become dissatisfied with this approach as well, in particular because of how hard it is to handle walls. (It also was somewhat unpopular because it adds a hard requirement for shader support.) Walls also will not be solved simply by adding extra foundations to the model, or by adding foundations as an extra model. They are simply quite hard to do right with the current way of doing things. Which is why I have started questioning the Current Way of Doing Things(TM). Right now I think the best way forward is to drop support for building on uneven terrain. I wrote a longer explanation of this in a private email:

Ever since people have started working on improving the model
rendering code, we have hit issues with how it has been designed. It
was written to take the CPU-based immediate-mode design to the max,
and has been very hard to change it to a GPU-based retained-mode
design, which is required to draw higher-polygon models with
higher-complexity shading. This is the reason I added a shader
requiring solution, which upset some people with bad drivers and/or
old hardware. However, even so, I was looking at writing a hideously
complicated shader to support wall rendering, which I was never
motivated to start on. The deep problem here is how buildings are
fitted to the terrain, since the terrain may be uneven, and building
models either require individual adapting to terrain (used by defense
buildings) or the terrain requires dynamic flattening (used for
non-defense buildings). There are long threads in the forum debating
various solutions to this issue - I do not wish to rehash this debate
here. None of the discussed solutions are very satisfactory over the
whole range of possible models, especially due to walls.

My proposed solution is drastic: We remove support for building on
uneven terrain. This, I believe, is the solution adopted by nearly all
(or all?) contemporary RTS games. This allows us to drop all the ugly
hacks related to adapting buildings and terrain flattening,
simplifying both terrain rendering and model rendering in one neat
stroke.

There are some problems with this approach, however. Every map needs
to be checked to ensure that they have even terrain where buildings
are supposed to be able to be built, and unacceptable levels of
unevenness must be flattened out (acceptable levels may be very small
to be visually unnoticeable). I do not think that this can be done
automatically. This includes all campaign maps. It will break maps
that are largely composed of slopes entirely. I do not know if any
such maps exist, in either skirmish or campaign. I am sure that we can
enlist some support for this task from forum members, if we manage to
sell this solution to the community at large. The impact of such a
change on a player's ability to wall off areas on existing maps is
hard for me to evaluate beforehand, but for maps designed with this
limitation in mind, it should work fine.

Doing this will allow us to bring back the old fallback for non-shader
drawing, since we will not need shaders to do the heavy lifting
required for adapting buildings to terrain. We can have normal maps
and other advanced features only for the shader-based path, without
this causing us a maintenance nightmare.

Afterward, I tested quite a few maps to see how much impact such a rules change would have. The result was mixed. On the one hand, with the standard camera angle, you simply don't notice the difference, since that angle makes almost any unevenness in the terrain invisible anyway. (Eg I had no idea Miza was that bumpy.) On the other hand, almost all standard maps are very uneven, and require a lot of by-hand modification. Without modification, it was almost impossible to build anywhere outside the starting base area on those maps. The worst may be maps like Bananas, where the whole map seems sloped.

Cybersphinx wanted to explore another way of solving the problem, by storing static copies of every single model instance on the GPU. I am unsure of that solution, but I am going to await whatever results he comes up with before going further with the above idea.

[MaNGusT]

Walls also will not be solved simply by adding foundations as an extra model.

Why?! because they align to each other?

I want to extend my idea by adding solution for walls.
We don't need a Great China Walls in wz, so why just not remove its alignment? this way we can use foundations as an extra models.
or I think there is another solution:
in addition to what I've wrote above, I suggest to grade(split) the height of wz's maps onto levels(floors).

simplified example

Also, in addition we should be able to build only 1 tile buildings on sloping terrain.

If we want to build a big building on an uneven terrain, the game should calculate how much the difference between lower and higher points we choose to build on. If difference is low, we should be able to build in way like this

P.S. the only problem I didn't think about is - if a factory will be built on some height and a foundation will be added, so if we by any chances will have the object event-driven animation and units will drive out from a factory, they will "jump" from this height to a near terrain. But well, for this problem can be added a special baseplate and a special foundation with a slope.

[Per]

I think jagged walls will look very bad. I can see if I can test it out and see how it turns out, since it is a quite simple solution to that problem.

Adding foundations to all buildings was the first thing I tried. It did not look very good. (https://gna.org/patch/?895) The height differences from one end of a building to the other could be quite large, and adding sloped foundations would make it enormously complicated.

[Jorzi]

I agree with MaNGusT, while it might not be as pleasing to the eyes, it is still a working solution to just remove the wall alignment and let walls be "stepped", they do this in AoE2, too, and it doesn't hurt the gameplay. Also, they do it irl in Gaza

[MaNGusT]

That is what I understand as a slope.

sketch

Yeah, baseplate should be "reconfigured" to implement the slope deeper into the baseplate:( or allow units to drive on it(slope).

[Jorzi]

Nice sketch mangust, although I must say that changing the height is how most games do it and, graphically at least, I find it an elegant solution.
@Per: I do get what you said about editing compiled data though...

[effigy]

How awful would it look to simply mirror the wall model at it's "bottom" and let the mirrored top fade into the terrain?

[Jorzi]

It could work, but making a proper extension in blender would be a non-issue.

[Per]

Examples of walls with jagged edges instead of being dynamically adjusted to neighbouring walls. If you know maps that are better examples, let me know and I'll make snapshots of them.

[Per]

The patch itself, for the adventurous.

PS Since the textures to not match up any more, masonry is a bad choice for texture material. However, prefab concrete slabs should look good, and should in any case make more sense in a makeshift robotics-based, post-apocalyptic military base.

[MaNGusT]

Examples of walls with jagged edges instead of being dynamically adjusted to neighbouring walls. If you know maps that are better examples, let me know and I'll make snapshots of them.

Good! that looks much better for me, no twisted textures anymore. May be we should create a poll?

P.S. what is the triangles limit for walls?

[Per]

May be we should create a poll?

If you artist-y guys approve of it, that is good enough. This will seriously simplify our rendering issues.

P.S. what is the triangles limit for walls?

Well, how many do need? They are only walls With the above change, there is no hard limit, really.

Maybe you could make a new wall model (not for AR, but for master) that works better with this rendering method?

[MaNGusT]

well,I thought that there was a hard limit for walls..I will see later how much I need. Also, Jorzi has a new model, I think he needs(and me too) a new exe to test it.