Making a tileset

No, more complex than that. It can be tiles with more than one mesh in them. And the origin of the mesh wasn't the origin of the tile. And the meshes are more than just one quad, even for simple walls.I currently worked around my problem by joining meshes in blender and set the origin to the center of the tile. When there are only mesh instances the converter seems happy.The only thing I noticed is that I see a small gap between tiles, even though the size of the meshes in blender are perfectly filling the size of the tile. It looks like I have to make the mesh a tiny bit larger than the tile size.

Sorry for the delay. I'm still in middle of adding collision in my tileset.There are screenshots of the tiles I'm working on.[url=http://pix.toile-libre.org/?img=1466244784.png][img width=451 height=360]http://pix.toile-libre.org/upload/img/1466244784.png[/img][/url][url=http://pix.toile-libre.org/?img=1466244816.png][img width=480 height=330]http://pix.toile-libre.org/upload/img/1466244816.png[/img][/url]Note: those are assets from fps creator classic, opensourced and free to use in other projects (as long as we don't make packs from it).

Alright. I've more or less my tileset, with collisions working fine. For some reason, there's still a gap between tiles. But the big problem is that's very big in memory, with 300 objects. It takes 5 seconds or so to load. That's a bit too long. Is there some way to optimize this? And if I make a large map with this tileset, would it be extra big?

[quote author=Bishop link=topic=15617.msg16887#msg16887 date=1466862712]Maybe somehow set the LOD and divide the tilesets on the groups?[/quote]LOD would only help to render faster, and I think the gridmap doesn't handle that. The gridmap is very limited and accept only meshes+collision+navmesh.Leaves only to divide the tilesets.About the gap, I found my solution in Blender. It seems that Blender doesn't display properly very small numbers, like 2.00000000000001. And when it's a 3d Vector of a mesh, that makes a gap. But Python in Blender does see the difference. So I wrote a nifty little script to round the position of all vertices of all selected objects. And that fixed my problem.This script does assume the tiles are of a whole number size and the vertices at the border have coordinates with integer value (no decimal). Precision can be given for irregular borders, but it is only really effective for precision=0.[code]import bpyimport bmeshdef work1():    precision=0 # set the decimal precision you want. But do it for precision=0 too for the borders    C = bpy.context    if C.mode != 'OBJECT':        return    if len(C.selected_objects) < 1:        print("Must have at least one object selected")        return    selected_objects = [ o for o in bpy.context.scene.objects if o.select ]    for o in selected_objects:        bpy.ops.object.select_all(action='DESELECT')        if o.type != 'MESH':            continue                o.select=True        C.scene.objects.active=o        bpy.ops.object.mode_set(mode='EDIT')        bpy.ops.mesh.select_all(action='SELECT')        bm = bmesh.from_edit_mesh(bpy.context.active_object.data)        selected_verts = [vert for vert in bm.verts if vert.select]        for o in selected_verts:            #o.location[2]=round(o.location[2])            pos=o.co            for i in range(3):                dist=abs(pos[i]-round(pos[i],precision))                # all vertices                 if dist < 0.00001 and dist != 0:                    pos[i]=round(pos[i],precision)                        bpy.ops.object.mode_set(mode='OBJECT')    for o in selected_objects:        o.select=True    work1()[/code]