Skip to content
体验新版
项目
组织
正在加载...
登录
切换导航
打开侧边栏
itdan3344
stb
提交
0cd5465f
S
stb
项目概览
itdan3344
/
stb
与 Fork 源项目一致
从无法访问的项目Fork
通知
2
Star
0
Fork
0
代码
文件
提交
分支
Tags
贡献者
分支图
Diff
Issue
0
列表
看板
标记
里程碑
合并请求
0
Wiki
0
Wiki
分析
仓库
DevOps
项目成员
Pages
S
stb
项目概览
项目概览
详情
发布
仓库
仓库
文件
提交
分支
标签
贡献者
分支图
比较
Issue
0
Issue
0
列表
看板
标记
里程碑
合并请求
0
合并请求
0
Pages
分析
分析
仓库分析
DevOps
Wiki
0
Wiki
成员
成员
收起侧边栏
关闭侧边栏
动态
分支图
创建新Issue
提交
Issue看板
体验新版 GitCode,发现更多精彩内容 >>
提交
0cd5465f
编写于
3月 12, 2015
作者:
S
Sean Barrett
浏览文件
操作
浏览文件
下载
电子邮件补丁
差异文件
re-add README.md that was in a different branch
上级
c27a6c6c
变更
2
隐藏空白更改
内联
并排
Showing
2 changed file
with
75 addition
and
75 deletion
+75
-75
tests/caveview/README.md
tests/caveview/README.md
+75
-0
tests/caveview/cave_render.c
tests/caveview/cave_render.c
+0
-75
未找到文件。
tests/caveview/README.md
0 → 100644
浏览文件 @
0cd5465f
# 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.
tests/caveview/cave_render.c
浏览文件 @
0cd5465f
...
...
@@ -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"
...
...
编辑
预览
Markdown
is supported
0%
请重试
或
添加新附件
.
添加附件
取消
You are about to add
0
people
to the discussion. Proceed with caution.
先完成此消息的编辑!
取消
想要评论请
注册
或
登录