Technical support > Feature Requests

Damage buildings/wall by rockets and/or explosives

<< < (3/4) > >>

geever:
I know about two problems:
* lightning: The game mostly uses static lights and shadows, which are computed in map compiling time. By destroying the wall in game would the shadow would remain which is awful....
* pathfinding: Destroying objects may open new paths which are probably more optimal in some cases. Pathfinding maps are also compiled into the map (because it is a resource intensive task)

-geever

H-Hour:
BPRoberts: First, descructible terrain is not impossible, but implementing it would require a nearly complete rewrite of the 3D engine. This was the conclusion of Arisian, who investigated the matter a couple years ago and began working towards our implementation of dynamic lighting (a key step on the road).

However, even if the development team felt that destructible terrain was a key design goal -- none of us do -- it is a unique problem. Handling the generation and then modification of 3D terrain requires extraordinarily complex math. The people who do this stuff commercially are specialists, and the people who do this stuff for free can be counted on one hand (LordHavoc, the Ogre3D people?). We don't have anyone on the team with those capabilities.

The different explanations ("excuses" as you call them) point to different aspects of the problem and typically address why different proposed "solutions" won't work.

1. Q2 supports destruction: Yes, and UFO:AI supports the same destructable objects system used in Q2 (func_breakables). This can not be extended to all of the game geometry or even a large portion of it because the destructable objects are not handled efficiently enough for decent performance. This is not a matter of waiting a few seconds, but even with one or two dozen func_breakables can turn into a 30-45 second pause.

2. Who cares if it breaks lighting?: Lighting is not a minor graphical detail. I can't argue this point, you would just have to see it for yourself. Nothing looks more confusing to the eye than lighting that doesn't behave properly. Lighting is the foundation of visualizing 3D objects.

3. Just create new simple maps if needed: Our active mapping team is named ShipIt. He is the only active mapper on the project who has produced a map in the last year. This idea that we have mapping or modelling talent waiting for orders on what to make next is false. There is no community of people waiting to do time consuming, pain-in-the-ass jobs.

Sandro:
Guess I should clarify things a bit. Problem is, the idTech2 engine is based on the concept that all geometry is rigid. To the point that characters ("actors" in the idTech lingo) are actually represented by axis-aligned boxes; only renderer cares about actually presenting humanoid (or not) shapes of them.

And that is how it is handled in all game subsystems -- visibility, physics, pathfinding, etc...

So, with this engine you can move stuff around, rotate, make it appear or disappear (that's how func_breakable works), but you cannot have deformable surfaces without a complete rewrite of the engine. The only easy solution could be making some sort of cheap breakables.

H-Hour:

--- Quote from: Sandro on July 08, 2012, 07:49:42 pm ---And that is how it is handled in all game subsystems -- visibility, physics, pathfinding, etc...

--- End quote ---

So visibility checks the box, not the actual alien model? Is it the same for projectile collision?

Sandro:
Yes and yes.

Navigation

[0] Message Index

[#] Next page

[*] Previous page