Destructible Terrain

[Spokesperson 0]

I think BIS talked about destructible terrain early in their development but later abandoned it. It seems like it's hard to implement. But why?

They could just add a 1/0-destroyed flag to every polygon, which is set to 1 when destroyed. Then erase it and spawn a multi-scale hole model to cover up for the gap. Filling user-made holes would be easy too.

Then people could dig themselves or their tanks in, which is essential to any kind of warfare.

[bravo 6 0]

BIS didn't talk about it, we did, the community suggested some years ago and asked for it. In fact i remember to create a thread mentioning this and giving some examples on how the terrain modification were in other engines.

The idea was pleasant for all but seemed to be difficult to apply in ArmA engine.

About your suggestion I think it would be too complex and impossible (is engine is the same) if you ask me.

When you build a terrain in visitor then you have to binarize it and you can not change the original map if you don't have the .pew file. Meaning you can not modify the original terrain like you said.

I know what you mean and it would be cool if we could have such, but i just think its impossible with the engine we have in ArmA. Maybe ArmA2 engine is different.. maybe they found a way to do it.. who knows?

[EricM 0]

Actually the feature looks already doable to some extent (VBS2), but with a large grid size on the terrain the effect is hardly noticable and worthwile.

At least in the video I saw posted.

[.kju 3245]

While it is not fully what you expect, you are also not aware

of the limitations and challenges (AI, performance), check

Dynamic Terrain by Spooner and Deanosbeano:

AH: Loki´s nightmare pack thread

[Spokesperson 0]

I don't think .pew should be a problem as you don't modify the original file. The terrain is displayed on screen, so it has to be loaded. Then after it has been loaded you modify what you see on screen. You locate some polygons and delete them. You can save changes to some other separate location and read both when loaded again. I can't see performance as a problem there.

Dynamic Terrain is the real thing (Sim City) but I guess it's harder to make it like that.

[bravo 6 0]

Sounds interesting, would it work in mp?

[bravo 6 0]

here the recent example for ArmA:

[NoRailgunner 0]

This video doesnt show how objects and units and gameplay are affected. It shows only that (flat) terrain can be deformed. Its really exciting + great if such "design studies" would become real useable ingame for all ArmA fans.

[bravo 6 0]

i forgot to mention the source:

Link to source

Edit: Well its a start.. maybe BIS can use this as inspiration (if not already implemented such) and create similar with more naturalism.

[Pyronick 21]

I think it's better to wait when GPGPU technology and fiberchannel internet is widely used before BIS will implement such sophisticated hardware and broadband demanding physics engines.

This would generate so much thread time that you'd need at least like a Core i7 975 or sth and still run ArmA 2 on it's highest settings possible.

Not to mention at least 20 Mbps internet to sync all this with the game server and other computer.

[Commando84 0]

aw man I wish they would inplement it even if they would have to limit it to not being able to make as deep as holes you want or so, but it would still be cool if mortars and bombs and missiles and tank shells could mess up the terrain like Loki's projekt thingy  

Maybe there is to little time for it to get put in the game now but maybe in a patch or expansion pack ...

[Pyronick 21]

aw man I wish they would inplement it even if they would have to limit it to not being able to make as deep as holes you want or so, but it would still be cool if mortars and bombs and missiles and tank shells could mess up the terrain like Loki's projekt thingy  

Maybe there is to little time for it to get put in the game now but maybe in a patch or expansion pack ...

It could be added in a future patch, but all it does is cut the community in half like what happend in Crysis with seperate DX9 and DX10 servers.

We should be happy that Armed Assault 2 only works from Shader Model 3.0 and up, because that gives us loads of features that simply weren't possible.

The problem is that we are stuck on old DSL-lines from 10 years ago which have been optimized to the theoretical bar of 20 Mbps which isn't anywhere near fully achieved.

What needs to happen is that all big urban spaces go 20+ Mbps fiberglass, which is direct, very broad and does not hop from node to node to node to proxyserver before it actually reaches the internet.

This will increase the speed of older DSL/cable lines too, if the nodes are hooked up with a fibreglass connection and they don't suffer from package hops sent by other users because they already are on the fiberchannel.

Anyway, back to the topic. Destructible terrain isn't going to happen, even I can tell you that. Especially on the multiplayer part.

[Lepardi 0]

I think it's better to wait when GPGPU technology and fiberchannel internet is widely used before BIS will implement such sophisticated hardware and broadband demanding physics engines.

This would generate so much thread time that you'd need at least like a Core i7 975 or sth and still run ArmA 2 on it's highest settings possible.

Not to mention at least 20 Mbps internet to sync all this with the game server and other computer.

Works fine on Battlefield Bad Company and Söldner already, so what are you going to wait for when it's been possible for years already?

[Spooner 0]

Thanks for the interest! Remember that DynamicTerrain is an early WIP and the current videos are tech demonstrations rather than indicative of the final product.

I don't think that the MP issues are as bad as you think. You only need to sync changes in terrain and move some objects when appropriate. Maybe not appropriate for 100 player servers, but possible, I think, on normal usage (and remember that in most missions, there aren't bombs going off and players digging holes continually!

Static objects would still be static rather than becoming full physics object, but they'd be manually positioned to follow changes in the underlying terrain. Yes, you could have full physics everywhere to make everything work perfectly, which would kill any current machine, but gaming is full of compromises (i.e. should we have waited for 3D games until real-time raytracing was available?)

This video doesnt show how objects and units and gameplay are affected. It shows only that (flat) terrain can be deformed.

The video intentionally doesn't show off how static objects are affected because that isn't implemented yet, due to the difficulties involved in working out how they should be affected (they just stay in position). Physics objects are pushed up and down by the terrain as it moves, as long as it doesn't move too fast, so that isn't such a problem.

Remember that the videos are just for WIP tests, so you should think about what they do show, rather than what they don't show.

@ericM

We will be using 5m terrain grid for DynamicTerrain (the videos mainly show 10m grids so far, which is the same as Sahrani uses). We think 5m is the best compromise of performance and visual effect and can create reasonable deformations. 10m grid is fine for overall terrain shaping, but it definitely doesn't create anything useful for trenches or reasonably sized craters.

[Raphier 0]

http://www.bistudio.com/developers-blog/arma-2-building-destruction_en.html

Come on people, read the blog. Gives an insight why it won't be there and why will, to some extend.

[Spokesperson 0]

I don't think it would increase server load much. You only have to specify the hole depth, radius, and coordinates (3 x 4 bytes). That's 20 bytes, loaded once. This text message is a lot bigger.

[MehMan 0]

Then you need to check if there's a building there, if it is sink or destroy it, then if there are bodies there they have to be in the hole, if there's a tree it needs to be in the hole. It's extra traffic in an already traffic intensive game. Connecting to an evo server would take even longer.

[Spokesperson 0]

Those checks are client side. There's a bullet-hole texture already that contains most information needed for this hole-making. The only information that isn't there is the depth, and that's 4-8 bytes more.

[MehMan 0]

Considering that it has to be passed to all the clients it's server side too. And it effects AI, AI is managed server side, so it's server side.

[Spokesperson 0]

Of course the information about the potential hole location is server side just like anything else, like chat messages. But the deciding and hole creating checks should be client side. You don't have to send 500 coordinates when you can send 1 and let clients generate the 500 coords themselves.

Server load will be increased, but far less than the chat-load.

AI vehicles would have to avoid holes, yes, but it's like avoiding buildings. The code already exists and doesn't increase load more than standard AI procedure.

[Commando84 0]

what will a.i do if they are surroundead by holes? get stuck or try driving anyways?

[bravo 6 0]

well if vehicles can't move for some specific reason, why not leave the vehicle and walk instead?

But of course it should depend on the situation threat.

[Spokesperson 0]

what will a.i do if they are surroundead by holes? get stuck or try driving anyways?  

What will AI do when surrounded by houses? I don't know.

[NeMeSiS 11]

what will a.i do if they are surroundead by holes? get stuck or try driving anyways?  

What will AI do when surrounded by houses? I don't know.

Have you ever walked through a city and suddenly found yourself surrounded by houses without a way to get out?

EDIT: Imagine a youtube link to the monty python scene with the sailing office here.

[Spokesperson 0]

If I walk into Corazol or any similar city I'm surrounded by houses. The AI has to find the best way out, just like when crossing a river. If all ways are equally bad and it has to move, it could just go right forward. I don't think that's a problem either.

Everything is very possible to make.