Closed deathcap closed 10 years ago
mikolalysenko
commented
10 years ago One option could be to compress the normal format, since we really only need one byte there if even that much, and then return a pair of bytes for the texture id. That way each vertex would still be 8 bytes, and it would also free up an extra byte for other purposes, maybe storing some displacement or separate "sun light" channel for day/night transitions.
deathcap
commented
10 years ago Well, the normal should be representable with 3-trits ≈ 5-bits, at least, or 6-bits in a more easily-decodable format, leaving 26-27 bits for the texture index or other data.
Something I'd also like stored in the voxel format is the texture size, so some textures can be of higher resolution than others (vs the tileSize uniform which applies to everything), parity with voxel-texture and for mixing textures from different texture packs. Shouldn't take more than a few bits since the size is always a power of two (maybe at most 2^10).
Curious if increasing the voxel format would be worth it, if the memory/performance implications would be noticeable. With another (vec4?) attribute attrib2 we might have plenty of space, for a 16-bit texture ID, (4-bit?) texture size, displacement (for bump maps?), lighting (4-bits or more?), etc. Also non-cube block models (some notes in https://github.com/deathcap/voxel-ideas/issues/3) might require more data, not sure how to handle those.
mikolalysenko
commented
10 years ago I think non-cube objects could be handled separately, since it doesn't make any sense to try merging them using greedy meshing or otherwise. What the mesher could do is flag those voxels, and add them to a separate mesh.
I think that realistically to get the things you want working would require a massive overhaul of the interface to ao-mesher, so perhaps it might be better to just fork the project and build a separate module.
As a sketch of what features would need to be added:
Alternatively, if it makes more sense to put decorations in the mesh it could be better to change the vertex format to something which allows for full 32 bit positions. Then the mesher could copy these objects into the vertex stream when it encounters them at the appropriate location.
deathcap
commented
10 years ago I think that realistically to get the things you want working would require a massive overhaul of the interface to ao-mesher, so perhaps it might be better to just fork the project and build a separate module.
Alright I've forked ao-mesher and ao-shader to voxel-mesher and voxel-shader, will see what I can do with the voxel format (hope you might be able to help, I could use it :)), I've have at least the 16-bit texture IDs working, after packing the normal into 6 bits.
Some way to customize or specify the per-face texture coordinates
Hm, do you mean something different from https://github.com/mikolalysenko/ao-mesher/pull/1?
The ability to emit multiple meshes, one for transparent faces and one for solid voxels, and possibly one for non-cube voxels/decorations
Sounds like a good idea, I suppose this is where front-to-back sorting would come in (ref https://github.com/mikolalysenko/ao-shader/pull/3).
For the non-cubic voxels, some might require the flexibility of completely custom renderers, but I think most could be separated into a few categories. Blocks of different heights (slabs) - the side would be transparent up to a certain height + the top face shifted downward; flat billboards (most plants); double-crossed billboards at right angles (fire — two textures. maybe tex_id, tex_id+1), etc.
Running into the limits of the voxel format
tex_id(8-bit, only enough for a 512x512 atlas with 16x16 tiles, trying to increase the atlas size), would it be possible to increase it to at least 16-bits?Not sure of the best way to do this, since the current format is 8-byte (attrib0 x,y,z,ao and attrib1 nx,ny,nz,tex_id). 9 bytes per voxel might be an unusual length.. could the other fields be compressed? (the normal vector maybe? if it is only 127-129, seems a few bits would suffice)