restore old q&a

tests/caveview/cave_render.c

@@ -2,6 +2,82 @@
 // to GL meshes, and manages threads that do the raw-mesh
 // 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"