terrain/ground imitation

[rübe 127]

In short: why would AI repeatetly step a bit forward, then backwards and forwards again while standing on a fake-terrain-object? It's like the AI would keep searching for a better spot to keep formation, because if ordered to "stop", they really do stop and behave normal again. (resolution-, geo- and roadway lods should be fine).... plus we might turn this into a general fake terrain tips thread.

I'm currently trying to model some simple terrain imitation objects, which are later to be used (in conjunction with some script) to prepare/spawn a horizontal spot, much like the fake ground beneath the warefare buildings.

Shouldn't be too hard, I've pictured, yet there I struggle.. it might be a config problem, though I doubt it.

The strategie is quite simple: let's model 3 elements: a squared/flat center ground piece, one for the borders and one for the corners, spawn and put them together by a script and that's it.

To ensure fine geo lods (geo, view and fire) and simplicity, I started with cubes, deformed them to make the slopes of the border/corner elements, triangulated the topfaces, so the faces are all planar again. Though convexity should be guaranteed this way, it still found some non-convexities, but a hit to "component convex hull" solved that easily without generating any mess. All fine. (the bigest object is the corner and has 25 components; 10 x 10m, whereas the center object is 4 x 4 m, so we have 6m for the slopes. Btw. the horizontal/top faces are at height 0, so the complete object is below zero and I've to raise it later per script as much as desired)..

Then I've built the resolution lod from this (while merging all the overlapping points from the individual components from the geo-lod and applying some texture/material).. duplicated, closed and triangulated to make the 0 shadow lod.. copied the top-faces to build the roadway (displacement + 0.01 in height)..

For now, I didn't bother with a path-lod, for I figured, there will be nothing in the way..

At first glance, the result was perfectly fine. The AI followed me and kept formation, while treating the spawned objects just like normal terrain. But once they catched up to me, one ugly problem occured: any unit standing ontop of my fake terrain objects woudn't stand still, instead they were going half a meter forward and half a meter backward (no pivot).. repeat. This not only looks akward, but also makes them pretty ineffective. Of course, this needs to be solved. A thing to note is, that once I ordered them to "stop", they finally would stand still. Otherwise - I guess - they were trying to keep formation and they kept adjusting...

So what might cause this? The only official fake-terrain in mlod I've found is "Stoh.p3d". But I can't spot any critical difference there, besides that I'm more unsure about some modeling "rules" than ever before:

1) Does a geo-lod need to be slightly displaced/sinked or not?

2) Does a roadway lod really need to be slightly displaced/lifted or not?

If I look at Stoh.p3d, I conclude that such things do not apply, so I should be able to work with the exact points from any of the resolution lod. (of course geo lods are simplified, but points can sit at the exact same spot)

I've tried lot's of things and don't really know what else I could try. I've done path lods for each of the objects, it didn't change anything. I've modified the geo lod and the roadway lod several times (from an exact match with the resolution lod to the sinked geo and lifted roadway lod by 0.01, ...).. nothing changed. :(

As for the config: nothing fancy, like "Land_Dirthump01" in ArmA2 (which dos not suffer from the explained "dancing soldiers" problem) I inherit from house and that's it basically (vertical position, no destruct, not animated, ...)

And since I haven't found an existing thread dedicated to fake terrain object's, we might use this one here in a broader way and share some tips?

modeling terrain in regard to good geo-lods

IMHO it isn't that easy to model fake terrain as it might occur at a first glance. Problem number one is that nice terrain is usually pretty bumpy, thus makeing good geo lods isn't that easy after all (for we need simple and convex components only). Basically, for every gap/hole there is, we need to model another component.

The point is: if I start with a 2d-mesh, segmented into lots of bits to be displaced to form nice terrain, etc. I can model a nice terrain for my resolution lod very quickly and easily. But what use is this nice terrain, wihtout proper geo-lods? (Re-)Doing this geo-lod by hand at an adequate accuracy isn't really an option (oh boy). Therefore - as described at the top - I did the geo-lod first, which is much faster.

So is this a "valid" strategy to model terrain or is there a better way? What's your way?

Btw. looking at BIS resolution and geo-lods, I'm quite astonished how "perfect" they always seem to be. Resolution lods degrade pretty close to O/2 (half complexity/faces per step), and their geo-lods are simple yet close enough.. What's the secret or workflow here? You can't tell me, that all the "degenerated" lods are carefully modeled by hand, do you? Oh boy, hehe.

proxy objects

I did my first experiments with proxy-objects, foliating my terrain with BIS ArmA2 objects from the "plants2" repository. Easily applied/set up, yet really effective to adapt the fake-terrain better to the real terrain. (btw. to make those objects work in game as well as in oxygen/buldozer, extract the pbo under p:\ca\ into the directory that is given in the $PBOPREFIX$ file. For clutter and other "dead" objects, no config seems to be necessary)

Now, since I wanna model fake terrain with a few repeating objects, I don't wanna end up with the same clutter/proxy objects on all those objects. That would certainly look pretty stupid. What I can do now is defining these proxies as hidden selections and thus I can easily define multiple variations of these basic terrain-objects, hiding different proxies for them... Thing is, I would need to take care of this in an additional script (the spawn-script), to randomly choose a variant, etc.. And that's not really nice.

The better solution certainly would be to have random proxies, defined in the config for one single object without the need to define multiple variants. (much like the vegetation/clutter-population definition for islands/visitor where you can define a probability for multiple objects).

Can this be done? I've found one old thread with a strong hit, that it should be possible: there is a class RandomShape in CfgNonAIVehicles. Then, instead of defining a model, there should be something like this (tooken from this other thread):

class RandomInForest
{
//models[] = {"str smrcicicek",0.3, rosti,0.3, "pahejl smrk",1};
models[]= {koule,0.5, cube,1};
autocenter=false; // normal vehicle are autocentered
scope=public;
reversed=false;
model = "";
simulation="randomshape";
};

I guess you'd then could use "RandomInForest" as proxyname in O2. But what's up with "str smrcicicek", rosti, etc.? So models is the object pool to choose from, defined in pairs of values, first the proxy-object-name, second the probability or weight of occurance. Do these proxies have to be defined in the config aswell? Or can I put a path to any p3d in there?

Does this actually work or shouldn't I bother (and waste my time) at all? Because there is no single example for this in ArmA2, not for furniture in buildings, not for something else.. (or I'm blind). thus I'm not very motivated to fiddle with this for hours, only to find out that it doesn't work. So any confirmation or denail would be welcome.

suitable terrain material

As I understand, real terrain is a "composition" of several texture-layers which you can't replicate with the given shaders. But that's not too bad. You still can manage to get nice fake-terrain.

The dirt_humps or the Stoh.p3d all use simple:

PixelShaderID = "NormalMapSpecularDIMap";
VertexShaderID = "NormalMap";

So they have a diffuse/color-map plus a normal-map (nohq), no or very low specular power.

What I currently use is:

PixelShaderID = "NormalMapDetailSpecularDIMap";
VertexShaderID = "NormalMap";

for I think the additional detailmap really adds to any fake-terrain (aslong as it's not based/build from the diffuse map, but is a completely different pattern).

Any other suggestions?

[mikebart 1]

As I understand, real terrain is a "composition" of several texture-layers which you can't replicate with the given shaders. But that's not too bad. You still can manage to get nice fake-terrain.

hey reube, you could use a mask material to blend multiple ground types and then somehow render that to texture to say a 256x256 for the distant lod's.

this sounds really interesting, im looking forward to see how it goes.

[rübe 127]

@mikebart: nice to see someone other is interested in this topic too! However, I can't quite follow your idea (at least I wouldn't know what to do). But I guess the best option would be to use the new Multimaterial for fake-ground. I didn't manage yet to experiment with this, but I for sure plan to. I imagine this could work very well for a "stones on grass" texture or something like that, where the stone-material has a pronounced normal-map (nohq).

Yeah, after reading a bit more into multimaterial (up to 4 CO-maps mixed per a mask-map... using 14 stages, oO), I guess that is exactly perfect for the task at hand. Though I wonder, if this will cost considerably more cpu/gpu-power than a much simpler material, using only a normal and detail-map... Imho the goal should be to have a fake terrain that doesn't cost much power.

Advantage of using MultiMaterial is similar like with landscape (technology is similar) - saves textures, higher detail, prevents repeating.

^^ sounds good, doesn't it? Especially the "prevents repeating" part :D

Anyway, I did some further tests with my fake-terrain regarding my problem, and got some surprising results. First, here a little animated gif that shows the problem (though this are only two frames, it really does look more or less this silly):

Ordering them to "stop" makes them standing there in a normal fashion. Otherwise it looks like they don't manage to keep in formation, and thus the back and forth...

Now, as mentioned, I've modeled the terrain `underground`, thus the horizontal surface/roadway of my objects is at 0. Considering this might be the problem, I lifted my objects, so they start at 0-height, so that I have to sink them later again as desired (opposed to lift them from the ground as desired)..

It got worse! Now, they simply refused to walk over the fake terrain. Like the terrain was marked as unpassable. Back to oxygen I did made some path-lods once again (4 ins in all direction with pos1 in the middle). Back ingame, they still walked around the fake terrain, thus deforming the formation, but if ordered to walk ontop of such a defined pos1 from any element, they did (they couldn't without a pathlod). But once order to follow the formation again, they would immediately leave the fake-terrain and walk around it again... Only by accident one or two units would walk onto the fake terrain, sometimes with normal behaviour and - now it comes - sometimes they would again bounce forth and back... omg. :/

I really don't know if any of this is intended behaviour or an odd sideeffect. But what strikes me most is this:

1) model your fake-terrain "underground", so the top horizontal surface will be at 0, then the fake terrain works perfect ingame: units walk over it like it would be any other terrain, keeping the formation perfectly. There is no need for any paths/path-lod at all! Only there's still my original problem: if they come to rest over this fake-terrain, they go back and forth like in the gif.

2) model your fake-terrain "on top" of the ground, and the AI will refuse to walk over it. It looks like the AI would recognize it as "terrain" but as an object which best is to be avoided. Second: now we absolutely need a path-lod, or they are simply not able to walk ontop of the fake terrain. And still, if you do have the path-lods, they still won't treat the fake terrain as normal terrain, but rather as an alien object and only walk ontop of it by accident or if ordered to. And, the original problem isn't solved at all and might still occur.

So I really recommend to model the terrain below 0, which yields a far better result in AI-interaction without the need to do any paths at all. Still, they bounce back and forth ontop there, which is pretty much a showstopper because it is that silly. So the question remains: how to stop that?

Also I would much appreciate it, if someone with a deeper insight into the mechanics could tell something about this. Is this behaviour intended at all, so fake-terrain indeed should be modeled underground? Or is this just a sideeffect, so this behaviour might stop to work at a future point?! And why do they dance? What can cause this?

Edited November 24, 2009 by ruebe

[.kju 3245]

Not sure if it is really related, yet be sure to check SPON DynamicTerrain.

[rübe 127]

oh boy, that's an impressive project. Unfortunately it looks like the project is abandoned, at least the last repository update is from spring 09 (though it's pretty informative in there, also their bugtracker grants some insight).

And it's for arma1, so I wonder if those guys have plans to take their work to arma2? Or did they meet any insurmountable problems leading to a halt?

If you think about it, it's a very nice approach to deform terrain, using simple animation for each tile-points (unfortunately their dbo_tile.p3d is binarized, so I can't really look at it.. of course I can imagine what the tile has to look like, but I wonder about details...)

What I can conclude is: they've used no paths-lod at all and their tile-box is positioned above the ground (starting at y=0). I wonder if this bug could be fixed by modeling the tile underground (below y=0) and if, as a result thereof, the described AI going back and forth would also occur then...

I guess this approach could be easily used, to randomize my own terrain-elements a bit, which would be incredibly usefull to make it look way more natural (without the need to pile up x variant objects..).

Anyway, thanks for the reference to their project (I wonder why I haven't found this by myself.. guess my google-fu sucks big time :/ hehe).

[.kju 3245]

You can reach Deano at OFPEC. Spooner left the scene unfortunately.

Deano is about to port it to a2 from what I know.

[mikebart 1]

@mikebart: nice to see someone other is interested in this topic too! However, I can't quite follow your idea (at least I wouldn't know what to do). But I guess the best option would be to use the new Multimaterial for fake-ground. I didn't manage yet to experiment with this, but I for sure plan to. I imagine this could work very well for a "stones on grass" texture or something like that, where the stone-material has a pronounced normal-map (nohq).

I just assumed that because you're using tiled meshes instead of a heightmap terrain that you would have LOD models for them, if so, you could take a snapshot of the result from the mask texture on lod 1 and re-size it to 256x256 to be used for lod 2, you could set something up in say 3dsmax to do this sort of thing automatically.

Are there any particular types of environments that you have in mind for this system?

Edited November 25, 2009 by mikebart

[rübe 127]

I just assumed that because you're using tiled meshes instead of a heightmap terrain that you would have LOD models for them, if so, you could take a snapshot of the result from the mask texture on lod 1 and re-size it to 256x256 to be used for lod 2, you could set something up in say 3dsmax to do this sort of thing automatically.

I'm sorry but I don't get it at all. Why would I wanna mix(?) textures in 3dsmax(?) to manually render, uhm, mipmaps?! What am I missing? Do you mind to elaborate a little or send me to a resource I can read on?

some first multimaterial tests & findings

Anyway, I did some first multimaterial tests and it seems to be really perfect for terrain. But I stumpled upon weird behaviour in O2, or maybe I just don't really get it. You can look at some screenshots and read my findings here: some quick multimaterial tests & findings for fake terrain

Either way I'd really appreciate if someone who knows better could tell a bit more about multitextures (esp. in regard to the mentioned quirks in the document just linked).

But first I'm still primarly interested in a tip about how to stop the dancing-AI-on-fake-terrain... I don't really know what else I could try.. :(

Are there any particular types of environments that you have in mind for this system?

No, just the usual/generic stuff. Some rocks, some grass, some mud, sand... whatever.. Maybe I'll just end up drawing some custom masks, using textures already in Arma2.

Edited November 27, 2009 by ruebe

[mikebart 1]

I'm sorry but I don't get it at all. Why would I wanna mix(?) textures in 3dsmax(?) to manually render, uhm, mipmaps?! What am I missing? Do you mind to elaborate a little or send me to a resource I can read on?

Im sorry, that was a crap explanation, ill try again.

Have a look in for example: "buildings2\ca\buildings2\HouseBlocks\HouseBlock_B\Data", look at the b1*.paa's, "houseblock_b1_mlod_co.paa" is a complete render of; the result of "b1_mask.paa" _co maps and "b1_mc" combined.

So what im suggesting is that you could do a similar thing with your terrain tiles, with or without the _mc.paa, as a way of having a less expensive material on the more distant lods.

All I was saying about 3dsmax is that you could set up all the texture maps in a shader containing; the mask result and the _mc.paa and render the mlod texture, but come to think of it again, that might be much easier to set up in photoshop using an action script.

hope that was better :)

[rübe 127]

Ah yes, thanks. That makes perfect sense, though it looks like quite an effort to go this route. In the end, I don't think I need that elaborate terrain-textures for my goal (I only need to create horizontal terrain to build some stuff on top of it). At least not now (functionality comes first). A simple tiled texture with some clutter on top of is fine for a start.