Jump to content
  • Advertisement

Archived

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

Zimans

Deformable Worlds

This topic is 5731 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

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!