ruebe
Nov 22 2009, 14:06
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?
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?