4
$\begingroup$

I am looking for advice on how to handle a large terrain mesh that I am importing from an existing file format through a custom add-on I am writing. Currently, I import heights from a height map file and generate vertices, edges and faces to create a single grid plane mesh. Here is an example of how it looks:

enter image description here

I have a total of 202,800 vertices and the dimension of my mesh is 520x390. Each 5x5 vertices (4x4 faces) represents 1 "tile" in the original file format and contains a pair of blended 256x256 textures. It's at this point that I am unsure how to best proceed because the dimensions of my mesh give me a fairly high number of "tiles" -- 8112. So here is my question:

  • Should I add 8112 materials to the mesh to texture each group of faces that represent a tile? OR
  • Should I break my mesh into 8112 objects, each representing a tile? OR
  • Is there a completely better way to handle this that I am missing?

Thanks for taking a look.

EDIT Adding some more information as recommended my Duarte

The terrain comes from an old 3D game and right now my only objective is to be able to render the terrain with textures in blender and manipulate the content. I don't really have a preference for which render engine to use (is one better than the other? I am an entry-level blender user).

More technically, for each 4x4 face I want to:

  • Blend 3 textures (256x256)
  • Apply the new texture to those faces
  • Render the mesh with all faces textured

EDIT2

After sleeping on it and taking a new look at the problem I realized that I could trim the number of "tiles" from 8112 to 224. This was due to the fact that not each tile is unique and some of the textures are duplicated ("tiled"). I added 224 default materials to the mesh and memory usage was not too bad (707mb - untextured). Going to experiment with this and will report back if it turns out to be a good solution for me.

$\endgroup$
  • 2
    $\begingroup$ What is the purpose of this terrain? Rendering? Game Engine? What render engine will you be using? Have you considered procedural textures? Please edit your question and provide more details about what you are trying to achieve. $\endgroup$ – Duarte Farrajota Ramos Jun 5 '17 at 0:20
  • $\begingroup$ Not an answer to the question, but keeping a regular grid as the topology will use more vertices as some form of adaptive topology. Using the decimate modifier might help you bring the polygon count while maintaining the shape. $\endgroup$ – cegaton Jun 5 '17 at 2:20
  • $\begingroup$ related: blender.stackexchange.com/questions/42640/… and blender.stackexchange.com/questions/57943/… $\endgroup$ – cegaton Jun 5 '17 at 2:29
  • $\begingroup$ @cegaton The subdivision/multires modifiers do look interesting. I could see it being a good optimization, as long as I could generate the virtual geometry from a script. However, I'm still left with the question of how do I texture each "patch" of my grid without blowing up my blender. $\endgroup$ – lazypenguin Jun 5 '17 at 2:45
  • $\begingroup$ Oh just duplicate, decimate, create a normalmap from high to low, and you put one mat. $\endgroup$ – Yvain Jun 5 '17 at 10:35
0
$\begingroup$

I have since found a good solution for my problem. What I've done is break up the mesh into individual "chunks" and then applied a material to each to texture it. I discovered that Blender can handle that many objects and my perception otherwise was due to the script functions I was using. Here is some pseudo code for what worked for me with good performance (10-15 seconds to create 8112 5x5 objects with 25 faces each):

for chunk in chunks:
    mesh = bpy.data.meshes.new(str(chunk.name))
    mesh.from_pydata(chunk.vertices, chunk.edges, chunk.faces)

    obj = bpy.data.objects.new(obj+str(chunk.name), mesh)
    obj.location = (chunk.offset.x, chunk.offset.y, 0

    bpy.context.scene.objects.link(obj)

The key was to not use any operations in bpy.ops but to instead create and link the mesh/obj/scene for better performance. See here to understand details Python performance with Blender operators.

$\endgroup$
  • $\begingroup$ It is usually a win to avoid bpy.ops. $\endgroup$ – Mutant Bob Jul 14 '17 at 15:18

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.