Support MagicaVoxel world mode and material. That’s why I suggested using shadow specific copies of the mesh, since you don’t need the color data there, and thus no UVs or hard edged normals, you can ensure there are no seams.Download Now “If possible, please buy the package to support the developer”Ĭreate prefab from vox and qb file with optimized mesh. At some point some edges must be duplicated or worse if you have a change in color.
Magicavoxel environment to unity manual#
With some manual work you can roughly get the best of both worlds with a texture atlas by trying to merge as many of the seams as you can, but there’s only so much you can do. This has the benefit of not needing a UV seam on the corners and edges of geometry, assuming the voxel is a single color on all sides, but means a lot of additional geometry on flat faces. You’re saving vertex count on the flat faces if you have color changes at the cost of extra ones on the edge.Ī texture swatch is the opposite, just a list of colors in a texture. Texture atlases usually mean seams and doubled/tripled vertices on the hard edges. Generally vertex count wasn’t the issue we were running into, especially since we didn’t use any shadows, though we did have doubled vertex counts on all characters due to a shell outline, this was never the bottleneck.Īs for the solution to your problem, it’s just a matter of picking your poison. For some rare cases I hand unwrapped some objects.
Auto-uv in other applications or hand UVing by the artists usually resulted in UVs that weren’t pixel edge prefect and resulted blurry textures, so I outright nixed that. The vertex count can continue to be a problem, but you may be able to keep the framerate playable.įor our project UV Mapping was usually left as the base output from Qubicle, seams and all. You might also consider using a reduced resolution on mobile devices rather than trying to significantly change the rendering. Breaking meshes up into smaller chunks (like 32x32x32 voxels) rather than an entire mesh may help with frustum culling. Shadows were all faked with simple blob shadows.īeyond that it depends on how much you can see on screen.
For our project we baked the lighting into the meshes' texture atlases with an external application and they were rendered using an unlit shader. However the real answer may be using no shadows or baked lighting instead. You were already kind of thinking that way, but exporting a solid colored greedy mesh with welded vertices as an explicit shadowcaster mesh can do wonders here for reducing the vertex count. Step 3: Use different meshes for shadows. Using the MagicaVoxel style color swatch texture or vertex colors can end up being better here than using a texture atlas style. This also likely won't get you as much as you might hope as the vertices may have already been split by UVs when using a texture atlas. However this requires GLES 3.0 or better, so if you're targeting GLES 2.0 devices, you're out of luck. However you may be able to get rid of some extra vertices by not using hard edges in the mesh to do the flat shading. If you have a lot of very detailed geometry (like the gravel under those tracks) then you're paying the cost of the high polycount no matter what even with the above optimization.
Step 2: The above can solve many of the polycount problems, but not all. This tool on the asset store appears to do something similar letting you directly import MagicaVoxel files: Qubicle outputs much cleaner meshes, and is what we used. MagicaVoxel for instance outputs just a color swatch texture and relatively high polygon meshes if you use a lot of color variation, and that can be brutal for vertex counts. Step 1: Use voxel tool that can output a greedy mesh and texture atlas, not just vertex colors or per-color indices. Having done a voxel based game for mobile VR not too long ago I went through a lot of this already.
0 kommentar(er)
