Hatch fill patterns for the CAD example #116

deprilula28 · 2024-05-31T18:14:31Z

TODO list:

Vulkan has a validation error that I haven't really made sense of
Need to decide how MsdfFillPattern will work (is it going to be fixed like I made it?)

This reverts commit 5629f9f.

Erfan-Ahmadi · 2024-06-03T07:02:25Z

62_CAD/DrawResourcesFiller.cpp

@@ -280,44 +279,50 @@ void DrawResourcesFiller::drawHatch(const Hatch& hatch, const float32_t4& color,
 drawHatch(hatch, color, InvalidTextureHash, intendedNextSubmit);
 }

-void DrawResourcesFiller::addMSDFTexture(ICPUBuffer const* srcBuffer, const asset::IImage::SBufferCopy& region, texture_hash hash, SIntendedSubmitInfo& intendedNextSubmit)
+void DrawResourcesFiller::addMSDFTexture(ICPUBuffer const* srcBuffer, uint64_t bufferOffset, uint32_t3 imageExtent, texture_hash hash, SIntendedSubmitInfo& intendedNextSubmit)


Change ICPUBuffer const* here and in TextureCopy struct to smart_refctd_ptr because we're holding onto the data until we finalize the copies.

Erfan-Ahmadi · 2024-06-03T07:56:27Z

62_CAD/DrawResourcesFiller.cpp

- IGPUCommandBuffer::SPipelineBarrierDependencyInfo::image_barrier_t barriersBeforeCopy[] =
+ using image_barrier_t = IGPUCommandBuffer::SPipelineBarrierDependencyInfo::image_barrier_t;
+ std::vector<image_barrier_t> barriers;
+ barriers.reserve(textureCopies.size());


you decided to do all in 1 barrier.
But remember there was a bug you even found out and mentioned to me before:
If you barrier from srcLayout=UNDEFINED the contents may be lost (implementation dependant based on vk docs) so you may lose other texture contents when uploading only 1 idx
so let's do it one by one for those you only want to copy.

updated comment

Erfan-Ahmadi · 2024-06-03T09:07:54Z

62_CAD/DrawResourcesFiller.h

@@ -24,6 +25,24 @@ struct DrawBuffers
 smart_refctd_ptr<BufferType> lineStylesBuffer;
 };

+// TODO: Better place for this
+enum class MsdfFillPattern: uint32_t


This is more high-level than DrawResourcesFiller, so make that and the factory functions that give you msdfs into a seperate file. this way we can easily copy paste into n4ce and use that there.

We'll have classes/structs related to text placement and msdf generations anyways, it makes sense to put them all in there along with the hashing of the data

When doing it one by one, the validation layer kept claiming that the resource was on the wrong layout, we could make it transition from shader read, and only use undefined for the first transition

UNDEFINED is not a wrong layout.
Your next barrier after the upload was the issue. Because some of the textures were freshly TRANSFER_DST and some of them were old SHADER_READONLY
Doing both the before and after barriers for only the uploading ones shouldn't result in a validation error.
Any transition barrier chain which starts from UNDEFINED, should be pretty straightforward because you're completely overwriting the previous slot

Done (I think commented on the wrong place here)

Erfan-Ahmadi · 2024-06-03T09:37:27Z

62_CAD/main.cpp

+ LRUCache<int, char> hugeCache(50000000u);
+ hugeCache.insert(0, '0');
+


old test code?

Erfan-Ahmadi · 2024-06-03T12:13:52Z

62_CAD/main.cpp

+ {
+ for (int x = 0; x < msdfMap.width(); ++x)
+ {
+ auto pixel = msdfMap(x, glyphH - 1 - y);


AFAIK this msdfgen::pixelFloatToByte is a multiplication by 256 so UNORM turns to UINT.
but your msdf textures are UNORM... something doesn't feel right here.

Ok my bad, brainfart! it should be filled with uint8_t

BUTTTT you can probably leverage format conversions WHILE uploading with our image upload utility. (change srcFormat to RGBA8F in the input params)

@devshgraphicsprogramming can you verify this? I forgot the vk format stuff regarding conversions.

Erfan-Ahmadi · 2024-06-04T08:33:47Z

62_CAD/MSDFs.h

+ break;
+ }
+
+ return textureTypeHash ^ (textureHash << 1);


use core::hash_combine

Erfan-Ahmadi · 2024-06-04T08:34:40Z

62_CAD/MSDFs.h

+ textureHash = std::hash<uint32_t>{}(uint32_t(s.fillPattern));
+ break;
+ case MsdfTextureType::FONT_GLYPH:
+ textureHash = std::hash<uint32_t>{}(s.glyphIndex);


instead of glyph index, take glyphHash which will be hashed by our text glyph generator tool later on. (it depends also on the font and the font settings and flags you pass into FT to generate those glyphs)

Erfan-Ahmadi · 2024-06-04T08:34:57Z

62_CAD/MSDFs.h

+ textureHash = std::hash<uint32_t>{}(uint32_t(s.fillPattern));
+ break;
+ case MsdfTextureType::FONT_GLYPH:
+ textureHash = std::hash<uint32_t>{}(s.glyphIndex);


then this path becomes textureHash = s.glyphHash

Erfan-Ahmadi · 2024-06-04T09:29:36Z

62_CAD/DrawResourcesFiller.h

+ uint32_t3 imageExtent;
+ std::vector<CPolyline> polylines;
+ };
+ void addMSDFTexture(std::function<MsdfTextureUploadInfo()> createResourceIfEmpty, texture_hash hash, SIntendedSubmitInfo& intendedNextSubmit);


few edits I suggest:

function returns the index/slice in our texture we have allocated. this way we don't have to look up in the cache if we need to work with the index immediately (for example text)

Lambda is good, another choice is to getMSDFTextureIndex(hash) so it can be looked up from outside, yours is better in a way that avoids checking the cache twice (one from outside, one inside in "cache->insert")

Reuse the Lambda function inside the other one to avoid duplicate code. we might want to use that as a convinience function later because for the 32x32 msdf hatch fill shapes it makes more sense to keep them around in cpu memory in a CPUBuffer array, ready to use and not have to go through the whole msdf generation everytime we can't find it in cache (it's fine in the example rn, I'm talking about n4ce codebase)

Erfan-Ahmadi · 2024-06-04T09:39:10Z

62_CAD/MSDFs.cpp

+ float scaleY = (1.0 / float(glyphExtents.y)) * glyphH;
+ msdfgen::generateMTSDF(msdfMap, glyph, MsdfPixelRange, { scaleX, scaleY }, msdfgen::Vector2(0.0, 0.0));
+
+ // TODO: Optimize this


as per discussions in discord, you can remove the for loops and set srcFormat in image upload utility to RGBA8_SFLOAT to get the conversion while memcpying to staging memory with our image filters (all happening inside the util)

62_CAD/common.hlsl

Erfan-Ahmadi · 2024-06-04T09:40:16Z

62_CAD/fragment_shader.hlsl

+ return max(min(r, g), min(max(r, g), b));
+}
+
+float screenPxRange(float2 uv) {


can you explain this function to me?
more explicitly why divide by float2(globals.resolution);

It's basically this:

On screen size of the quad / MSDF Resolution * MSDF Pixel Range

(From msdfgen docs: screenPxRange() represents the distance field range in output screen pixels. For example, if the pixel range was set to 2 when generating a 32x32 distance field, and it is used to draw a quad that is 72x72 pixels on the screen, it should return 4.5 (because 72/32 * 2 = 4.5). For 2D rendering, this can generally be replaced by a precomputed uniform value.)

I did it using the 3D path as we have to support transformations on the text (due to DWG and such), so this allows it to be more flexible (and only costs one fwidth)

I think it should be / float2(32, 32); or the msdf texture size instead of float2(globals.resolution);
let's double check the math, so we're trying to get from

from [0, 1] of msdf sampled value to [-0.5, 0.5] by (sd - 0.5)

then we multiply by MsdfPixelRange to get it to [-MsdfPixelRange/2, MsdfPixelRange/2] and that is basically the
distance in glyph texture units (because the spectrum/range from lowest to highest sdf is MsdfPixelRange! the input to msdfgen!)
now we need this distance in uv units:

we divde by (32,32) or GetDimensions(msdfTexture) to get the distance in uv units

now, how to turn uv distance into actual screenspace distance?! that's the main question!

here it uses fwidth to do that because it shows you the rate of change of both U and V with regards to x and y on the screen and the inverse of that gives you the screenspace size of the
so if everything is aligned (u with x and v with y) it becomes 1.0 / abs(float2(ddx(u),ddy(v)))

1/ddx(u) gives you the horizontal size of the glyph box in screen pixels!
and 1/ddy(v) gives you the vertical size of the glyph box in screen pixels!
If you're not sure why read the thought experiment below:

++++
Optional Read
ddx(u) tells you the rate of change of u per pixel in x direction
if you think about it ddx(u) is basicaly dU/dScreenPixel (if you go 1 pixel how much does u value change?)
and 1/ddx(u) is dScreenPixel/dU and gives you the inverse rate of change (if you go by 1 units in u how many units in screen pixels? ---> width pixels!)
++++

But fwidth is just used as an approximation. float2 fwidth = abs(ddx(uv) + ddy(uv))
small note: ddx(uv) is a float2, it's computing ddx for both u and v.

Now that you understand this, you get why is the / float2(globals.resolution) is buggy and why you need to have different functions for this for 1. glyph boxes 2. hatch fills
and if you fix this you are going to see these bugs fixed:

some hatch fills msdfs being buggy or non connected

text being too blurry when zooming in

A. How to handle this function for "Hatch Box Fills"?
for hatch box fills we cannot use this fwidth(uv) because we're doing repeat sampling of a 8x8 msdf onto the screen! (that's ptobably you caused a double bug by the wrong division, two wrongs sometimes make a right :D)
so for hatch fills it's float2 screenTexSize = float2(8,8) or whatever the fixed size for them is!

B. How to handle this function for "glyph boxes"?
for glyph boxes (or I think you call the fontglyphs in other branch), the screenspace size of the glyph box can be computed in vshader and get passed along! no need for fwidth, and it will result in a nice shape with any rotation because the sdf would be exact as the last step (4th one) above get's you correctly from uv distance to screenspace distance, then you can use that to compute opacity or whatever

…ping in the loop itself)

…demo

Erfan-Ahmadi · 2024-06-06T05:00:05Z

62_CAD/MSDFs.cpp

+
+ float scaleX = (1.0 / float(glyphExtents.x)) * glyphW;
+ float scaleY = (1.0 / float(glyphExtents.y)) * glyphH;
+ msdfgen::generateMTSDF(msdfMap, glyph, MsdfPixelRange, { scaleX, scaleY }, msdfgen::Vector2(0.0, 0.0));


why are you generating MTSDF (it has true sdf in alpha channel) but don't use it? you can just make the MSDF textures RGB and generateMSDF instead of MTSDF

It was for debugging, easier to know what's wrong with the texture in render doc that way, but I'll change it over when everything is working

Msdfs are harder to understand and read

Or you can just use msdf.exe, generate the msdf with cmdline and compare

I can't use that with the hatch fills, since they're not exactly font files, but I'll change it over to msdf only when everything works

…es to not bother with DLLs, mark TODO regarding Nabla Text Rendering extension for future

…3rpdarty freetype + msdfgen-ext directly without the extension enabled

…-1-3

Erfan-Ahmadi · 2024-06-18T07:05:32Z

62_CAD/vertex_shader.hlsl

+ // TODO needs to handle rotations as well, probably from curve box code
+ const float2 ndcAxisMin = screenTopLeft;
+ const float2 ndcAxisMax = screenTopLeft + screenDirU + screenDirV;
+ const float2 screenSpaceAabbExtents = abs(ndcAxisMax - ndcAxisMin) * float2(globals.resolution);


Just use lenght(screenDirU) and length(screenDirV) , to get the length of the sides

Also, not aabb anymore. Use box or obb

Erfan-Ahmadi · 2024-06-18T07:08:14Z

62_CAD/vertex_shader.hlsl

+ const float2 screenDirV = (float2) transformVectorNdc(clipProjectionData.projectionToNDC, dirV);
+
+ float2 corner = float2(bool2(vertexIdx & 0x1u, vertexIdx >> 1));
+ const float2 coord = screenTopLeft + corner * (screenDirU + screenDirV);


This should be topLeft + corner.x * dirU + corner.y * dirV
Now rotation is handled

Erfan-Ahmadi · 2024-06-18T07:18:34Z

62_CAD/fragment_shader.hlsl

@@ -372,6 +372,23 @@ float32_t4 calculateFinalColor<true>(const uint2 fragCoord, const float localAlp
 return col;
 }

+// TODO: place this MSDF code elsewhere


These can be in nbl/hlsl/text_rendering/msdf.hlsl within correct namespace.
(Fix indentation please with the brackets)

Do this when you've finalised working on these functions cause otherwise built-ins have to rebuild each time you make a change to the hlsl built-in.

Don't forget to document what the different input params and terms such as msdfPixelRange means and how it's related to the msdfgen lib (you can copy paste and quote from the lib above these functions)

Erfan-Ahmadi · 2024-06-18T07:21:39Z

62_CAD/fragment_shader.hlsl

+ return max(min(r, g), min(max(r, g), b));
+}
+
+float screenPxRange(float2 screenSpaceSizePixels, float2 distanceFieldSizePixels) {


Let's not bring this function to the builtin hlsl header, because it's application dependant. Let's be flexible like msdfgen about user providing a screenPxRange. But remember to document clearly so there is no confusion about what screenPxRange is

It is the value used to convert the distance values in the msdf texture to distance in screen space. In other words it's DistanceInScreenSpace/DistanceInMSDFTextureSpace, the larger the glyph (or more zoomed in) the larger this value is.

Erfan-Ahmadi · 2024-06-18T09:24:03Z

62_CAD/common.hlsl

@@ -197,6 +211,8 @@ NBL_CONSTEXPR uint32_t InvalidTextureIdx = nbl::hlsl::numeric_limits<uint32_t>::
 NBL_CONSTEXPR MajorAxis SelectedMajorAxis = MajorAxis::MAJOR_Y;
 // TODO: get automatic version working on HLSL
 NBL_CONSTEXPR MajorAxis SelectedMinorAxis = MajorAxis::MAJOR_X; //(MajorAxis) (1 - (uint32_t) SelectedMajorAxis);
+NBL_CONSTEXPR float MsdfPixelRange = 4.0;
+NBL_CONSTEXPR float MsdfSize = 32.0; // TODO: Should this be dynamic?


nope, but make sure to use MSDF all caps + use that on the c++ side as well

Erfan-Ahmadi · 2024-06-18T09:55:29Z

62_CAD/fragment_shader.hlsl

+float msdfOpacity(float3 msd, float2 screenPxRangeValue) {
+ float sd = median(msd.r, msd.g, msd.b);
+ float screenPxDistance = screenPxRangeValue * (sd - 0.5);
+ float opacity = clamp(screenPxDistance + 0.5, 0.0, 1.0);


Don't output opacity, output screen space distance and do AA with smooth step like we already do.
This is literally a sdf function, but reads from texture

deprilula28 and others added 25 commits April 15, 2024 19:23

Add text rendering functionality on the CAD example

ca0c525

Work on uploading MSDF texture in the example

f24c668

Small fixes

5393e8a

Attempt at showing the MSDF (didn't work)

bb63791

Work on drawing hatch fill patterns with MSDF

c7b3d06

Patch MSDF code

295af73

temp code to show text positioning

5629f9f

Revert "temp code to show text positioning"

54d20aa

This reverts commit 5629f9f.

Work on fixing hatch fill code

8ca5f3a

Merge branch 'master' into text-rendering-example-vulkan-1-3

255eb80

Attempts to test issue

c6bc353

Recreate issues in example 21 unit test

fa1f8d9

use unique_ptr for lrucache

d888b8f

Add IndexAllocator & implement std unique ptr for lru cache

a60cf35

Work on todos

112ffb7

Work on testing the stuff

db1af36

Fix issues

19fc2a5

Implement fixes to MSDF uploading & test eviction

35160de

Improvements & fixes

35e7535

Fix all styles and demo that shows them off

6759ecd

Showing off bg & fg colors

eb6dbde

Implement hashing for patterns

c3e0c1a

Refactor the code for the msdf shapes being duplicated

50e8fd6

Change resource barrier to change the resource

a2a526c

Add text rendering using MSDFs

87950b6

Erfan-Ahmadi reviewed Jun 3, 2024

View reviewed changes

Erfan-Ahmadi reviewed Jun 4, 2024

View reviewed changes

62_CAD/common.hlsl Show resolved Hide resolved

Erfan-Ahmadi reviewed Jun 4, 2024

View reviewed changes

deprilula28 added 6 commits June 4, 2024 14:09

Use RGBA32F to RGBA8UNORM conversion using utilities (temporarily cap…

b6c5ace

…ping in the loop itself)

PR reviews

a30c6c1

PR reviews

56eec1f

Fix PR reviews

adec6bd

Merge branch 'text-rendering-example-vulkan-1-3' into text-rendering-…

7e73971

…demo

Work on demo

eb1b1f5

Erfan-Ahmadi reviewed Jun 6, 2024

View reviewed changes

deprilula28 and others added 10 commits June 7, 2024 00:14

Fix problems with MSDF text and line style comparator

8d8e8a7

Small change

028f0d4

link Freetype + MSDFGEN-ext directly to CAD example as static librari…

1ea8f2d

…es to not bother with DLLs, mark TODO regarding Nabla Text Rendering extension for future

make a room for Text Rendering extension for future - by default use …

78c431c

…3rpdarty freetype + msdfgen-ext directly without the extension enabled

WIP corrections

f97093b

Fix issues with msdfgen shape generation & screenPxRange

f3f92f1

Merge branch 'text-rendering-demo' into text-rendering-example-vulkan…

e2b192c

…-1-3

Start TextRendering extension rework

4102b91

Use new TextRenderer extension funcions

7bc76c7

Test SingleLineText API

d69ca14

Erfan-Ahmadi reviewed Jun 18, 2024

View reviewed changes

		LRUCache<int, char> hugeCache(50000000u);
		hugeCache.insert(0, '0');

Hatch fill patterns for the CAD example #116

Are you sure you want to change the base?

Hatch fill patterns for the CAD example #116

Conversation

deprilula28 commented May 31, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Erfan-Ahmadi Jun 3, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Erfan-Ahmadi Jun 3, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Erfan-Ahmadi Jun 5, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Erfan-Ahmadi Jun 6, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Erfan-Ahmadi Jun 18, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Erfan-Ahmadi Jun 18, 2024 • edited

Choose a reason for hiding this comment

deprilula28 commented May 31, 2024 •

edited

Erfan-Ahmadi Jun 3, 2024 •

edited

Erfan-Ahmadi Jun 3, 2024 •

edited

Erfan-Ahmadi Jun 5, 2024 •

edited

Erfan-Ahmadi Jun 6, 2024 •

edited

Erfan-Ahmadi Jun 18, 2024 •

edited

Erfan-Ahmadi Jun 18, 2024 •

edited