-1
\$\begingroup\$

Lets say my engine supports a "Model" with a position in the world, hitbox and the data to paint in the render method. Should an open world map be a "Model"? How do I render only part of it in order to increase performance? How do I implement only "local" collisions, again, performance-wise. Logically, it seems different than a normal "Model", I just cannot figure out how.

Bottom line: How's terrain rendering and physics different than "normal" rendering and physics?

Some technical information: I am using OpenGL with GLFW using C++.

\$\endgroup\$
  • 3
    \$\begingroup\$ Think of it this way: if you're only doing rendering and physics with a part of the world at a time, do you even need the other parts in memory? So then, why even consider them to be part of the same model? The player needs to believe that it's one continuous world, but that doesn't mean the game code needs to believe all parts of the world are "really" one big mesh. It looks to me like you should do a bit more research on terrain systems. Very quickly you'll encounter discussion of "chunk" based streaming and LoD systems that chop maps into pieces. \$\endgroup\$ – DMGregory Jun 26 '17 at 20:09
  • \$\begingroup\$ There are many aspects to this, like frustum culling, LOD rendering, dynamic terrain streaming, comparisons of different kinds of spatial data structures, etc., etc. One could write an entire essay about each of them. I'm sorry, but your question is too broad. Please pick one problem and ask about it specifically. \$\endgroup\$ – Philipp Jun 26 '17 at 21:46
1
\$\begingroup\$

On the one side, it isn't different. On the other, it is.

Models typically use bounding volumes (e.g. boxes) for collision detection, and only the really important stuff gets mesh-accurate collision detection.

Models are typically loaded into memory fully. You either need them or don't.

Terrain on the other hand isn't needed completely. You only need parts of it, commonly refered to as chunks. Those chunks could be individual models, but more often then not they aren't.

Terrain needs LOD, and with LOD comes stitching problems. So chunks need to be aware of their LOD state and the LOD state of the neighbouring chunks - a common solution is using quad trees for terrain.

Moreover, collision detection against terrain can often be simplified. If your terrain does not have holes but is derived from a height map, you can greatly simply collision detection by only checking the height of the bottom vertices of your chracaters bounding volume against the hight of the terrain at that point.

You will want to have your terrain in a data structure that supports frustum culling and potentially caching / paging (if a player goes back and forth a lot).

All in all, terrain is vastly different from normal models due to its sheer size. But at the end of the day, your piece of terrain is just a mesh with a shader and a few textures, just like any other model, too. So not so different after all.

You need to ask yourself what your terrain - for your game - has to be able to do. And then support that.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.