yyc12345/stb
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

re-add README.md that was in a different branch

Browse Source
This commit is contained in:
Sean Barrett 2015-03-12 00:00:10 -07:00
parent c27a6c6c36
commit 0cd5465f52
2 changed files with 75 additions and 75 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

75
tests/caveview/README.md Normal file
View File

@ -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.

75
tests/caveview/cave_render.c
View File

@ -3,81 +3,6 @@
// building (found in cave_mesher.c) // 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" #include "stb_voxel_render.h"
#define STB_GLEXT_DECLARE "glext_list.h" #define STB_GLEXT_DECLARE "glext_list.h"