mitchellhansen/Trac3r-rust
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

Piping just the vertex glyph representation first to test the stencil buffer

Browse Source
This commit is contained in:
mitchellhansen
2020-02-22 00:07:58 -08:00
parent bb8144bb01
commit b3e092e25a
70 changed files with 906 additions and 369 deletions
Download Patch File Download Diff File Expand all files Collapse all files

48
notes/Drawables.txt Normal file
View File

@@ -0,0 +1,48 @@
Content-Type: text/x-zim-wiki
Wiki-Format: zim 0.4
Creation-Date: 2020-02-21T22:54:06-08:00
====== Drawables ======
[[/doc/sfml_rust/drawables/index.html|Documentation]]
=== Details ===
Drawables are all able to be passed to the canvas frame to be rendered
The implementation of the Drawable trait is tightly coupled to the data types defined in VertexType and ingested by the canvas frame
Right now I have a couple of types that I'm using:
TextureType(vec, handle)
ImageType(vec, handle)
ColorType(vec)
ThreeDType(vec)
This maps to the drawables I have implemented
compu_sprite : ImageType
polygon : ColorType
rect : ColorType
sprite : TextureType
It doesn't matter, how these objects get the VertexType that it needs to return. Generating them on the fly should be generally OK. It won't scale to very large amounts of sprites. But it's fine for now.

60
notes/Home.txt
View File

@@ -2,67 +2,43 @@ Content-Type: text/x-zim-wiki
Wiki-Format: zim 0.4
Creation-Date: 2020-02-03T22:11:42-08:00
====== Home ======
[[~/source/Trac3r-rust/doc/sfml_rust/index.html|Documentation Root]]
Main Systems:
[[~/source/Trac3r-rust/doc/sfml_rust/sprite/index.html|Spri]][[~/source/Trac3r-rust/doc/sfml_rust/sprite/index.html|te]]
[[VKProcessor:CanvasContainerClasses]]
Docs
[[VkProcessor]] [[~/source/Trac3r-rust/doc/sfml_rust/vkprocessor/struct.VkProcessor.html|===========]]
[[VKProcessor:CanvasState|CanvasState]] [[~/source/Trac3r-rust/doc/sfml_rust/canvas/canvas_state/index.html|===========]]
[[VKProcessor:DynamicVertex|DynamicVertex]] ===========
[[VKProcessor:CompuState|CompuState]] [[~/source/Trac3r-rust/doc/sfml_rust/compute/compu_state/struct.CompuState.html|===========]]
--------------------
=== Trac3r : A program to convert images to 2D toolpaths ===
TODO:
+ Text rendering is half implemented.
+ Need generalized interface for render (image, texture, text)
+ Currently using local copies of a few libraries:
[ ] Text rendering is half implemented.
[ ] Currently using local copies of a few libraries:
shade_runner
vulkano/vulkano-win
vulkano/vulkano-shaders
vulkano/vulkano
[ ] Get a new GPU
--------------------
====== Warming Up ======
[[~/source/Trac3r-rust/doc/sfml_rust/index.html|Documentation Root]]
Docs
[[VkProcessor]] [[~/source/Trac3r-rust/doc/sfml_rust/vkprocessor/struct.VkProcessor.html|===========]]
[[VKProcessor:CanvasState|CanvasState]] [[~/source/Trac3r-rust/doc/sfml_rust/canvas/canvas_state/index.html|===========]]
[[VKProcessor::CanvasFrame|CanvasFrame]] ===========
[[VKProcessor:CompiledShader|CompiledShader]] ===========
[[VKProcessor:CompuState|CompuState]] [[~/source/Trac3r-rust/doc/sfml_rust/compute/compu_state/struct.CompuState.html|===========]]
[[VKProcessor:DynamicVertex|DynamicVertex]] (dead) ===========
[[Drawables]] ===========
Currently I'm getting my bearings again on this project.
=== canvas ===
I made a maybe(?) good change to the heirarchy of the canvas. Hiding the construction of handles from anything outside.
Currently, canvas is separated out to
* A state container: CanvasState
* An Interface class CanvasFrame
* `Managed` objects. Aka, everything that CanvasState holds
CanvasText is just laying around until I use it...
Shader pipeline objects exists in one level of managed
Handle and Buffer objects exists in the base managed level
== Do I commit to the all handles in handles.rs? ==
FYI The shader API is actually pretty badass
load_shader::<GenericShader, ColorVertex2D>("shadername", a, b);
--------------------
So right now it looks like I am having some trouble in the drawing of the CanvasFrame I've crafted.
It is seriously just a Vector of VertexTypes. Which should be fine
==== Context switching ====
So lets finish this text rendering!
I remember using a triangle fan to render the fonts using the stencil buffer swapping
--------------------

6
notes/VKProcessor.txt
View File

@@ -16,12 +16,6 @@ Vk Processors is a do_all class for interaction with the render window, vulkan s
[[./vkprocessor.drawio]]
--------------------
===== Data =====

8
notes/VKProcessor/CanvasContainerClasses.txt
View File

@@ -12,14 +12,6 @@ The Canvas needs to package certain buffers along with their metadata. These tak
All buffers will have a coupled handle type stored in [[/src/canvas/managed/handles.rs|handles.rs]] and a reference to that handle
===== CanvasImage =====
===== CanvasTexture =====
===== CanvasFont =====

22
notes/VKProcessor/CanvasState.txt
View File

@@ -25,6 +25,26 @@ Creation-Date: 2020-02-03T23:30:41-08:00
An object which accumulate frame draws. The State will then parse this list of calls and display them on the screen
--------------------
=== canvas ===
I made a maybe(?) good change to the heirarchy of the canvas. Hiding the construction of handles from anything outside.
Currently, canvas is separated out to
* A state container: CanvasState
* An Interface class CanvasFrame
* `Managed` objects. Aka, everything that CanvasState holds
CanvasText is just laying around until I use it...
Shader pipeline objects exists in one level of managed
Handle and Buffer objects exists in the base managed level
== Do I commit to the all handles in handles.rs? ==
FYI The shader API is actually pretty badass
load_shader::<GenericShader, ColorVertex2D>("shadername", a, b);
--------------------
===== Data =====
@@ -38,7 +58,7 @@ Creation-Date: 2020-02-03T23:30:41-08:00
[[CanvasImage]]
[[VKProcessor:CanvasTexture|CanvasTexture]]
[[CanvasFont]]
[[CompiledGraphicsPipeline]]
[[CompiledShader]]
--------------------

11
notes/VKProcessor/CompiledGraphicsPipeline.txt
View File

@@ -1,11 +0,0 @@
Content-Type: text/x-zim-wiki
Wiki-Format: zim 0.4
Creation-Date: 2020-02-12T23:22:51-08:00
====== CompiledGraphicsPipeline ======
Unfortunately we have to explicitly provide the type to the graphics pipeline if we don't want to fall out into the

44
notes/VKProcessor/CompiledShader.txt Normal file
View File

@@ -0,0 +1,44 @@
Content-Type: text/x-zim-wiki
Wiki-Format: zim 0.4
Creation-Date: 2020-02-12T23:22:51-08:00
====== CompiledShader ======
[[/doc/sfml_rust/canvas/managed/shader/shader_common/trait.CompiledShader.html|Documentation]]
==== Details ====
This trait returns:
* It's pipeline
* It's own assigned handle
* The renderpass it copied from the constructor
==== Implementors ====
**GenericShader**
For basic 2D drawing we just these shaders
* Vertex
* Fragment
We also use a **SingleBufferDefinition**
For vertices, we use a **Triangle List**
We also use the **generic** depth stencil
**TextShader**
Very similar to the GenericShader, but specialized with the depth stencil to draw text.
Still using the shaders :
* Vertex
* Fragment
**SingleBufferDefinition**
**TriangleList**
**DepthStencil** with our own specialized depth stencil values

2
notes/VKProcessor/DynamicVertex.txt
View File

@@ -10,7 +10,7 @@ Creation-Date: 2020-02-04T23:22:14-08:00
===== Details =====
So, the **pipeline** we create over in the **shader** needs to know about the vertex data it will be using. This lines up pretty well because the Shader is precisely the mechanism which would know about this data.
So, the **pipeline** we create over in the **shader** needs to know about the vertex data it will be using.
--------------------