-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathnotes
114 lines (88 loc) · 6.66 KB
/
notes
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
================================================================================
== ATTRIBUTE ASSEMBLY ==========================================================
when loading models from GLTF, the attributes can be assembled into buffers
easily as so:
┌───────┐
│INDICES│
└──┌─┐──┘ ┌───────────────┐
│5│───┬────┐ └┐ORIGIN OFFSET┌┘
├─┤ │ │ │ + STRIDES │ ┌──────────────────────┐
│3│───┤ │ └──┬────────┬─┘ │ORIGIN/UV COORD BUFFER│
├─┤┌──┘ ├─────────► │ACCESSOR│[2] └────┌─────────┐───────┘
│2│┘ │ └┌─ ─┐┘ │<0.2,0.5>│
└─┘ │ │BUFFER│[3] │<0.1,0.2>│
│ └──────┘ │<0.5,0.7>│ ◄─┐
│ │ │<0.2,0.8>│ ◄─┤
│ └──────────┐ │<0.8,0.5>│ │
┌─────────────┤ │ │<0.1,0.2>│ ◄─┤
│ │ │ │<2, 3, 4>│ │
│ │ ┌───────────┐ ├────►│<2, 3, 4>│ │
│ │ │UV OFFSET +│ ├────►│<2, 3, 4>│ │
│ │ │ + STRIDES │ │ │<2, 3, 4>│ │
│ │ └─┬────────┬┘ └────►│<2, 3, 4>│ │
│ └─────────► │ACCESSOR│[0] └─────────┘ │
│ └┌─ ─┐┘ ┌──────────────────────┘
│ ┌─────────────┐ │BUFFER│[0]│
│ │NORMAL OFFSET│ └──────┘ │ ┌─────────────┐
│ │ + STRIDES │ │ │ │NORMAL BUFFER│
│ └──┬────────┬─┘ └───────┘ └─┌─────────┐─┘
└────► │ACCESSOR│[0] │<2, 3, 4>│
└┌─ ─┐┘ │<2, 3, 4>│
│BUFFER│[0] ┌──────────►│<2, 3, 4>│
└──────┘ ├───────── ►│<2, 3, 4>│
└──────────────────┤ │<2, 3, 4>│
└──────────►│<2, 3, 4>│
└─────────┘
As can be seen, there are lots of potential configurations that the data can be
laid out in the asset model. Multiple attributes can be any set of buffers
with their own offsets, their own strides, etc. Given that artists aren't
really thinking about the layout of their data, it doesn't make much sense
to rely on it. Not to mention we might perform faster under a specific
configuration of layout (such as interweaved vertices)
Something that is important to know about how our renderer works is that the
origin fetch speeds will remain dominant in the visibility buffer, as the
only attribute information necessary at that point. In the material processes,
all the attributes will be fetched in a way that will prevent unneccessary
overdraws (ei the information we grab will not be discarded)
Thus there are two possible configurations to select between to compare
performances.
┌───────┐ ┌─────────────┐
│INDICES│ │ORIGIN BUFFER│
└──┌─┐──┘ └┌─────────┐──┘
│5├┬─┬─┐ │<1, 3, 4>│
│3├┤ │ │ │<2, 3, 4>│
│2├┘ │ ├──►│<2, 3, 4>│
└─┘ │ ├──►│<2, 3, 4>│
│ │ │<2, 3, 4>│
│ └──►│<2, 3, 4>│
┌────────┘ └─────────┘
│
│ ┌─────────────┐ ┌────────────────┐
│ │ANIMATION │────►│ANIMATION BUFFER│ [mapped to client]
├─► │STRIDE+OFFSET│ └─┌───────────────┐
│ └─────────────┘ │JOINTS, WEIGHTS│
│ └───────────────┘
│ ┌───────────┐
└─► │ MATERIAL │ ┌───────────────┐
│ STRIDE+OFF│───────►│MATERIAL BUFFER│
└───────────┘ └─┌──────────────────────────┐
│NORMAL, UV, TANGENT, COLOR│
└──────────────────────────┘
[ note that Animation/Material stride/offsets are part of the same buffer ]
--- OR ---
┌───────┐
│INDICES│
└──┌─┐──┘ ┌───────────────────────────┐ ┌──────────────────────┐
│5├┬──►│ORIGIN, NORMAL, ... OFFSETS├──►│ORIGIN+MATERIAL BUFFER│
│3├┤ └───────────────────────────┘ └──────────────────────┘
│2├┴─┐ ┌───────────────────────┐ ┌────────────────┐
└─┘ └►│JOINTS, WEIGHTS OFFSETS├────►│ANIMATION BUFFER│
└───────────────────────┘ └────────────────┘
as well the formats will be converted to:
INDICES: u32
ORIGIN: RGBA 32F (maybe RGB)
NORMAL: RGB 32F
UV: RG 32F
TANGENT: RGB 32F
COLOR: RGB 32F
The renderer will use meshlets [todo]