note update
This commit is contained in:
parent
d63af3eac3
commit
af0038b5e6
4
.obsidian/appearance_0.json
vendored
Normal file
4
.obsidian/appearance_0.json
vendored
Normal file
@ -0,0 +1,4 @@
|
||||
{
|
||||
"accentColor": "",
|
||||
"baseFontSize": 18
|
||||
}
|
||||
12
.obsidian/community-plugins_0.json
vendored
Normal file
12
.obsidian/community-plugins_0.json
vendored
Normal file
@ -0,0 +1,12 @@
|
||||
[
|
||||
"obsidian-git",
|
||||
"obsidian-kanban",
|
||||
"obsidian-excalidraw-plugin",
|
||||
"calendar",
|
||||
"obsidian-image-auto-upload-plugin",
|
||||
"templater-obsidian",
|
||||
"periodic-notes",
|
||||
"media-extended",
|
||||
"mx-bili-plugin",
|
||||
"obsidian-plantuml"
|
||||
]
|
||||
51
.obsidian/core-plugins.json
vendored
51
.obsidian/core-plugins.json
vendored
@ -1,21 +1,30 @@
|
||||
[
|
||||
"file-explorer",
|
||||
"global-search",
|
||||
"switcher",
|
||||
"graph",
|
||||
"backlink",
|
||||
"canvas",
|
||||
"outgoing-link",
|
||||
"tag-pane",
|
||||
"properties",
|
||||
"page-preview",
|
||||
"daily-notes",
|
||||
"templates",
|
||||
"note-composer",
|
||||
"command-palette",
|
||||
"editor-status",
|
||||
"bookmarks",
|
||||
"outline",
|
||||
"word-count",
|
||||
"file-recovery"
|
||||
]
|
||||
{
|
||||
"file-explorer": true,
|
||||
"global-search": true,
|
||||
"switcher": true,
|
||||
"graph": true,
|
||||
"backlink": true,
|
||||
"canvas": true,
|
||||
"outgoing-link": true,
|
||||
"tag-pane": true,
|
||||
"page-preview": true,
|
||||
"daily-notes": true,
|
||||
"templates": true,
|
||||
"note-composer": true,
|
||||
"command-palette": true,
|
||||
"slash-command": false,
|
||||
"editor-status": true,
|
||||
"bookmarks": true,
|
||||
"markdown-importer": false,
|
||||
"zk-prefixer": false,
|
||||
"random-note": false,
|
||||
"outline": true,
|
||||
"word-count": true,
|
||||
"slides": false,
|
||||
"audio-recorder": false,
|
||||
"workspaces": false,
|
||||
"file-recovery": true,
|
||||
"publish": false,
|
||||
"sync": false,
|
||||
"properties": true
|
||||
}
|
||||
22
.obsidian/graph_0.json
vendored
Normal file
22
.obsidian/graph_0.json
vendored
Normal file
@ -0,0 +1,22 @@
|
||||
{
|
||||
"collapse-filter": false,
|
||||
"search": "",
|
||||
"showTags": false,
|
||||
"showAttachments": false,
|
||||
"hideUnresolved": false,
|
||||
"showOrphans": false,
|
||||
"collapse-color-groups": false,
|
||||
"colorGroups": [],
|
||||
"collapse-display": true,
|
||||
"showArrow": false,
|
||||
"textFadeMultiplier": 0,
|
||||
"nodeSizeMultiplier": 1,
|
||||
"lineSizeMultiplier": 1,
|
||||
"collapse-forces": true,
|
||||
"centerStrength": 0.518713248970312,
|
||||
"repelStrength": 10,
|
||||
"linkStrength": 1,
|
||||
"linkDistance": 250,
|
||||
"scale": 0.8854989543150492,
|
||||
"close": false
|
||||
}
|
||||
BIN
Assert/Image/image-20241224115033263.png
Normal file
BIN
Assert/Image/image-20241224115033263.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 92 KiB |
@ -85,4 +85,10 @@ Android Studio如何连接
|
||||
|
||||
- 文件 studio64.exe.vmoptions
|
||||
- 添加 `-Dfile.encoding=UTF-8`
|
||||
## 清单报错
|
||||
|
||||
- 如果项目中有多个模块或使用了第三方库，这些库的`AndroidManifest.xml`文件可能会与主项目的清单文件产生冲突。
|
||||
- 在这种情况下，打开`build.gradle`中的`manifest`合并报告查看具体的冲突信息：
|
||||
- 路径：`app/build/outputs/logs/manifest-merger-release-report.txt`
|
||||
- 合并冲突通常发生在权限、`<application>`、`<activity>`等元素上，查看并手动解决冲突。
|
||||
|
||||
|
||||
@ -49,3 +49,9 @@ go install google.golang.org/protobuf/cmd/protoc-gen-go
|
||||
go install google.golang.org/grpc/cmd/protoc-gen-go-grpc
|
||||
```
|
||||
|
||||
## Goland
|
||||
|
||||
[官网地址](https://www.jetbrains.com/go/download/download-thanks.html?platform=windows)
|
||||
|
||||
https://www.jetbrains.com/go/download/download-thanks.html?platform=windows
|
||||
|
||||
|
||||
@ -108,6 +108,10 @@ luapanda插件
|
||||
zhaoboshuang
|
||||
892st21t
|
||||
|
||||
外网
|
||||
zhaoboshuang
|
||||
5xhs6ma3
|
||||
|
||||
## RTX
|
||||
|
||||
企业实时通信
|
||||
@ -124,6 +128,11 @@ jg
|
||||
|
||||
jghd123
|
||||
|
||||
### 打包
|
||||
192.168.101.212
|
||||
devel
|
||||
Rg7yQgjy
|
||||
|
||||
## \\192.168.1.212
|
||||
`\\192.168.101.212`
|
||||
`\\192.168.1.212\Nei`
|
||||
|
||||
@ -94,9 +94,17 @@ set CGO_LDFLAGS=-LF:\Coding\GoModule\cgo -I:vulkan.lib
|
||||
go build -o main.exe main.go
|
||||
|
||||
#C:\Users\Administrator\AppData\Roaming\go
|
||||
#C:\Users\ouczbs\AppData\Roaming\go
|
||||
```
|
||||
```
|
||||
CGO_ENABLED=1
|
||||
CGO_CFLAGS=-IF:\Coding\GoModule\cgo
|
||||
CGO_LDFLAGS=-LF:\Coding\GoModule\cgo -l:vulkan.lib
|
||||
GOPROXY=https://goproxy.cn,direct
|
||||
```
|
||||
|
||||
|
||||
### mingw
|
||||
https://blog.csdn.net/yyd9015/article/details/133873853
|
||||
|
||||
# 条件编译
|
||||
|
||||
|
||||
15
src/m/me/密码.md
Normal file
15
src/m/me/密码.md
Normal file
@ -0,0 +1,15 @@
|
||||
---
|
||||
aliases:
|
||||
tags:
|
||||
creation date: 2024-07-04 14:29
|
||||
modification date: Thursday 4th July 2024 14:29:10
|
||||
---
|
||||
# 破解
|
||||
## 解压密码
|
||||
|
||||
【徐公】 回复 【解压密码 】即可获取
|
||||
:: `xugong`
|
||||
code
|
||||
```
|
||||
JZFLGE21ND-eyJsaWNlbnNlSWQiOiJKWkZMR0UyMU5EIiwibGljZW5zZWVOYW1lIjoic2lnbnVwIHNjb290ZXIiLCJhc3NpZ25lZU5hbWUiOiIiLCJhc3NpZ25lZUVtYWlsIjoiIiwibGljZW5zZVJlc3RyaWN0aW9uIjoiIiwiY2hlY2tDb25jdXJyZW50VXNlIjpmYWxzZSwicHJvZHVjdHMiOlt7ImNvZGUiOiJQU0kiLCJmYWxsYmFja0RhdGUiOiIyMDI1LTA4LTAxIiwicGFpZFVwVG8iOiIyMDI1LTA4LTAxIiwiZXh0ZW5kZWQiOnRydWV9LHsiY29kZSI6IlBHTyIsImZhbGxiYWNrRGF0ZSI6IjIwMjUtMDgtMDEiLCJwYWlkVXBUbyI6IjIwMjUtMDgtMDEiLCJleHRlbmRlZCI6dHJ1ZX0seyJjb2RlIjoiUFdTIiwiZmFsbGJhY2tEYXRlIjoiMjAyNS0wOC0wMSIsInBhaWRVcFRvIjoiMjAyNS0wOC0wMSIsImV4dGVuZGVkIjp0cnVlfSx7ImNvZGUiOiJHTyIsImZhbGxiYWNrRGF0ZSI6IjIwMjUtMDgtMDEiLCJwYWlkVXBUbyI6IjIwMjUtMDgtMDEiLCJleHRlbmRlZCI6ZmFsc2V9LHsiY29kZSI6IlBDV01QIiwiZmFsbGJhY2tEYXRlIjoiMjAyNS0wOC0wMSIsInBhaWRVcFRvIjoiMjAyNS0wOC0wMSIsImV4dGVuZGVkIjp0cnVlfV0sIm1ldGFkYXRhIjoiMDEyMDIyMDkwMlBTQU4wMDAwMDUiLCJoYXNoIjoiVFJJQUw6LTE1NTI3NDEyNzIiLCJncmFjZVBlcmlvZERheXMiOjcsImF1dG9Qcm9sb25nYXRlZCI6ZmFsc2UsImlzQXV0b1Byb2xvbmdhdGVkIjpmYWxzZX0=-cQoXljKE7uBjoI23ZBPd84P89vQAaprVvVhxj1/nSOABUZKPZMCs6p2id5WKBP1n0EoPHykvzd0y7QcdcO2hxNwbaBRZxpPFuuMigGazrrt+zSd9+UlFXmtcseFTXlWn7Jw2qqp7WSVQlj+o3gf2Gic9/Vp2pAmIajMGdFDsXcHbYUrLwTRVtFkNtggtsqh0AVS8xhzLuXMzGXJsqEEWPZCKMEjy0bURm/FQvrRC/gIptJzuybSb/neqKmvxZefX1lhe98igS3tZsL/E+hsQK7ueXVSP2AuuVEz/6qHYknPS7K4UluWpd+ktIxTcHjIykK1tlWlwTsupZTxnvXFWQA==-MIIETDCCAjSgAwIBAgIBDTANBgkqhkiG9w0BAQsFADAYMRYwFAYDVQQDDA1KZXRQcm9maWxlIENBMB4XDTIwMTAxOTA5MDU1M1oXDTIyMTAyMTA5MDU1M1owHzEdMBsGA1UEAwwUcHJvZDJ5LWZyb20tMjAyMDEwMTkwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCUlaUFc1wf+CfY9wzFWEL2euKQ5nswqb57V8QZG7d7RoR6rwYUIXseTOAFq210oMEe++LCjzKDuqwDfsyhgDNTgZBPAaC4vUU2oy+XR+Fq8nBixWIsH668HeOnRK6RRhsr0rJzRB95aZ3EAPzBuQ2qPaNGm17pAX0Rd6MPRgjp75IWwI9eA6aMEdPQEVN7uyOtM5zSsjoj79Lbu1fjShOnQZuJcsV8tqnayeFkNzv2LTOlofU/Tbx502Ro073gGjoeRzNvrynAP03pL486P3KCAyiNPhDs2z8/COMrxRlZW5mfzo0xsK0dQGNH3UoG/9RVwHG4eS8LFpMTR9oetHZBAgMBAAGjgZkwgZYwCQYDVR0TBAIwADAdBgNVHQ4EFgQUJNoRIpb1hUHAk0foMSNM9MCEAv8wSAYDVR0jBEEwP4AUo562SGdCEjZBvW3gubSgUouX8bOhHKQaMBgxFjAUBgNVBAMMDUpldFByb2ZpbGUgQ0GCCQDSbLGDsoN54TATBgNVHSUEDDAKBggrBgEFBQcDATALBgNVHQ8EBAMCBaAwDQYJKoZIhvcNAQELBQADggIBABqRoNGxAQct9dQUFK8xqhiZaYPd30TlmCmSAaGJ0eBpvkVeqA2jGYhAQRqFiAlFC63JKvWvRZO1iRuWCEfUMkdqQ9VQPXziE/BlsOIgrL6RlJfuFcEZ8TK3syIfIGQZNCxYhLLUuet2HE6LJYPQ5c0jH4kDooRpcVZ4rBxNwddpctUO2te9UU5/FjhioZQsPvd92qOTsV+8Cyl2fvNhNKD1Uu9ff5AkVIQn4JU23ozdB/R5oUlebwaTE6WZNBs+TA/qPj+5/we9NH71WRB0hqUoLI2AKKyiPw++FtN4Su1vsdDlrAzDj9ILjpjJKA1ImuVcG329/WTYIKysZ1CWK3zATg9BeCUPAV1pQy8ToXOq+RSYen6winZ2OO93eyHv2Iw5kbn1dqfBw1BuTE29V2FJKicJSu8iEOpfoafwJISXmz1wnnWL3V/0NxTulfWsXugOoLfv0ZIBP1xH9kmf22jjQ2JiHhQZP7ZDsreRrOeIQ/c4yR8IQvMLfC0WKQqrHu5ZzXTH4NO3CwGWSlTY74kE91zXB5mwWAx1jig+UXYc2w4RkVhy0//lOmVya/PEepuuTTI4+UJwC7qbVlh5zfhj8oTNUXgN0AOc+Q0/WFPl1aw5VV/VrO8FCoB15lFVlpKaQ1Yh+DVU8ke+rt9Th0BCHXe0uZOEmH0nOnH/0onD
|
||||
```
|
||||
189
src/n/noesis.md
Normal file
189
src/n/noesis.md
Normal file
@ -0,0 +1,189 @@
|
||||
---
|
||||
aliases:
|
||||
tags:
|
||||
creation date: 2024-12-23 10:54
|
||||
modification date: Monday 23rd December 2024 10:54:30
|
||||
---
|
||||
# 文档
|
||||
|
||||
## 控件
|
||||
|
||||
是否有富文本的概念？
|
||||
|
||||
- 按钮
|
||||
|
||||
- Button
|
||||
- RepeatButton
|
||||
- ToggleButton
|
||||
- CheckBox
|
||||
- RadioButton
|
||||
|
||||
- 常用控件
|
||||
|
||||
- Label
|
||||
- 文本，ToolTip
|
||||
- GroupBox
|
||||
- 自带标题，只能包含一个子控件
|
||||
- Expander
|
||||
- 同GroupBox，但可以展开、收缩
|
||||
|
||||
- ProgressBar
|
||||
- 进度条
|
||||
- Slider
|
||||
- 滑块
|
||||
- TextBox
|
||||
- 文本输入框
|
||||
- PasswordBox
|
||||
- 密码框
|
||||
|
||||
- 多子容器
|
||||
|
||||
- Selectors
|
||||
- 好像是抽象类，定义了选中相关逻辑接口
|
||||
- ComboBox
|
||||
- 下拉选择框，默认只展示选中项，节省空间
|
||||
- ListBox
|
||||
- 同ComboBox，但不会展示、隐藏
|
||||
- ListView
|
||||
- 继承自ListBox，可支持自定义子元素类型展示
|
||||
- GridView
|
||||
- 继承自ListView
|
||||
- TabControl
|
||||
- 页签栏
|
||||
- Menu
|
||||
- 标题菜单
|
||||
- ContextMenu
|
||||
- 内容菜单，比如右键显示
|
||||
- TreeView
|
||||
- 树形容器
|
||||
- ToolBar
|
||||
- 工具栏
|
||||
- StatusBar
|
||||
- 状态栏
|
||||
|
||||
## 控件实例
|
||||
|
||||
- Image
|
||||
- Text
|
||||
- Animation
|
||||
|
||||
## 事件
|
||||
|
||||
- 控件绑定
|
||||
- c++ 通过名字找到对应控件后，直接在代码强行绑定事件
|
||||
- 接口绑定
|
||||
- 在xaml中定义事件接口名字
|
||||
- 在c++中绑定函数到事件接口上
|
||||
- 命令绑定
|
||||
-
|
||||
- 路由事件 暂时看不懂
|
||||
- Bubbling
|
||||
- Tunneling
|
||||
- Direct
|
||||
|
||||
## FrameWorkElement
|
||||
|
||||
- 生命周期
|
||||
- Initialized 已初始化但布局未计算
|
||||
- Loaded 已全部加载完成
|
||||
- Reloaded 热重载
|
||||
- Unloaded 删除控件时触发
|
||||
|
||||
## 画布
|
||||
|
||||
- 定义画刷
|
||||
- 定义形状
|
||||
|
||||
# xaml
|
||||
|
||||
## 标记扩展
|
||||
|
||||
|
||||
|
||||
```xaml
|
||||
<Style TargetType="{x:Type Button}">
|
||||
<Button Background="{x:Null}">Click</Button>
|
||||
<TextBlock TextContent="{Binding Path=SimpleProperty, Mode=OneTime}"/>
|
||||
<TextBlock
|
||||
Name="myText"
|
||||
Background="{StaticResource
|
||||
{x:Static SystemColors.ActiveCaptionBrushKey}}" />
|
||||
<TextBlock Name="myText" Background="{DynamicResource
|
||||
{x:Static SystemColors.ActiveCaptionBrushKey}}" />
|
||||
|
||||
```
|
||||
|
||||
```c#
|
||||
TypeExtension te = new TypeExtension("Button");
|
||||
object val = te.ProvideValue(s, Style.TargetTypeProperty);
|
||||
|
||||
Style s = new Style( );
|
||||
s.TargetType = typeof(Button);
|
||||
|
||||
Button b = new Button( );
|
||||
b.Background = null;
|
||||
b.AddText("Click");
|
||||
|
||||
Binding b = new Binding( );
|
||||
b.Path = new PropertyPath("SimpleProperty");
|
||||
b.Mode = BindingMode.OneTime;
|
||||
|
||||
myText.Background = (Brush)
|
||||
myText.FindResource(SystemColors.ActiveCaptionBrushKey);
|
||||
|
||||
myText.SetResourceReference(TextBlock.Background,
|
||||
SystemColors.ActiveCaptionBrushKey);
|
||||
|
||||
```
|
||||
|
||||
```xaml
|
||||
<?Mapping XmlNamespace="http://example.com/foo"ClrNamespace=
|
||||
"MyNamespace" ?>
|
||||
<Window
|
||||
xmlns="http://schemas.microsoft.com/winfx/avalon/2005"
|
||||
xmlns:x="http://schemas.microsoft.com/winfx/xaml/2005"
|
||||
xmlns:my="http://example.com/foo">
|
||||
<Button my:Foo.Bar="Blue" />
|
||||
<StackPanel>
|
||||
<StackPanel.Children>
|
||||
<Button>Foo</Button>
|
||||
<Button>Bar</Button>
|
||||
<StackPanel.Children>
|
||||
</StackPanel>
|
||||
<Button>
|
||||
<Button.Content>
|
||||
<Ellipse Fill="Red" Height="20" Width="70"/>
|
||||
</Button.Content>
|
||||
</Button>
|
||||
<ListBox>
|
||||
<ListBox.Items>
|
||||
<TextBlock>Foo</TextBlock>
|
||||
<TextBlock>Bar</TextBlock>
|
||||
<TextBlock>Quux</TextBlock>
|
||||
<TextBlock>Spong</TextBlock>
|
||||
</ListBox.Items>
|
||||
</ListBox>
|
||||
|
||||
</Window>
|
||||
|
||||
|
||||
```
|
||||
|
||||
|
||||
|
||||
# vulkan 渲染器
|
||||
|
||||
- 传输管线
|
||||
- 分两种传输
|
||||
- 高频的渲染队列传输，在交换链waitforfence 后，可以保证渲染队列中渲染命令 和 传输命令都执行完毕
|
||||
- 传输的中间缓冲需要按类型进行复用
|
||||
- 复用对象要和传输队列区分开，因为二者复用规则不一样
|
||||
- 低频的传输队列传输，可以按一定策略每10帧同步清空一次，可以按照帧索引来判断是否传输完毕
|
||||
- 中间缓冲也需要按类型进行复用
|
||||
- 所以呢？ 抽象一个资源类，然后分两层
|
||||
- 那么缓冲区如何管理呢？
|
||||
- 可以跨队列提交
|
||||
- 如何重用呢？
|
||||
- 什么时候重置？
|
||||
|
||||
嘿，我发现一个问题，如果我当前vulkan 着色器需要一个图片，图片还未加载，然后就会创建一个undefined 布局的图片，然后再把布局改成 TRANSFER_DST_OPTIMAL，把磁盘数据拷贝到图片中。这个时候我着色器读取图像时，布局又要处于SHADER_READ_ONLY_OPTIMAL。
|
||||
15
src/s/shell/dumpbin.md
Normal file
15
src/s/shell/dumpbin.md
Normal file
@ -0,0 +1,15 @@
|
||||
---
|
||||
aliases:
|
||||
tags:
|
||||
creation date: 2024-06-26 17:50
|
||||
modification date: 星期三 26日 六月 2024 17:50:59
|
||||
---
|
||||
# 静态库
|
||||
- MDd
|
||||
- MD
|
||||
- MTd
|
||||
- MT
|
||||
MT 与 MD 的区别在于底层多线程库与c++标准库不同
|
||||
```
|
||||
dumpbin /directives myzlib.lib
|
||||
```
|
||||
@ -1,10 +0,0 @@
|
||||
---
|
||||
aliases:
|
||||
tags:
|
||||
creation date: 2024-01-17 13:47
|
||||
modification date: 星期三 17日 一月 2024 13:47:00
|
||||
---
|
||||
# vulkanapi
|
||||
|
||||
## shader
|
||||
|
||||
23
src/v/vulkan/vulkan resource.md
Normal file
23
src/v/vulkan/vulkan resource.md
Normal file
@ -0,0 +1,23 @@
|
||||
---
|
||||
aliases:
|
||||
tags:
|
||||
creation date: 2024-10-21 11:29
|
||||
modification date: Monday 21st October 2024 11:29:12
|
||||
---
|
||||
# 内存管理
|
||||
|
||||
## 全局对象
|
||||
全局光照、场景属性
|
||||
- 更新
|
||||
- 整体更新
|
||||
- 存储
|
||||
- 所有数据放到一个大结构体里，然后持有唯一的对象结构
|
||||
## 普通对象
|
||||
按照基础类型分类，通过对象池管理
|
||||
- 更新
|
||||
- 挨个更新
|
||||
- 存储
|
||||
- 一个类型一个对象池
|
||||
## 大量同类对象
|
||||
- 分组批量存储、偏移更新
|
||||
-
|
||||
77
src/v/vulkan/vulkan_guid.md
Normal file
77
src/v/vulkan/vulkan_guid.md
Normal file
@ -0,0 +1,77 @@
|
||||
---
|
||||
aliases:
|
||||
tags:
|
||||
creation date: 2024-01-17 13:47
|
||||
modification date: 星期三 17日 一月 2024 13:47:00
|
||||
---
|
||||
# vulkanapi
|
||||
|
||||
## loader shader
|
||||
|
||||
### 输入
|
||||
|
||||
- 输入布局 `location`
|
||||
- 顶点属性必须包含这些输入布局
|
||||
- 一个小着色器，也可支持多个顶点类型
|
||||
- 统一缓冲区 `binding + uniform`& 存储缓冲区 `binding + storage`
|
||||
- 采样器和纹理 `binding + uniform + sampler2D`
|
||||
- 输入附件 `subpass`
|
||||
|
||||
```glsl
|
||||
#version 450
|
||||
#extension GL_GOOGLE_include_directive : enable
|
||||
|
||||
layout (location = 0) in vec3 position;
|
||||
layout (location = 1) in vec2 texture;
|
||||
layout (location = 2) in vec3 normal;
|
||||
layout (location = 3) in vec3 tangent;
|
||||
layout (location = 4) in vec4 weights;
|
||||
layout (location = 5) in uvec4 bones;
|
||||
|
||||
layout(binding = 0) uniform UniformBufferObject {
|
||||
mat4 model;
|
||||
mat4 view;
|
||||
mat4 proj;
|
||||
} ubo;
|
||||
|
||||
layout(binding = 1) buffer StorageBufferObject {
|
||||
vec4 data[];
|
||||
} sbo;
|
||||
|
||||
layout(binding = 2) uniform sampler2D textureSampler;
|
||||
|
||||
layout(input_attachment_index = 0, set = 0, binding = 3) uniform subpassInput inputAttachment;
|
||||
|
||||
//out vec4 outPosition;
|
||||
out gl_PerVertex {
|
||||
vec4 gl_Position;
|
||||
};
|
||||
|
||||
vec2 positions[3] = vec2[](
|
||||
vec2(0.0, -0.5),
|
||||
vec2(0.5, 0.5),
|
||||
vec2(-0.5, 0.5)
|
||||
);
|
||||
|
||||
void main() {
|
||||
gl_Position = vec4(positions[gl_VertexIndex], 0.0, 1.0);
|
||||
}
|
||||
```
|
||||
|
||||
### 渲染管线
|
||||
|
||||
- 顶点属性
|
||||
- 顶点装配
|
||||
- 曲面细分
|
||||
- 光线追踪属性
|
||||
- 光栅化属性
|
||||
- 视口剪裁
|
||||
- 颜色混合
|
||||
- 模板测试
|
||||
- ...
|
||||
|
||||
|
||||
|
||||
# loader mesh
|
||||
|
||||
copy vertex and index to gpu
|
||||
219
src/v/vulkan/描述符.md
Normal file
219
src/v/vulkan/描述符.md
Normal file
@ -0,0 +1,219 @@
|
||||
---
|
||||
aliases:
|
||||
tags:
|
||||
creation date: 2024-10-30 20:47
|
||||
modification date: Wednesday 30th October 2024 20:47:25
|
||||
---
|
||||
当然可以！下面是一个示例，展示如何在 Vulkan 中为你的着色器代码添加描述符，并在着色器中使用这些描述符。这个例子将包括一个 uniform buffer，用于传递颜色数据。
|
||||
1. 更新着色器代码
|
||||
|
||||
首先，我们将更新顶点着色器以接受一个 uniform 颜色：
|
||||
顶点着色器（Vertex Shader）
|
||||
|
||||
glsl
|
||||
|
||||
#version 450
|
||||
layout (location = 0) in vec3 iPos;
|
||||
|
||||
layout(set = 0, binding = 0) uniform ColorData {
|
||||
vec4 uColor; // 从 uniform buffer 获取颜色
|
||||
};
|
||||
|
||||
layout (location = 0) out vec4 vColor;
|
||||
|
||||
void main()
|
||||
{
|
||||
gl_Position = vec4(iPos, 1.0);
|
||||
vColor = uColor; // 使用 uniform 颜色
|
||||
}
|
||||
|
||||
片段着色器（Fragment Shader）
|
||||
|
||||
片段着色器保持不变，只是将颜色从顶点着色器传递到输出：
|
||||
|
||||
glsl
|
||||
|
||||
#version 450
|
||||
#extension GL_ARB_separate_shader_objects : enable
|
||||
layout (location = 0) in vec4 vColor;
|
||||
layout (location = 0) out vec4 oColor;
|
||||
|
||||
void main() {
|
||||
oColor = vColor; // 输出传入的颜色
|
||||
}
|
||||
|
||||
2. Vulkan 设置代码
|
||||
|
||||
接下来，我们将添加必要的 Vulkan 设置，以创建 uniform buffer，并将其绑定到描述符集中。
|
||||
2.1 创建 Uniform Buffer
|
||||
|
||||
首先，我们需要创建一个 uniform buffer，以便传递颜色数据。
|
||||
|
||||
cpp
|
||||
|
||||
// 颜色数据结构
|
||||
struct ColorData {
|
||||
glm::vec4 color; // 使用 glm 库来处理向量
|
||||
};
|
||||
|
||||
// 创建 uniform buffer
|
||||
VkBuffer uniformBuffer;
|
||||
VkDeviceMemory uniformBufferMemory;
|
||||
|
||||
// 设置 uniform buffer 的大小
|
||||
VkDeviceSize bufferSize = sizeof(ColorData);
|
||||
|
||||
// 创建 buffer
|
||||
createBuffer(bufferSize, VK_BUFFER_USAGE_UNIFORM_BUFFER_BIT, VK_MEMORY_PROPERTY_HOST_VISIBLE_BIT | VK_MEMORY_PROPERTY_HOST_COHERENT_BIT, uniformBuffer, uniformBufferMemory);
|
||||
|
||||
2.2 创建描述符布局
|
||||
|
||||
创建描述符布局以定义 uniform buffer 的结构。
|
||||
|
||||
cpp
|
||||
|
||||
VkDescriptorSetLayoutBinding layoutBinding = {};
|
||||
layoutBinding.binding = 0;
|
||||
layoutBinding.descriptorType = VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER;
|
||||
layoutBinding.descriptorCount = 1;
|
||||
layoutBinding.stageFlags = VK_SHADER_STAGE_VERTEX_BIT; // 顶点着色器使用
|
||||
layoutBinding.pImmutableSamplers = nullptr;
|
||||
|
||||
VkDescriptorSetLayoutCreateInfo layoutInfo = {};
|
||||
layoutInfo.sType = VK_STRUCTURE_TYPE_DESCRIPTOR_SET_LAYOUT_CREATE_INFO;
|
||||
layoutInfo.bindingCount = 1;
|
||||
layoutInfo.pBindings = &layoutBinding;
|
||||
|
||||
VkDescriptorSetLayout descriptorSetLayout;
|
||||
vkCreateDescriptorSetLayout(device, &layoutInfo, nullptr, &descriptorSetLayout);
|
||||
|
||||
2.3 创建描述符池
|
||||
|
||||
创建描述符池以管理描述符的分配。
|
||||
|
||||
cpp
|
||||
|
||||
VkDescriptorPoolSize poolSize = {};
|
||||
poolSize.type = VK_DESCRIPTOR_TYPE_UNIFORM_BUFFER;
|
||||
poolSize.descriptorCount = 1;
|
||||
|
||||
VkDescriptorPoolCreateInfo poolInfo = {};
|
||||
poolInfo.sType = VK_STRUCTURE_TYPE_DESCRIPTOR_POOL_CREATE_INFO;
|
||||
poolInfo.poolSizeCount = 1;
|
||||
poolInfo.pPoolSizes = &poolSize;
|
||||
poolInfo.maxSets = 1;
|
||||
|
||||
VkDescriptorPool descriptorPool;
|
||||
vkCreateDescriptorPool(device, &poolInfo, nullptr, &descriptorPool);
|
||||
|
||||
2.4 分配描述符集
|
||||
|
||||
分配描述符集以绑定 uniform buffer。
|
||||
|
||||
cpp
|
||||
|
||||
VkDescriptorSetAllocateInfo allocInfo = {};
|
||||
allocInfo.sType = VK_STRUCTURE_TYPE_DESCRIPTOR_SET_ALLOCATE_INFO;
|
||||
allocInfo.descriptorPool = descriptorPool;
|
||||
allocInfo.descriptorSetCount = 1;
|
||||
allocInfo.pSetLayouts = &descriptorSetLayout;
|
||||
|
||||
VkDescriptorSet descriptorSet;
|
||||
vkAllocateDescriptorSets(device, &allocInfo, &descriptorSet);
|
||||
|
||||
2.5 更新描述符集
|
||||
|
||||
将 uniform buffer 更新到描述符集中。
|
||||
|
||||
cpp
|
||||
|
||||
VkDescriptorBufferInfo bufferInfo = {};
|
||||
bufferInfo.buffer = uniformBuffer; // 你的 uniform buffer
|
||||
bufferInfo.offset = 0;
|
||||
bufferInfo.range = sizeof(ColorData); // uniform buffer 的大小
|
||||
|
||||
vkUpdateDescriptorSets(device, 1, &bufferInfo, 0, nullptr);
|
||||
|
||||
3. 渲染循环中设置颜色数据
|
||||
|
||||
在渲染循环中，你可以设置 uniform buffer 中的颜色数据：
|
||||
|
||||
cpp
|
||||
|
||||
ColorData colorData;
|
||||
colorData.color = glm::vec4(1.0f, 0.0f, 0.0f, 1.0f); // 红色
|
||||
|
||||
// 将数据复制到 uniform buffer
|
||||
void* data;
|
||||
vkMapMemory(device, uniformBufferMemory, 0, sizeof(colorData), 0, &data);
|
||||
memcpy(data, &colorData, sizeof(colorData));
|
||||
vkUnmapMemory(device, uniformBufferMemory);
|
||||
|
||||
4. 在绘制时绑定描述符集
|
||||
|
||||
在你的绘制命令中绑定描述符集，以确保着色器能访问 uniform 数据。
|
||||
|
||||
cpp
|
||||
|
||||
vkCmdBindDescriptorSets(commandBuffer, VK_PIPELINE_BIND_POINT_GRAPHICS, pipelineLayout, 0, 1, &descriptorSet, 0, nullptr);
|
||||
|
||||
总结
|
||||
|
||||
通过这个示例，你已经将一个 uniform buffer 绑定到着色器，使其能够动态设置颜色数据。你可以根据需要进一步扩展这个示例，添加更多的 uniform 或其他类型的资源。如果你有任何疑问或需要进一步的帮助，请告诉我！
|
||||
您说：
|
||||
嘿，是的，你的方法是可以运行的。但是我还是感到困惑，为什么需要这些步骤呢，每一步的作用和原理是什么呢
|
||||
ChatGPT 说：
|
||||
ChatGPT
|
||||
|
||||
当然，理解每一步的作用和原理有助于你更好地掌握 Vulkan 的资源管理。Vulkan 的 API 相对复杂，它的这些步骤主要是为了解决 GPU 资源的管理和绑定问题。让我逐步为你解释每一部分的作用和原理。
|
||||
1. Uniform Buffer
|
||||
|
||||
Uniform buffer 是一种特殊的缓冲区，允许我们将数据从 CPU 传递到 GPU，供着色器在每次绘制时使用。在本例中，我们将颜色数据存储在 uniform buffer 中，并在顶点着色器中引用它。
|
||||
|
||||
作用：保存从 CPU 到 GPU 的数据传输内容。因为 Vulkan 的内存管理是手动的，所以我们需要在内存中分配出 uniform buffer 的位置。
|
||||
原理：GPU 无法直接访问 CPU 内存，Vulkan 通过 vkMapMemory 允许我们将数据映射到统一的内存空间，之后 GPU 就能使用这个缓冲区中的内容了。
|
||||
|
||||
2. 描述符集布局（Descriptor Set Layout）
|
||||
|
||||
描述符集布局定义了描述符集的结构，也就是告诉 GPU 程序每个资源（如 uniform buffer、纹理）应该怎样组织。Vulkan 中描述符集布局可以包含多个不同类型的资源描述符。
|
||||
|
||||
作用：定义了着色器可以访问的资源列表和每种资源的类型，这样我们可以在 GPU 上创建与着色器一致的布局。
|
||||
原理：Vulkan 需要事先知道资源类型和数量，这样它可以在执行命令时优化内存布局和性能。描述符集布局让 GPU 明确知道有哪些类型的数据（如 uniform buffer、采样器等）并匹配着色器的 layout(set = 0, binding = 0) 标注。
|
||||
|
||||
3. 描述符池（Descriptor Pool）
|
||||
|
||||
描述符池是用于管理描述符集的内存池。在 Vulkan 中，描述符集用于将 GPU 资源绑定到着色器，并由描述符池统一分配和管理。
|
||||
|
||||
作用：管理描述符集的内存分配，并允许 Vulkan 高效管理和释放资源。
|
||||
原理：Vulkan 使用描述符池来避免频繁的内存分配和释放。通过池化机制，一次创建多个描述符可以有效地减少内存分配的开销，从而提升性能。
|
||||
|
||||
4. 描述符集（Descriptor Set）
|
||||
|
||||
描述符集是资源到 GPU 的具体绑定。例如，我们在着色器中使用 layout(set = 0, binding = 0) uniform ColorData，描述符集的作用就是把 ColorData 这个 uniform buffer 实际绑定到着色器的 binding 中，使得 GPU 可以访问这些资源。
|
||||
|
||||
作用：将具体的资源绑定到特定的管道（pipeline）和绑定点。
|
||||
原理：描述符集是将特定资源绑定到 GPU 的接口，它通过指向资源（如 uniform buffer 或纹理）的指针来实现数据传递。描述符集使得不同的资源可以快速替换和重新绑定，支持灵活的渲染需求。
|
||||
|
||||
5. 更新描述符集
|
||||
|
||||
创建描述符集之后，我们还需要更新它的内容，将实际的资源（如 uniform buffer）和描述符绑定。
|
||||
|
||||
作用：更新描述符集中的资源引用，比如告诉 Vulkan 当前描述符绑定的 uniform buffer 的位置。
|
||||
原理：描述符集只是一个空的引用表，在更新时，我们指定每个 binding 实际要绑定的数据地址。更新描述符集时，vkUpdateDescriptorSets 命令会在 GPU 内部建立引用，避免在绘制过程中频繁访问 CPU 数据。
|
||||
|
||||
6. 将数据写入 Uniform Buffer
|
||||
|
||||
在 Vulkan 中，将数据传输到 GPU 并不是实时的。我们需要先映射内存，然后将数据写入缓冲区，最后解除映射，这样数据才会从 CPU 缓冲区中传输到 GPU。
|
||||
|
||||
作用：将数据从 CPU 写入 GPU 中的 uniform buffer。
|
||||
原理：Vulkan 使用 vkMapMemory 和 vkUnmapMemory 允许 CPU 访问 GPU 内存（通常 GPU 内存在 CPU 端是不可见的）。通过这种方式，我们可以高效地将数据复制到 GPU 的 uniform buffer。
|
||||
|
||||
7. 绘制时绑定描述符集
|
||||
|
||||
在每次绘制调用时，需要告诉 Vulkan 要使用哪些描述符集。vkCmdBindDescriptorSets 将描述符集绑定到特定的管道，以确保在渲染过程中 GPU 能够访问到这些资源。
|
||||
|
||||
作用：将描述符集和管道绑定，以便在着色器中访问资源。
|
||||
原理：Vulkan 在渲染时会执行大量的管线状态切换，而描述符集绑定会在管道切换时发生，使得 GPU 可以根据描述符集内容动态调整资源。通过 vkCmdBindDescriptorSets，GPU 可以获得 uniform buffer 或纹理等资源的地址，并在着色器中使用这些数据。
|
||||
|
||||
通过这些步骤，Vulkan 确保了 CPU 和 GPU 间资源管理的高效性和灵活性。描述符机制在着色器和 GPU 之间提供了一个清晰的接口，使得资源管理既灵活又高效。
|
||||
|
||||
78
src/x/xmake/xmake bugfix.md
Normal file
78
src/x/xmake/xmake bugfix.md
Normal file
@ -0,0 +1,78 @@
|
||||
---
|
||||
aliases:
|
||||
tags:
|
||||
creation date: 2024-06-26 20:19
|
||||
modification date: 星期三 26日 六月 2024 20:19:59
|
||||
---
|
||||
# debug
|
||||
|
||||
## lua_panda
|
||||
|
||||
- `xmake\core\main.lua`
|
||||
|
||||
```lua
|
||||
local _luasocket = _PROGRAM_DIR .. "/winenv/bin/core.dll"
|
||||
package.cpath = package.cpath .. ";" .. _luasocket
|
||||
require("../winenv/bin/LuaPanda").start("127.0.0.1",8818)
|
||||
```
|
||||
## xrepo-debug
|
||||
EmmyLua
|
||||
https://zhuanlan.zhihu.com/p/658542723
|
||||
```
|
||||
#设置xrepo 权限
|
||||
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
|
||||
|
||||
```
|
||||
vscode
|
||||
```json
|
||||
settings.json
|
||||
{
|
||||
|
||||
"Lua.diagnostics.severity" : {
|
||||
|
||||
"redefined-local" : "Hint",
|
||||
|
||||
"emmy-lua" : "Hint",
|
||||
|
||||
"undefined-global": "Hint",
|
||||
|
||||
"lowercase-global": "Hint",
|
||||
|
||||
}
|
||||
|
||||
}
|
||||
```
|
||||
# clang
|
||||
|
||||
## on_test
|
||||
- `xmake\modules\private\action\require\impl\actions`
|
||||
```lua
|
||||
-- clang编译器需要注掉 test，不然安装第三方库很容易失败
|
||||
-- msvc编译器是官方支持的，无需改动
|
||||
-- test(package)
|
||||
```
|
||||
- engine.h
|
||||
```c++
|
||||
嘿，你知道c++ 的dll ,lib ，exe之间的链接吗？ 当我处理复杂项目时，遇到了困扰。请耐心听，当我提问的时候再回答，并且回答时不要带上代码，好吗
|
||||
|
||||
你先不要回答，请听一下我的问题细节。现在假设有两个c++ 的 dll 项目 engine.dll 与 vulkan.dll。vulkan.dll 依赖 engine.dll。现在engine.dll 里 有一个未导出的全局函数声明 void* GlobalPool(); 和 一个未导出的类型 class ModuleManager{ public: void* GlobalPool(){return ::GlobalPool()}};。
|
||||
|
||||
//engine.h
|
||||
void * GlobalPool();
|
||||
struct ModuleManager{
|
||||
static void* ModulePool(){
|
||||
return GlobalPool;
|
||||
}
|
||||
std::string Name(){
|
||||
return "ModuleManager";
|
||||
}
|
||||
}
|
||||
//engine.cpp
|
||||
void* GlobalPool(){
|
||||
return nullptr;
|
||||
}
|
||||
|
||||
//vulkan.h
|
||||
#include "engine.h"
|
||||
Module
|
||||
```
|
||||
40
src/z/zengine/体系.md
Normal file
40
src/z/zengine/体系.md
Normal file
@ -0,0 +1,40 @@
|
||||
---
|
||||
aliases:
|
||||
tags:
|
||||
creation date: 2024-12-04 13:44
|
||||
modification date: Wednesday 4th December 2024 13:44:50
|
||||
---
|
||||
# 世界
|
||||
|
||||
阶段
|
||||
|
||||
- 组装
|
||||
- 模块化
|
||||
- 运行
|
||||
- module
|
||||
- 模块化设计
|
||||
- subsystem
|
||||
- 世界基石
|
||||
- rule
|
||||
- 规则创建世界
|
||||
- 销毁
|
||||
|
||||
规则
|
||||
|
||||
- 时间规则
|
||||
- 时间一帧一帧的前进
|
||||
- 时间可暂停
|
||||
- 可前进到下一帧
|
||||
- 事件规则
|
||||
- 每帧事件？？？
|
||||
- 突发事件！！！
|
||||
|
||||
# 组装
|
||||
|
||||
|
||||
|
||||
# 运行
|
||||
|
||||
|
||||
|
||||
# 销毁
|
||||
79
src/z/zengine/单例.md
Normal file
79
src/z/zengine/单例.md
Normal file
@ -0,0 +1,79 @@
|
||||
---
|
||||
aliases:
|
||||
tags:
|
||||
creation date: 2024-08-02 09:15
|
||||
modification date: Friday 2nd August 2024 09:15:58
|
||||
---
|
||||
# # 符号
|
||||
|
||||
- static 与 extern 是互斥的，static 缩小了变量范围，不再全局化
|
||||
- static 的作用域是命名空间时，每个引入的cpp文件里都会含有这个static 本地变量
|
||||
- static 的作用域是类时，变量作用域属于类，类是唯一的，static 变量也唯一
|
||||
- static + inline + class 又变回了全局变量，定义唯一
|
||||
- inline 不会报符号重定义的错，而是会合并相同符号
|
||||
|
||||
## 变量定义
|
||||
|
||||
- 定义与声明分离 ::extern
|
||||
- 头文件中 extern 声明
|
||||
- 源文件中 定义
|
||||
- 具有唯一的定义
|
||||
- 定义与声明合并 ::inline
|
||||
- 头文件中 inline 定义
|
||||
- 每个翻译单元都有，但是最终会合并符号为唯一
|
||||
|
||||
## 符号导出
|
||||
|
||||
- 在变量定义的基础上 加上 导出宏 DLL_API
|
||||
- extern + DLL_API 可适配原逻辑
|
||||
- 代价和原逻辑一样，需要头文件、源文件分离
|
||||
- inline + DLL_API , 在引入符号时，不能带定义，只能适用于无参变量
|
||||
- 有参变量，需要拆分，可通过宏拆分在头文件中
|
||||
- DLL_API extern 是不实际导出的，必须要有DLL_API + 声明，才能正确导出
|
||||
|
||||
### LIB
|
||||
|
||||
- 变量会导出到所有依赖库中
|
||||
- 有策略可以保证在dll 和 exe 中唯一
|
||||
- LIB 的依赖库 DLL 必须唯一，其他库必须通过该 DLL 间接依赖LIB
|
||||
- extern 变量唯一，但符号未定义，不能直接用。 inline 能使用，但会导致变量不唯一
|
||||
- 指针类型，可以想办法让变量不唯一，但是变量的值唯一。
|
||||
|
||||
### DLL
|
||||
|
||||
dll 链接时，只能链接导出符号，其他符号会报未定义错误
|
||||
|
||||
- 可以导出变量
|
||||
- 类，函数
|
||||
- 导出接口一致时，才能通过替换dll实现逻辑动态切换
|
||||
|
||||
# 链接
|
||||
|
||||
## 函数
|
||||
|
||||
- 普通函数直接拷贝是合适的
|
||||
- 深拷贝，可能会导致变量不唯一
|
||||
- 含静态变量的函数怎么办呢？
|
||||
- 建议导出，确保变量的唯一性
|
||||
|
||||
## 变量
|
||||
|
||||
- 依然是深拷贝，可能会导致出现其他符号
|
||||
- 变量是要保证唯一的
|
||||
- 需要导出
|
||||
|
||||
## 流程
|
||||
|
||||
- 声明符号
|
||||
- 声明符号，必须结合使用符号才有意义
|
||||
- 使用符号
|
||||
- 使用符号之前，必须先声明符号
|
||||
- 才能知道从何处查找符号
|
||||
- 定义符号
|
||||
- 同时包含了声明与使用符号
|
||||
- 多重定义
|
||||
- 多个相同符号不一定会造成多重定义,链接时是有范围的，范围外的符号不会参与链接
|
||||
- 但是使用符号时，多个相同符号才会导致多重定义
|
||||
|
||||
|
||||
|
||||
220
src/z/zengine/引擎文档.md
Normal file
220
src/z/zengine/引擎文档.md
Normal file
@ -0,0 +1,220 @@
|
||||
---
|
||||
aliases:
|
||||
tags:
|
||||
creation date: 2024-08-16 13:30
|
||||
modification date: Friday 16th August 2024 13:30:09
|
||||
---
|
||||
# 抽象设计
|
||||
|
||||
## 跨平台窗口
|
||||
|
||||
功能
|
||||
|
||||
- 图像渲染
|
||||
- 创建交换链
|
||||
- 图像渲染、展示
|
||||
- 消息处理
|
||||
- 触摸事件
|
||||
- 点击事件
|
||||
- 键盘事件
|
||||
|
||||
## 渲染命令
|
||||
|
||||
- api接口 同步接口
|
||||
|
||||
|
||||
# 代码设计
|
||||
|
||||
## Main
|
||||
|
||||
```c++
|
||||
int API_MAIN(int argc, char** argv){
|
||||
AppImpl app;
|
||||
app.run();
|
||||
}
|
||||
//15277607545
|
||||
```
|
||||
|
||||
|
||||
|
||||
## framegraph
|
||||
### 资源复用
|
||||
- **纹理**（Textures）：
|
||||
|
||||
- 相同大小、格式兼容的纹理可以复用。
|
||||
- 典型的例子是阴影贴图和后处理缓冲区等，这些通常在不同的渲染阶段被用作输入输出。
|
||||
- **渲染目标**（Render Targets）：
|
||||
|
||||
- 多个不同阶段的渲染目标（如颜色缓冲、深度缓冲）可以复用，前提是它们的大小和格式相同或兼容。
|
||||
- **深度缓冲**（Depth Buffers）：
|
||||
|
||||
- 深度缓冲资源也可以复用，如果它们不同时被读写，并且格式一致。
|
||||
- **计算着色器的中间缓冲**（Compute Shader Buffers）：
|
||||
|
||||
- 用于计算着色器的中间缓冲区可以复用，特别是在不同的计算通道或不同的阶段。
|
||||
- **临时数据存储缓冲**（Temporary Buffers）：
|
||||
|
||||
- 如 SSBO（Shader Storage Buffer Objects）和 UBO（Uniform Buffer Objects）等可以用于不同阶段的复用，特别是这些缓冲区通常在一个帧内使用后不再需要，可以在下一阶段复用。
|
||||
|
||||
### 输入输出
|
||||
渲染图像有rendergraph管理
|
||||
其他资源需要有renderpassnode自身管理
|
||||
- 输入交换链图像
|
||||
- 更新交换链图像目标布局
|
||||
- 输入的资源总需要rendergraph 保持状态正确吧
|
||||
- 输出同步信号量
|
||||
|
||||
|
||||
|
||||
## 编辑器模式
|
||||
|
||||
输入是交换链图像，这样就会有两个窗口大小？
|
||||
|
||||
原始窗口变成了编辑器窗口，只有编辑器能用，其他逻辑用的是编辑器的一个子窗口
|
||||
|
||||
- 所以要把和窗口相关的逻辑都修改了吗？
|
||||
- 我希望从非编辑器模式切换到编辑器模式是做加法，尽量不要影响到原始逻辑
|
||||
|
||||
FrameGraph 相关逻辑都变了，一个是正常渲染的交换链图像需要换成纹理。一个是信号量同步逻辑需要修改
|
||||
|
||||
- 增加一个mEditorSurface 表示真实的交换链，而mSurface则替换成子纹理
|
||||
- 替换逻辑需要最先执行，那要怎么执行呢？
|
||||
- 信号量同步逻辑是否需要重构，让framegraph 能够更加自由
|
||||
|
||||
|
||||
|
||||
## FrameGraph
|
||||
|
||||
VkImageUsageFlags
|
||||
|
||||
VkImageLayout
|
||||
|
||||
核心是做好同步工作，需要为输出节点补充自动同步信号
|
||||
|
||||
那么编辑器模式需要做如何改动呢？
|
||||
|
||||
- 获取输入时，编辑器会修改输入
|
||||
- 输出节点会新增一个类型
|
||||
-
|
||||
|
||||
输入
|
||||
|
||||
- 输入阶段可以拆分，就可以让任意目标有机会修改数据了
|
||||
- 交换链获取图像的信号量
|
||||
- 交换链图像
|
||||
- 如果还输入了其他图像，还需要信号量吗？
|
||||
- 如果需要信号量，那么应该封装为renderpass
|
||||
- 所以输入不用关心信号量
|
||||
- 暂时先封装到这里
|
||||
|
||||
输出
|
||||
|
||||
- 渲染完成信号量
|
||||
- 交换链图像布局切换到present
|
||||
|
||||
编译
|
||||
|
||||
- 需要找出所有输出节点
|
||||
- 创建节点时可以填写节点类型
|
||||
- 需要裁剪掉和输出节点不相连的冗余节点
|
||||
- 需要对输出节点进行排序，然后补充信号依赖
|
||||
- 多输出，不需要考虑其他输出，自动依据类型排序
|
||||
- 如果要兼容编辑器，应该怎么设计？
|
||||
- 相当于有两种输出，需要按输出类型，按节点类型双重排序
|
||||
- 然后依然是正常的依赖补充，下一个依赖上一个
|
||||
- 需要做好信号量的依赖
|
||||
- 依据补充依赖 与 输入边进行信号依赖
|
||||
- 那么输入的获取交换链的信号量怎么同步呢？
|
||||
- 需要找到使用node的第一个renderpass？？？
|
||||
- 实际上第一个renderpass只能在输出节点里找
|
||||
- 因为把原始交换链图像作为输入是没有意义，也不合理的
|
||||
|
||||
执行
|
||||
|
||||
- 按node顺序执行，node在gpu端是并行的，通过信号量同步，所以顺序不重要
|
||||
- 判断是否是第一个节点，添加信号依赖？？？
|
||||
- 这样不是特别合理吧？ 为什么不在准备阶段就传递好信号量
|
||||
- 因为执行在render.lib 获取不到信号量对象，信号量是vulkan专属的
|
||||
- 但是这样扩展性就低了，不是吗？
|
||||
|
||||
|
||||
|
||||
## 资源管理
|
||||
|
||||
一条边对应一个资源实例
|
||||
|
||||
资源实例包含了当前需要的资源状态
|
||||
|
||||
需要找到另外一个对应的唯一资源对象，找到当前状态
|
||||
|
||||
需要更新GPU与唯一资源对象 资源状态
|
||||
|
||||
- 例子
|
||||
- 比如我在editor中输入了一个纹理对象细节，需要创建对应的图
|
||||
- ResolveTexture
|
||||
- 找另外一个对象时，发现没图，需要创建
|
||||
- 需要注意三缓冲有三张格式一样的图，如何区分？
|
||||
- 这需要加一个唯一id吧
|
||||
- 唯一资源描述池子
|
||||
- 依据名字+下标找资源？？？资源中包含唯一id
|
||||
- 这里的资源不负责创建对象，仅仅是为了获取描述与唯一id
|
||||
- 资源池子
|
||||
- 通过唯一id找到对应的池子资源
|
||||
- 如果不存在再去创建资源
|
||||
- 那么为什么要两份呢？
|
||||
- 那我还如何共享资源呢？ 难道id 指向0吗？？？
|
||||
- 如果我有两个资源类型一样，如何共享资源
|
||||
|
||||
实现资源共享
|
||||
|
||||
- 依据名字找资源，资源唯一
|
||||
- 依据类型找资源，资源共享
|
||||
|
||||
实现资源唯一
|
||||
|
||||
所以有名字池，类型池，唯一池
|
||||
|
||||
那么如何回收资源呢？更新三个池子就行
|
||||
|
||||
## 资源管理 二版
|
||||
|
||||
资源池
|
||||
|
||||
- 存储了所有图像，包括id，格式、状态、内存等
|
||||
|
||||
名字池
|
||||
|
||||
- 存储名字到id的映射
|
||||
- 依据名字找到唯一的资源池资源
|
||||
|
||||
资源key池
|
||||
|
||||
- 资源复用，如果资源的key一致就用已有的
|
||||
- 如果找不到就新创建一个共享资源
|
||||
|
||||
那么如果出现了资源复用，是否会影响到节点图的拓扑排序和并发
|
||||
|
||||
- 任意资源都能复用吗？？？
|
||||
- 如果出现问题了，需要人为调整资源类型吗？
|
||||
- 资源不再需要name，而是id，资源复用时，可以检测状态，然后切换到另外一个资源吗？
|
||||
- 边也不需要状态，状态存储在资源里
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## renderpass
|
||||
|
||||
考虑多重采样格式一致，有就一定是k
|
||||
|
||||
node
|
||||
|
||||
outs[mask1,mask2,mask3,mask4]
|
||||
|
||||
formats[color1, color2, depth]不行哈，如果这样计算mask会很麻烦
|
||||
|
||||
- color1
|
||||
- resolve1
|
||||
- color2
|
||||
- depth
|
||||
- 别省，简单就行，可是这样mask 也会变大哈
|
||||
@ -21,3 +21,46 @@ modification date: 星期二 30日 四月 2024 10:16:59
|
||||
|
||||
- 着色器参数
|
||||
|
||||
## texture
|
||||
|
||||
通用描述：资源描述、资源实例
|
||||
|
||||
- 导入纹理
|
||||
- 用做着色器输入
|
||||
- 绑定描述符，暂时省略
|
||||
- 用做渲染目标
|
||||
- 依据资源描述构建渲染附件
|
||||
- 自身纹理
|
||||
- 用做渲染目标
|
||||
- 多一步，从资源池中获取资源对象
|
||||
|
||||
### property
|
||||
|
||||
-
|
||||
|
||||
### function
|
||||
|
||||
## renderpass
|
||||
### property
|
||||
|
||||
- key
|
||||
|
||||
- ::texture::
|
||||
- colorFormat[8]
|
||||
- depthFormat
|
||||
- ::flags::
|
||||
- clear
|
||||
- discardStart[8]
|
||||
- discardEnd[8]
|
||||
- samples
|
||||
|
||||
- val
|
||||
|
||||
- pAttachments
|
||||
- pSubpasses
|
||||
- pDependencies
|
||||
|
||||
### function
|
||||
- execute
|
||||
|
||||
- beginrenderpass
|
||||
108
src/z/zengine/资源.md
Normal file
108
src/z/zengine/资源.md
Normal file
@ -0,0 +1,108 @@
|
||||
---
|
||||
aliases:
|
||||
tags:
|
||||
creation date: 2024-07-01 17:19
|
||||
modification date: Monday 1st July 2024 17:19:43
|
||||
---
|
||||
# 资源
|
||||
|
||||
path是地址，地址分为两部分，小区名和房间号
|
||||
|
||||
guid 是身份证
|
||||
|
||||
resourcemanager 是网络平台，资源可通过 guid 交互，前提是对方处于上网状态（已加载）
|
||||
|
||||
filemanager 是地址管理平台，通过path可以找到资源，可能在本地，也可能在外面，也可能加密躲起来了
|
||||
|
||||
那么如何找到想要的资源呢？
|
||||
|
||||
- path
|
||||
|
||||
- 加载文件内的所有资源
|
||||
|
||||
- 如果资源不在呢？
|
||||
- 支持异步下载、加解密
|
||||
- 如果重复加载呢？
|
||||
- 第一个人加载资源
|
||||
- 加载列表会变化吗？当然可以，比如保存场景信息，客户端信息，客户端服务器优先校验信息
|
||||
- 这里不支持热更变化，如有需求，请在上层实现
|
||||
- 那么单个资源会变化吗？
|
||||
|
||||
- suffix
|
||||
|
||||
- .b
|
||||
- 二机制数据
|
||||
- .c
|
||||
- 压缩数据
|
||||
- 其他
|
||||
- 其他数据由loader, resource_manager管理
|
||||
|
||||
- resource_manager
|
||||
|
||||
- 处理meta数据
|
||||
- 调用loader
|
||||
|
||||
- loader
|
||||
|
||||
- 处理各类型数据 纹理、视频、音频
|
||||
- 不同类型可以有不同的数据存储方式
|
||||
|
||||
- file_manager
|
||||
|
||||
- 需要存储各种变体吗？不应该，存储meta就够了，双倍字符串
|
||||
- 如果是不同的变体呢？ 二进制 | 压缩 | HTTP，谁来处理
|
||||
- 变体类型从哪里存储呢？
|
||||
- 先进行读
|
||||
- 一个类型一个类型判断？
|
||||
|
||||
- guid
|
||||
- 如果资源已加载就能找到
|
||||
|
||||
资源，如果知道谁持有，就可以通过guid找对方要，否则需要记住path
|
||||
|
||||
|
||||
|
||||
## URL
|
||||
|
||||
- 路径
|
||||
- 包名
|
||||
- 相对路径
|
||||
- 原始资源
|
||||
- 一个文件一个资源一个meta
|
||||
- 对象资源
|
||||
- 一个文件任意对象资源
|
||||
- 序列化 + 反序列化
|
||||
|
||||
- 代码资源
|
||||
|
||||
|
||||
|
||||
## Loader
|
||||
|
||||
### .obj
|
||||
|
||||
- .obj
|
||||
- .meta
|
||||
- model object
|
||||
- mesh object
|
||||
- mesh object
|
||||
- .asset
|
||||
- mesh property
|
||||
- 如何标记为dirty
|
||||
|
||||
# 问题
|
||||
|
||||
## 如何统一读写数据？
|
||||
|
||||
- 二进制
|
||||
- 文本
|
||||
- 完整文件
|
||||
- 文件分割
|
||||
|
||||
## 如何优化字符串？ 占用空间大，查找、比较 慢
|
||||
|
||||
- 存储
|
||||
- 引用
|
||||
- 比较
|
||||
- 查找
|
||||
|
||||
Loading…
Reference in New Issue
Block a user