From 0cd5465f5216a2c5fc8b2be3a0fe4a2fbdca907b Mon Sep 17 00:00:00 2001 From: Sean Barrett Date: Thu, 12 Mar 2015 00:00:10 -0700 Subject: [PATCH] re-add README.md that was in a different branch --- tests/caveview/README.md | 75 ++++++++++++++++++++++++++++++++++++ tests/caveview/cave_render.c | 75 ------------------------------------ 2 files changed, 75 insertions(+), 75 deletions(-) create mode 100644 tests/caveview/README.md diff --git a/tests/caveview/README.md b/tests/caveview/README.md new file mode 100644 index 0000000..798f8b0 --- /dev/null +++ b/tests/caveview/README.md @@ -0,0 +1,75 @@ +# FAQ + +### How accurate is this as a Minecraft viewer? + +Not very. Many Minecraft blocks are not handled correctly: + +* No redstone, rails, or other "flat" blocks +* No signs, doors, fences, carpets, or other complicated geometry +* Stairs are turned into ramps +* Upper slabs turn into lower slabs +* Only one wood type +* Colored glass becomes regular glass +* Glass panes become glass blocks +* Water level is incorrect +* No biome coloration +* Cactus is not shrunk, shows holes +* Chests are not shrunk +* Chests, pumpkins, etc. are not rotated properly +* Torches are drawn hackily, do not attach to walls +* Incorrect textures for blocks that postdate terrain.png +* Transparent textures have black fringes due to non-premultiplied-alpha +* Only blocks at y=1..255 are shown (not y=0) +* If a 32x32x256 "quad-chunk" needs more than 800K quads, isn't handled (very unlikely) + +Some of these are due to engine limitations, and some of +these are because I didn't make the effort since my +goal was to make a demo for stb_voxel_render.h, not +to make a proper Minecraft viewer. + + +### Could this be turned into a proper Minecraft viewer? + +Yes and no. Yes, you could do it, but no, it wouldn't +really resemble this code that much anymore. + +You could certainly use this engine to +render the parts of Minecraft it works for, but many +of the things it doesn't handle it can't handle at all +(stairs, water, fences, carpets, etc) because it uses +low-precision coordinates to store voxel data. + +You would have to render all of the stuff it doesn't +handle through another rendering path. In a game (not +a viewer) you would need such a path for movable entities +like doors and carts anyway, so possibly handling other +things that way wouldn't be so bad. + +Rails, ladders, and redstone lines could be implemented by +using tex2 to overlay those effects, but you can't rotate +tex1 and tex2 independently, so you'd have to have a +separate texture for each orientation of rail, etc, and +you'd need special rendering for rail up/down sections. + +You can use the face-color effect to do biome coloration, +but the change won't be smooth the way it is in Minecraft. + + +### Why isn't building the mesh data faster? + +Partly because converting from minecraft data is expensive. + +Here is the approximate breakdown of an older version +of this executable and lib that did the building single-threaded, +and was a bit slower at building mesh data. + +* 25% loading & parsing minecraft files (4/5ths of this is my zlib) +* 18% converting from minecraft blockids & lighting to stb blockids & lighting +* 10% reordering from data[z][y]\[x] (minecraft-style) to data[y][x]\[z] (stb-style) +* 40% building mesh data +* 7% uploading mesh data to OpenGL + +I did do significant optimizations after the above, so the +final breakdown is different, but it should give you some +sense of the costs. + diff --git a/tests/caveview/cave_render.c b/tests/caveview/cave_render.c index e964587..e736573 100644 --- a/tests/caveview/cave_render.c +++ b/tests/caveview/cave_render.c @@ -3,81 +3,6 @@ // building (found in cave_mesher.c) -// This got lost somewhere - -// Q: How accurate is this as a Minecraft viewer? -// -// A: Not very. Many Minecraft blocks are not handled correctly: -// -// No signs, doors, redstone, rails, carpets, or other "flat" blocks -// Only one wood type -// Colored glass becomes regular glass -// Glass panes become glass blocks -// Stairs are turned into ramps -// Upper slabs turn into lower slabs -// Water level is incorrect -// No biome coloration -// Cactus is not shrunk, shows holes -// Chests are not shrunk -// Chests, pumpkins, etc. are not rotated properly -// Torches do not attach to walls -// Incorrect textures for blocks that postdate terrain.png -// Transparent textures have black fringes due to non-premultiplied-alpha -// If a 32x32x256 "quad-chunk" needs more than 300K quads, isn't handled -// Only blocks at y=1..255 are shown (not y=0) -// -// Some of these are due to engine limitations, and some of -// these are because I didn't make the effort since my -// goal was to make a demo for stb_voxel_render.h, not -// to make a proper Minecraft viewer. -// -// -// Q: Could this be turned into a proper Minecraft viewer? -// -// A: Yes and no. Yes, you could do it, but no, it wouldn't -// really resemble this code that much anymore. -// -// You could certainly use this engine to -// render the parts of Minecraft it works for, but many -// of the things it doesn't handle it can't handle at all -// (stairs, water, fences, carpets, etc) because it uses -// low-precision coordinates to store voxel data. -// -// You would have to render all of the stuff it doesn't -// handle through another rendering path. In a game (not -// a viewer) you would need such a path for movable entities -// like doors and carts anyway, so possibly handling other -// things that way wouldn't be so bad. -// -// Rails, ladders, and redstone lines could be implemented by -// using tex2 to overlay those effects, but you can't rotate -// tex1 and tex2 independently, so you'd have to have a -// separate texture for each orientation of rail, etc, and -// you'd need special rendering for rail up/down sections. -// -// You can use the face-color effect to do biome coloration, -// but the change won't be smooth the way it is in Minecraft. -// -// -// Q: Why isn't building the mesh data faster? -// -// A: Partly because converting from minecraft data is expensive. -// -// Here is the approximate breakdown of an older version -// of this executable and lib that did the building single-threaded, -// and was a bit slower at building mesh data. -// -// 25% loading & parsing minecraft files (4/5ths of this is zlib) -// 18% converting from minecraft blockids & lighting to stb blockids & lighting -// 10% reordering from data[z][y][x] (minecraft-style) to data[y][x][z] (stb-style) -// 40% building mesh data -// 7% uploading mesh data to OpenGL -// -// I did do significant optimizations after the above, so the -// final breakdown is different, but it should give you some -// sense of the costs. - - #include "stb_voxel_render.h" #define STB_GLEXT_DECLARE "glext_list.h" -- GitLab