stb/tests/caveview/README.md

   1 # FAQ
   2
   3 ### How to run it?
   4
   5 There's no GUI. Find a directory with Minecraft Anvil files (.mca).
   6 Copy a Minecraft "terrain.png" into that directory (do a google
   7 image search). Run from that directory.
   8
   9 ### How accurate is this as a Minecraft viewer?
  10
  11 Not very. Many Minecraft blocks are not handled correctly:
  12
  13 *         No redstone, rails, or other "flat" blocks
  14 *         No signs, doors, fences, carpets, or other complicated geometry
  15 *         Stairs are turned into ramps
  16 *         Upper slabs turn into lower slabs
  17 *         Wood types only for blocks, not stairs, slabs, etc
  18 *         Colored glass becomes regular glass
  19 *         Glass panes become glass blocks
  20 *         Water is opaque
  21 *         Water level is incorrect
  22 *         No biome coloration
  23 *         Cactus is not shrunk, shows holes
  24 *         Chests are not shrunk
  25 *         Double-chests draw as two chests
  26 *         Pumpkins etc. are not rotated properly
  27 *         Torches are drawn hackily, do not attach to walls
  28 *         Incorrect textures for blocks that postdate terrain.png
  29 *         Transparent textures have black fringes due to non-premultiplied-alpha
  30 *         Skylight and block light are combined in a single value
  31 *         Only blocks at y=1..255 are shown (not y=0)
  32 *         If a 32x32x256 "quad-chunk" needs more than 800K quads, isn't handled (very unlikely)
  33
  34 Some of these are due to engine limitations, and some of
  35 these are because I didn't make the effort since my
  36 goal was to make a demo for stb_voxel_render.h, not
  37 to make a proper Minecraft viewer.
  38
  39
  40 ### Could this be turned into a proper Minecraft viewer?
  41
  42 Yes and no. Yes, you could do it, but no, it wouldn't
  43 really resemble this code that much anymore.
  44
  45 You could certainly use this engine to
  46 render the parts of Minecraft it works for, but many
  47 of the things it doesn't handle it can't handle at all
  48 (stairs, water, fences, carpets, etc) because it uses
  49 low-precision coordinates to store voxel data.
  50
  51 You would have to render all of the stuff it doesn't
  52 handle through another rendering path. In a game (not
  53 a viewer) you would need such a path for movable entities
  54 like doors and carts anyway, so possibly handling other
  55 things that way wouldn't be so bad.
  56
  57 Rails, ladders, and redstone lines could be implemented by
  58 using tex2 to overlay those effects, but you can't rotate
  59 tex1 and tex2 independently, so there may be cases where
  60 the underlying texture needs a different rotation from the
  61 overlaid texture, which would require separate rendering.
  62 Handling redstone's brightness being different from underlying
  63 block's brightness would require separate rendering.
  64
  65 You can use the face-color effect to do biome coloration,
  66 but the change won't be smooth the way it is in Minecraft.
  67
  68
  69 ### Why isn't building the mesh data faster?
  70
  71 Partly because converting from minecraft data is expensive.
  72
  73 Here is the approximate breakdown of an older version
  74 of this executable and lib that did the building single-threaded.
  75
  76 *       25%   loading & parsing minecraft files (4/5ths of this is my crappy zlib)
  77 *       18%   converting from minecraft blockids & lighting to stb blockids & lighting
  78 *       10%   reordering from data[z][y]\[x] (minecraft-style) to data[y][x]\[z] (stb-style)
  79 *       40%   building mesh data
  80 *        7%   uploading mesh data to OpenGL
  81
  82 I did do significant optimizations after the above, so the
  83 final breakdown is different, but it should give you some
  84 sense of the costs.
  85