Static mesh as terrain?

[Honas]

Hey there folks,
I recently came to the conclusion that a heightmap-based terrain may not be a good solution for a "Jump n' Run"-game.
So I tried to sculpt and texture paint a terrain in Blender, which works well. And I can see it in OgreMeshy after exporting and converting. Great. But:
Is it performance-wise OK to use a giant mesh for my level? Will there be enough culling?

http://www.ogre3d.org/tikiwiki/tiki-ind ... rain+Howto
refers to the octree scene manager. So, I will assume that some culling is going on, if you use it. But is it enough?
My level size will not be that big, think of a N64 "Jump n' Run" level area.

[bstone]

There will be no culling. That is either the whole mesh is visible or none of it. If you want to cull areas of your "terrain" then split it into smaller parts (meshes). That way the parts that are off screen will not be rendered.

[Honas]

Thanks for your answer, bstone!
So I would have to cut my mesh afterwards into different objects in Blender?
Is there maybe another way to do what I want?

[bstone]

Yes, just decompose it into chunks based on a 2d grid if you will. Just don't batch them together into a single static geometry instance because that will effectively group them back together again.

[lingfors]

Afaik, static geometry will split up your mesh in several regions and cull those regions separately.

[bstone]

I doesn't split the geometry but it groups all attached entities into separate batches by their proximity and size which is quite different from splitting geometry.

[Honas]

Alright, thank you guys. I've got a follow-up question:

Is raycasting to the polygonal level of my (big-ass terrain) mesh the way to go?
Like placing a vector that points straight down (because gravity) at my figure to get a y-coordinate? Or is there a better way that I overlooked?

[duststorm]

Is raycasting to the polygonal level of my (big-ass terrain) mesh the way to go?

That's the brute force approach. It depends on how your terrain is structured whether you can increase performance.

I'm thinking something along the lines of:
- Instead of bounding box tests, if your terrain is split in equal-size chunks ordered in a uniform axis-aligned grid, you can determine the correct terrain chunk for a position in O(1)
- When you know the correct chunk, you don't have to do a brute force test on all triangles if the vertices of the terrain are uniformly distributed along the axes (like is the case with most terrain meshes generated from heightmaps). Again you can determine the correct triangle in O(1).

So, it depends on your data structure. The technique you suggested is basically the worst-case scenario.