CubeMeshBuilder fallback to extra triangles
XeonG opened this issue · comments
..I know you said something about replace w, h with 1.. however my attempt at trying to fix this in CubeMeshBuilder has not gone well...
... seem to get more missing faces than anything :) though the faces that are drawn the textures are right.
Could you maybe add another compiler conditional for it or provide an edited CubeMeshBuilder we can swap in to fall back to having the extra triangles per face that won't need the shader to have the block textures drawn correctly repeated on surfaces.
Think maybe having this might provide some other benefit for exporting out the geometry and using it another 3d app, where fixing the currently optimized face geometry would be harder to do than just having all the extra triangles and applying the same block textures to recreate things in another 3d package for cinematics or whatever.
Yeah, well looking at the code I realized I've changed a lot more than I rememered. So what you need to do is comment out the entire body of the for loops in the Build method of MergedFacesMeshBuilder.cs so that it looks like:
for (int y = 0; y<Env.ChunkSize; ++y)
for (int z = 0; z<Env.ChunkSize; ++z)
for (int x = 0; x<Env.ChunkSize; ++x)
{
BuildBox(chunk, x, y, z, x+1, y+1, z+1);
}
Although it's still going to be slower then the old implementation because there are some extra checks inside BuildBox now (not to mention colliders use this code to build their meshes as well, thus they won' have merged faces anymore).
However, this should make it rather easy for you to change to code to your liking.
Thanks that works I adjusted it so that the colliders still use the newer code, and then I have an option to force mesh generation to use the above or the newer code aswel.. at least I can see the textures better for testing purposes when I need and don't have to go back to the much older voxel build I was using.
Using this workaround is pretty slow though :( not sure if I should go back to the older build I was using before for my project, if I knew you might have the shader to use in a month then this workaround is fine but if you know it might be longer could you say, as right now the older build is bit more stable as far performance and visuals go. And also the callback thing didn't work out as much as a I hoped.. I'll post a newer issue for that tomorrow.
Using this workaround is pretty slow though :(
Use the w=1, h=1 trick to speed it up a bit. It will save 32 * 32 * 6 iterations per block + gets rid of some checks in those loops...
Or simply copy&paste the code from older revisions and simply adjust the mask calculation parts so that AO and multiple materials are supported. It won't take you more than a few minutes.
more stable as far performance and visuals go.
If you compare it with performance of this crippled down version then yes :)
I knew you might have the shader to use in a month then this workaround is fine
Maybe, I don't know when I get to it. However, it might be rather soon given this is one of the two issues I currently know of that I would like to sorted out before 0.1 is done.
And also the callback thing didn't work out as much as a I hoped.. I'll post a newer issue for that tomorrow.
I assume you mean fallback? Anyway, I don't know what kind of issue you face but if it's about this workaround that I suggested then don't create a new issue. But honestly. I don't feel like supporting something that's not in my repository right now. It's not like I earn any money on Voxel(metric) (not yet at least :) ) and my free time is limited. I'd rather spend it working on my code than solving someone else's custom code issues...
However, I'll wait for what you come up with and we'll see what can be done about it.
Use the w=1, h=1 trick to speed it up a bit. It will save 32 * 32 * 6 iterations per block + gets rid of some checks in those loops...
Or simply copy&paste the code from older revisions and simply adjust the mask calculation parts so that AO and multiple materials are supported. It won't take you more than a few minutes.
you make it sound easy :) I have no idea which part you're talking about.. I assume CubeMeshBuilder.cs , but w and h are used a lot throughout and I haven't been able to figure out which specific areas to be setting w=1, h=1, let alone adjust the mask stuff.. see this is why project needs someone like you taking care of the engine part. I do think you could charge for voxelmetric, though I hope you keep it low/affordable like cheap early buyers then increase as dev continues. Though I also think if it helps make a game a success then licensing also works. I've tried a few voxel solutions and this one seems the most promising open sourced version, the paid versions seem to all head towards smooth voxels (which would be great if they had 7dtd like block structure aswel and good smooth terrain). The cubed voxel ones either lack features or performance or both, voxelmetric is like the glimmer of hope but its been a slow ride.
I've been messing around with it for a over a year, even built a worldedit/worldedit gui like system on top of it, though multiplayer stuff seems to be a whole nuther issue. So I do have interest in seeing it continue to improve.
As for performance I can't really do a direct comparison with the old build I was using in game... ended up breaking a few things(game was using voxelmetrics object pooling that broke when I changed the scripts, but I been meaning to use something separate so not tied to that in the future) so until I fix that I can't do a better comparison, just seemed that way. I was getting extra gc, spikes on things and I can't be sure if its newer changes or just not a fair comparison, as the default example voxelmetric scene does seem faster, but with a lot of mesh/collider regenerating I'm not so sure.
And I did mean the callback thing.. with the setblock calling another function when it had 'finished' and a subsequent getblock check on affected block should return updated result.. so floating blocks for a structure are detected and broken off.. the annoying thing is I can't be sure if its my own implementation that has a few bugs or if the delay in getblock picking up old info.. anyway you say you might do the shader soon so I will properly update the game again and stay with the latest codebase, might have video to show of the issue, it seems to be 2 issues now when before it was only 1.. the new issue is blocks that are removed, the geometry generation (at least assuming its voxelmetric) is leaving some blocks behind when they should be air... and a second input of setblock, those same blocks are then removed.. been really annoying bottleneck to figure out but yeah it could be my own code.
I added the fallback - 98324bd
As the description states, change your s_cubeMeshBuilder to CubeMeshBuilderNaive to use it.
works nice thanks for adding it