• Advertisement

Archived

This topic is now archived and is closed to further replies.

Deformable Worlds

This topic is 5498 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Something i''ve always wanted to do is have deformable worlds. One thing that has always annoyed me in games is that you either can''t blow something up, or when you do, it spawns some debris wich dissapears shortly. When I go on a rampage of wanton destruction I expect to see the results of that rage when I''m finished. I want to see debris and blast craters. I want charred remains of various objects once former selves adorning the area. This poses some technical challenges. Making entity class objects deformable is fairly simple. They''re meshes to begin with so chopping is simple. Making the World deformable is tricky. With a deformable world alot of the old tricks for handling levels need to be either modified or tossed out. Anything that is pre-computed has no garuntee that it will stay valid as the game progresses. Lets take VIS for example. VIS usually is a list of all potentially visible nodes of the partioning tree from the current node. Now lets suppose that we have two areas completely seperated by a solid object. Vis would say that the other side of the object is not visible. Now lets use a standard issue Big Gun and blow a hole in said solid object. The other area should be visible, but VIS says it isn''t. Doh. So what other options are there to accomplish what vis does, but be adaptible to geometry being removed/relocated? My original idea was to use an octree to split up the world, then generate a list of posibly visible nodes for each node. But this suffers the problem mentioned before. Without vis the only geometry removal I can think of is tossing octree nodes that are out of the players field of view, but that could still leave alot of geometry to render. Another issue arrises with removal of geometry. Most of my maps I want to be outdoor city scapes. This means that it would be possible to destroy the supporting section of a building. In order for the game to accurately make things fall, it needs to know what parts of geometry are single solid sections and where the force points of support are. This could probably be overcome with the use of hint style brushes that let the map compiler know whatever is in the hint brush(es) are a single object. However, the game still has to figure out how to make it fall. If a multiplayer option is pursued, this adds another issue. There would be a definite need for people to be able to enter and leave a server running a map at will. If the map is deformable then all new players need to have there maps updated to bring them up to speed. This could be accomplished by the server keeping track of all map changes as time progresses, and then when a person joins these smnall deform packets are sent. However, if a map''s been going awhile this could be alot of packets... Another issue that is beyond the scope of this rant/question is lighting. Lighting could be solved by using a completely dynamic lighting system. However that is computationally expensive, and a whole nother discussion. So, Any suggestions or ideas that I should pursue? Or maybe i''m just insane and should abandon this idea completely. I know that the Game Red Faction does this. Something called GeoMod. I have no idea how they do it, I just know they do. -Zims

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
X-COM (made in 1994) probably had the most completely deformable terrain, also check www.lasersquadnemesis.com which is a modern game made by the same people, has deformable terrain and is multiplayer.

Share this post


Link to post
Share on other sites
I took a look at laserquadnemisis. Unless i''m mistaken this looks like a tile based game. Deforming terrain in a tile based game seems like it would be easy.

What I''m trying to do is deform a 3d world with a first person perspective.

This poses alot of problems, hence my distress.

-Zims

Share this post


Link to post
Share on other sites
I made a java scorched-earth clone a LOOOOONG time ago, and it kept an internal list of "blastzones". Everytime a bullet hit the geometry, it added a "blastzone" to a list, and used these to draw the new terrain.

Anyway, you could use this to store your blastzones in a list, send that list over on connect, and enjoy the ride. A blastzone is no more than a 3D coordinate and a radius. You can have the client side interpret these blastzones and update the map on the client side, but it''s nescesary for each client to use the same algorithm for deforming the landscape, else people will get different results. Ofcourse, you can have some randomness in your display, but not in your geometry.
Such a list of four numbers per item shouldn''t be THAT large, assuming that you don''t play your map for hours, and hours, and hours...........

As for the visibility thing, again you could use the blastzones for that. If the blast occurs in one part of the octree, you can itterate through the tree and see if this node was visible. If it was, you do some raytracing and update the list and add the nodes that have become visible after the blast.

You WILL have to make a choice though, of how precise you want your geometry to be shaped to damage. If you are going to reshape it for every bullet, you will be stuck with a HUGE list of blastzones in multiplayer, and with a huge overhead of raytracing in singleplayer, but if you choose to only reshape it for large blasts from rocketlaunchers and cannons, this might work.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
..and I want your source.

Share this post


Link to post
Share on other sites
My Engine handles deformable terrain as follows: If your terrain Engine, like mine, never has polygons ontop of eachother just use a Quadtree. You dont have to recalculate it, since changing the height wont put the verts in a different Node. Now if your terrain like most terrains doesn''t have any transparency such as alphablending just draw it last at all times.
This is what my latest game does with its deformable terrain.
So all the height changes and volcanoe craters are still there after playing(its on my website under (programming(geocannons), if your interested).

-CProgrammer
My Website http://atumotu.shorturl.com

Share this post


Link to post
Share on other sites
You could try creating small structures (that could be blown up) as entities. You could do an oct-tree or PVS for just those small buildings, and use it to "guess" at what is visible. You could also try portal based rendering, and just rotate portals/add new portals as the world is deformed. (i.e. a new portal is added whenever a rocket launcher blast a hole in the wall, and the portals are translated just like real polygons when the building falls over) You would probably have to put in quite a bit of extra code to handle that, but it might be worth a try

Share this post


Link to post
Share on other sites
Modern 3D cards dont require as much culling as before. Plus with an octree, there are many many nodes in a large map, which could lead to a way huge vis list in each node (which would be painful to properly recompile at run-time).

Imo octrees do well at dynamic indoor/outdoor areas. You can get away with just frustum culling. I dont think you should go with quadtrees because in a city scape you can have high buildings with many floors, and an octree would help with that.

When you modify an octree, you dont even have to remove nodes, unless, of course, there are no polygons in that node anymore (nodes at the top of a collapsed building, which you can safely remove once they are empty). My point is, you dont need the culling to be perfect with a GeForce 3... You can use CPU power for better purposes like actually moving those polygons when things collapse.

Unless your engine is totally based on meta balls and is a very realistic physics simulation system, you''re going to need to specify keypoints on where the weaknesses of the buildings are.

As for networking... Its either you download the significant changes (you dont have to store em all), or you download the whole polygon list on joining.

Share this post


Link to post
Share on other sites
Re-raytracing to generate new vis information, while still computationally expensive, may be possible.

If we make a few assumptions we can cut back on the amount of calculation required.

First, when testing for vis, only the edge faces of the nodes need to be tested against each other. If there is a path from one point on the edge surface of the source node to a point on the edge surface of the destination node then the two nodes can see each other.

Any node that can already be seen doesn''t have to be part of a new calculation.

Then, the only nodes that need to re-calculate are ones that can see the effected node. If it couldn''t see the node to begin with, then it shouldn''t be able to see through anything in it.

An Idea to optimize this at the expense of the map using more memory to store is instead of having a list of only visible nodes, make it a list of all nodes. If the node is visible, put a 0 into that index. If the node is not visible put the index of the node that blocked the trace into the list. Then the only nodes that need to perform new ray-tracing are nodes that had there vision blocked by the effected node.

Depending on how small the nodes become this could be a very large list, and every node needs one.

Another option is instead of having a big list, have two lists. Nodes I can see, and Nodes whose vision I blocked.

Since TraceRoutes would be a common thing needed for general use by the game this func should already be optimized and take advantage of the tree.

Another thing is this doesn''t account for moving geometry. If we ignore the fact that something that was visible may no longer be visible, then falling geometry would be dealt with just like geometry that was removed.

The more the map changes the more geometry becomes visible, on the other hand geometry is also being removed so....

Then again, frustrum culling as has been suggested may be efficient enough to not even need VIS.

Gotta get more code written so I can test these methods. Right now it just renders everything....

-Zims

Share this post


Link to post
Share on other sites
Since I am a bezier person, I''d rather go for bezier patch terrain. It is so easy to change control points for a patch and recompute it, so I won''t be talking about that process. What is more important is that you can use those patches even in quadtree visibility algo or almost any other.
Try it. Make it. You will love it.



Or not.

" Do we need us? "


Ionware Productions - Games and Game Tools Development

Share this post


Link to post
Share on other sites
A question is whether your going to have new vertices for all the damaged places or will you just change multitextured textures on the terrain and change heights? In case you are doing the first one i would have a check every frame checking whether frame rate dropped under 30FPS. If this is the case delete old damaged areas. I know this is what your trying to avoid but if you dont then the slower computers will begin to have a disadvantage in a network game over time. So if this game is to be network played, try to make the damaged areas a ''chrome''feature, meaning not necessary to play the game or slower computers cant join.
If your thinking of adding things like movement speed is decreased on debree this may cause a problem in a multiplayer game cause you will never be able to delete damage causing a major speed drop over time.

Just some thoughts.
-CProgrammer
My Website

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
You haughty fortune cookie! What is that you are displaying? I have not seen the likes of that cloud anywhere in the sky! Where will I find my dish detergent if I can not approbate my degenerating DNA structure?
End Transmission! (_|_)

Share this post


Link to post
Share on other sites
It''s apparent I haven''t been to clear about certain details of my engine in it''s current state, so to alieviate confusion Here are some more specific details.

The maps are not terrain, they''re made in GTKRadiant. Most of the maps I have in mind are city-scapes, but anything is really possible. The gameplay is a ship flying through these maps fighting other ships. Basically dog fighting.

As for Bezier Patches. I imagine that in the future I will implement some form of that as I think it''s a good way to add detail that is dynamic. But at the moment I don''t think they will help with deformation.

Another thing that needs some consideration. How should the Verts be stored for use in Direct3D. As of now they are in one giant Vertex Buffer, and all the indicies are also in one giant index buffer. Since I intend to deform the world, I will be adding and removing verticies. If all the verts are in a giant list then modifying that list becomes expensive. If they are in small lists then vertex buffers need to be switched more often, which also incurr''s a penalty. I wonder which will prove most efficient overall.

-Zims

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
I love playing red faction, and it has very nice deformation with its geo mod technology, i wonder if there is a resource on how its done in that game?

Share this post


Link to post
Share on other sites
If you want to make a proper deformable world, visibility culling is the least of your problems!



Read about my game, project #1
NEW (18th December)2 new screenshots, one from the engine and one from the level editor



John 3:16

Share this post


Link to post
Share on other sites
quote:
Original post by d000hg
If you want to make a proper deformable world, visibility culling is the least of your problems!


I would say that''s the main problem.
IMHO Red Faction uses BSP tree merging for its CSG operations, but how do they handle a destroyed portal or the recompution of a precalculated PVS ...
What''s left is dynamic culling which is costly

Share this post


Link to post
Share on other sites

  • Advertisement