Yep. You may do only half of the checks, because if A is a neighbour of B, then B is a neighbour of A too.
5 Likes
@hofk this should be in your gallery 
2 Likes
riiight clever.
You can do use that nested for loop for that:
for( let i = 0; i< array.length; i++)
for( let j = i+1; j < array.length; j++)
check(array[ i ],array[ j ] )
Awesome. And Iâm guessing it will only require a little math to designate each tile with a global longitude and latitude value, like the hexasphere project does?
Follow-up observation: I tried PavelBoytchevâs method and got it to run smoothly at about 57.000 tiles. But I also couldnât help myself, and went back with the hexasphere-project and got it to create 56.000 tiles, but this time I implemented BufferGeometryUtils.mergeGeometries and it ALSO runs very smoothly. Have I misunderstood the documentation? I thought mergeGeometries only gave a performance boost if all of the the geometries were the same. But they are not in this case. Each tile/hexagon is built with its own unique vertices, but it still runs great.
Youâre probably mixing up instancing and merging. Both help by reducing draw calls, which is often the main performance killer. Instancing is best when all tiles share the same geometry. Merging still helps even with unique geometries⌠it just combines everything into one buffer, so the GPU can handle it more efficiently. Performance depends on tons of factors (draw calls, triangle count, overdraw, transparency, refresh rate), so itâs not surprising that your 56k merged tiles still run great.
Assuming 4 triangles per hex.. thats 56000*4 which is like.. idk 200k triangles?
Most gpus can handle ~1 to 2 million triangles no problem.
(Intel UHD, older mobile GPUs, low-end AMD/NVIDIA)
Good gpus (RTX 3080+, Radeon RX 7000) can render like 10 to 20 million triangles.
So on a 3080 at 60hz you might be able to render 40 of your hex planets. 
How do you plan to work with individual plates after merging?
2 Likes
Thatâs the next problem and Iâm not sure I can. Thatâs why Iâm trying a bit of everythinf; to see what works best. I am going to see if the faceIndex I get from raycasting the merged mesh can somehow be used to identify the hexagon saved in the hexasphere object.
Not sure what can be done with materials and textures
Instancing will save you memory.
I highly recommend going with @PavelBoytchevâs implementation, itâs not only clever but also the most performant, with minimal code.
If you combine it with @agargaroâs instancedmesh2, youâll get control helpers over each tile plus out of the box raycasting along with high-performance utilities like frustum culling and LOD support.
For the textures, I suggest using a texture atlas. Hereâs a minimal demo showing a texture atlas implementation with InstancedMesh2, also thanks to @agargaro.
4 Likes
Yeah, that is the approach I have had the most progress with. However, the issue is more about looks:
Hexasphere.js
PavelBoytchevâs implementation
As you can see, the latter method does create some stretched and squished hexagons. Itâs not a deal breaker, but if I can get the hexasphere-mergeGeometries-method to work with materials and tile selection, that would be optimal.
1 Like
I am curious to see how you get such hexagons. Could you demonstrate it with a codepen?
Edit: not curious any more. Found how to generate such irregular shapes. Now curious to see whether they could be eliminated.
Most likely geometries are merged one after another, so you could pass all hexagons followed by pentagons. This would allow to easily calculate the tile based on face index (provided all hexagons are decomposed in the same number of triangles; and pentagons also in the same number of triangles). If you do not want to reorder, you can make one pass and collect info which triangle to which tile belongs.
As for materials, you could use multimaterials and groups; or texture atlas; or vertex colors (in case of just colors, no textures); or custom shader; or TSL. Not all approaches are equally feasible, it depends on your internal structures and what things you want to do.
Iâm somewhat jealous of the journey you have ahead of you.
1 Like
Yeah, it really is a fun endeavour. Iâm learning a lot
Also, I think I cracked tile picking: when I raycast, the intersect object returned contains the faceIndex. Multiply that by 3, and you can use that number to find the group in mesh.geometry.groups. The index of that group is the same as the index of tile in the hexasphere object, because the geometries where built in the same order as the tiles in the hexasphere object.
Edit: Map is now 56.252 hexagons
Edit: also managed to add indexed materials for the groups, so now world map painting is back (this is 11 different materials, which does make rendering a little slower than just 2 materials, simple green and blue). It runs surprisingly well:
3 Likes
Final step: texturing. As mentioned above, a texture atlas would make sense. Are there any perfomance issues to be aware of when using a texture atlas? Can I have just one single material for all tiles and just offset the texture for each tile, if it is a desert, ocean, mountain etc? Or does it have to be a material for each terrain type, but all materials are using the same texture?
1 Like
Using a texture atlas like that is a really good approach performance wise. The only downside is the texture filtering between tile types can sometimes show seams, but this can be avoided/improved by padding/dilating the tile textures.
Another option would be to use a texture array.. but I would go for an atlas if you donât mind the complexity of generating it, and the shader logic for tile lookup.
You could probably get away with a single material, and manipulating the roughness/metalness etc. in the shader. You may want an extra material if you want to do a transparent water layer.
2 Likes
Oh, I didnât know that had anything to do with shaders. Well, time to dive into that rabbit hole too 
Another possible shaderless approach with an atlas is just to set (and change when needed) the UVs of the vertices of tiles. For example, in the atlas you may have a large grass region and grass tiles may pick random pieces (turfs?) of that region. Thus you will get randomized grass tiles.
3 Likes
So I am playing around with the UV-mapping of merged geometries and it is sort of working, but only sort of:
The lighter tiles are not displaying the texture correctly. The color seems to come from the texture, but itâs not wrapping correctly, and I canât seem to figure out what the pattern means. I checked the UV attribute under the geometry, and as far as I can tell, the UV coordinates are correct. There are 675000 points in total, which should be correct: 12 pentagons with 5 2D-coordinates, and 56240 tiles with 6 2D-coordinates.
Another odd thing, is that so far I have NOT added UV mapping coordinates for the 12 pentagon tiles, but actually the single tile in the middle of the image where the areas meet is a pentagon, and for some reason it seems to get texture applied to it. Can anyone here figure out whatâs going on?
Edit: a strange observation: exactly half the tiles have correct textures and the other half does not. All tiles after index 28126 have the light, incorrect texturing, while all tiles before have the correct texturing; including my pentagons, which are index 0 to 11. Is there some kind of indexing error that might be messing with the UV attributes array?