GitHub - Srlion/RNDX: Because drawing ro...

[velvet umbra]

havent looked at the code yet but are you doing AA or supersampling?

[quick sky]

AA

[velvet umbra]

what technique did you use

going through the code very quickly youre calculating the alpha of a corner based on distance or something?

[past prairie]

Nice

[twilit cloud]

EPIC

[north spade]

Well i gotta say i use it everyday it's a revolution for UI in gmod !

Thank you so much 🙏

[quick sky]

damn that looks great

[past prairie]

Gorgeous

[indigo crag]

Great work on the library, really nice!

Since I am using blur for some parts in my UI, I was also particularly interested in the blur feature of it without a rounded shape (even though it's not really the main use-case of the library I guess).

It seems to work great, but during testing I noticed that the performance is actually a bit worse than the current way of drawing blur using pp/blurscreen (which is pretty slow).

I expected that implementing a custom shader for blur would make it possible to make it noticeably faster. Is there just no room for performance improvements, or would it (in theory) be possible to achieve better performance?

[quick sky]

When I benched vs the default gmod one, it was 10% faster, make sure ur testing vs double passing not single passing, as a single pass would look terrible

The reason why both gmod and my version are slow because of
https://gmodwiki.com/render.UpdateScreenEffectTexture

Without calling it, you will have nice blur BUT any drawing behind it won't appear

Eg. Draw a box and then blur on top of it, u won't see the box

I assume there are other ways to optimize it using rendertargets but I haven't put too much time on it

If someone is willing to optimize it while keeping the api 1:1 with how it currently works then I'm up for it

[indigo crag]

compared it with this one: https://pastebin.com/urx4Qvez
I ran both 10 times in HUDPaint and measured the time it took for 1000 calls, and the pp/blurscreen one was slightly faster.

But yeah, I suspected it could be render.UpdateScreenEffectTexture, that's unfortunate.
Thanks for the information though, would be awesome if someone finds a better solution at some point. I never really used rendertargets, maybe that's an opportunity to look into them

[quick sky]

i think when i benched it, it didnt have lots of SetMatFloat calls? i cant remember really, if my pr about batched SetFloat calls it should def be faster

it could also be that my gpu because its highend so it doesnt show that much diff

but i suspect its more about the 18 c calls to just set material params, which can be reduced to just 2 c calls if rubat adds it

but if we get a better method than UpdateScreen thing, it wouldnt matter because its the one that causes the overhead

[indigo crag]

I compared it just out of curiosity

RNDX
With render.UpdateScreenEffectTexture: ~0.083ms
Without render.UpdateScreenEffectTexture: ~0.054ms

pp/blurscreen
With render.UpdateScreenEffectTexture: ~0.072ms
Without render.UpdateScreenEffectTexture: ~0.028ms

Without render.UpdateScreenEffectTexture, the blur looks terrible, but yeah just to see the performance difference
https://pastebin.com/SAbCRCMm

[quick sky]

it really could be because lots of c calls

remove some SetMatFloat calls

keep the w h ones

and remove other ones

it should be faster im sure

as the blur shader i got is actually fast

[indigo crag]

damn I just used the blur in 3D2D and I love it, that's one thing I was never able to do

yeah I'll try with less SetMatFloat calls

[quick sky]

yeah i know, thats why i said i will only approve a pr if it keeps working the same way

[indigo crag]

I commented all SetMatFloat until it broke (6 out of 8 removed):

All SetMatFloat with render.UpdateScreenEffectTexture: ~0.088ms
Less SetMatFloat with render.UpdateScreenEffectTexture: ~0.062ms (vs pp/blurscreen 0.078ms)
= -0.026ms

All SetMatFloat without render.UpdateScreenEffectTexture: ~0.057ms
Less SetMatFloat without render.UpdateScreenEffectTexture: ~0.028ms (vs pp/blurscreen 0.030ms)
= -0.029ms

So the SetMatFloat C calls I was able to remove seem to take about as much time as render.UpdateScreenEffectTexture (that one takes ~0.031-0.034ms)

[quick sky]

yeah they eat a lot, not because they are costly, because they are called 18 times lol

if i used mat:SetFloat that would have been 18 * 2 calls lol

https://github.com/Facepunch/garrysmod-requests/issues/2606

Having this function can save performance on really simple shaders by avoiding the round trips between Lua and C++, as it will only be two trip from 8 trips.

[indigo crag]

I see, hopefully Rubat decides to implement something like that soon (I guess earliest would be the next update after todays one, but that will be a few months again probably)

My hope was that shaders would finally allow a good and optimized implementation for blur... maybe it will at some point

Until then, I guess the best way is just to call the blur function as few times as possible. For 2D / vgui I implemented a solution using stencils that blurs the whole screen and cuts out everything except the bounds of panels that requested a blurred background. Before that, panels with many children with blurred backgrounds would tank my fps from 800 to like 200 xd

I'll have to find a similar solution for 3D2D, but that'll be more complex I guess, I don't really know much about that stuff.

Thanks again though for the library and the insights

[quick sky]

for 3d2d its easy really

limit it to only really close distance

more than the thing u want to draw

and if multiple stuff are going to be drawn, limit it to max number

players shouldnt be able to always notice blur

for 2d i only draw blur for the main frame/panel that contains everything

u reach by max like 5 calls which isnt that much

My hope was that shaders would finally allow a good and optimized implementation for blur... maybe it will at some point
this is incorrect, shaders actually gave better blur than gmod one with better performance, its just a limitation now by source engine/gmod

i could also try to find a single pass blur whicah can make it 2x faster but i couldnt find a nice implementation as i aint a shader expert

[indigo crag]

I mean render.UpdateScreenEffectTexture and SetMatFloat seem to have the largest impact and not much can be changed about those without an update

[quick sky]

how many setmatfloat calls have u left

[quick sky]

w and h only?

[indigo crag]

C_OUTLINE_THICKNESS and C_POWER_PARAM
After commenting C_SIZE_W and C_SIZE_H, everything still seems to work

so only those 2

in RNDX.DrawBlur

[quick sky]

no, sizes should be kept and comment out the others

also there is a trick u can do to have slightly better perf, but i dont know if it will show weird results

[indigo crag]

when removing C_OUTLINE_THICKNESS and C_POWER_PARAM, nothing is drawn anymore

[quick sky]

oh

[indigo crag]

with only C_SIZE_W and C_SIZE_H, nothing is drawn

[quick sky]

for slightly better perf do this

change all $basetexture materials to _rt_FullFrameDepth instead of _rt_FullFrameFB

then swap all render.update calls to be render.UpdateFullScreenDepthTexture

this prob will give u like 20% boost or something

but i dont know how fked the drawings behind it will look, i couldnt find something that would make it look weird, but swapped to fullframefb to be safe

[quick sky]

no this cant be true wtf

it worked fine with me

lemme try some stuff to try to solve the perf issue using rendertargets, will give it a small try

but it wouldnt be same quality even if it worked lol

[indigo crag]

I retried with an original copy, only changed _rt_FullFrameFB to _rt_FullFrameDepth and the the localised render.UpdateScreenEffectTexture to render.UpdateFullScreenDepthTexture at the top of the file

same (broken) result

[quick sky]

idk what the fuck happened to get this effect lol

[indigo crag]

damn haha

[quick sky]

eh couldnt get it to work unforun

we can wait for someone with more knowledge passing by my lib and pushing a pr

[north spade]

Would it be posible to get negative radius like this ?

[quick sky]

are u drawing it using an image or what

[north spade]

Well rn it's a image, but i would love to do it with RNDX

[quick sky]

im not good in math to know would to make it this way tbh

shaders i made from shadertoy with some changes

[north spade]

Let's invoke cursor out there! I'll let you know

[quick sky]

would be nice if u can figure it out, good luck

[north spade]

Well it worked ! I'll see if i can get you a PR

It's perfect

[quick sky]

nice job

[north spade]

Well i got a ultra weird issue where first loading it look like this and if i reload via lua refresh it it goes back well with opacity

Do you know why ?

[quick sky]

i dont understand the issue

[north spade]

Well here is the real resulthttps://cdn.discordapp.com/attachments/1349076959866519692/1355742633959489556/image.png?ex=67ec0378&is=67eab1f8&hm=db57782591fb93305fd2ffdef50f66547d8b9f506eb7206f6d6b45a7d4eb23f2&

it appear only after lua refresh, and i verified the border colors are the same so it came from RNDX but idk why

Maybe it's from my changes, i'll try on v1.2 from github

[floral trail]

Great Library, i wanted to migrate my Circles! stuff, but if I'm not mistaken, it's currently not possible to set the angles of a circle, am I right?

Talking about making smth like this

[north spade]

Only plain circle afaik

[floral trail]

damn

thought i could drop circles! entirely

[quick sky]

I will eventually implement it when I have enough time

[quick sky]

pushed an update that improves the performance by around 25~30%, thanks to jaffies/svetov trick, now its possible to just pass params to the shader using just 2 c calls

next update, should be a faster blur (svetov working on it, not me) then afterwards will add angle start/end and rotation for drawing circles

benchmarks i got on my pc now:

draw.RoundedBox: 0.73529150000002s (Average: 0.0073529885298855ms)
old rndx: 0.2459015s (Average: 0.0024590395903959ms)
new rndx: 0.18606340000002s (Average: 0.0018606526065263ms)

[quick sky]

Working with jaffies on blur thing, we managed to improve blur drawing performance,
its not as strong as before, but i would take that over a slower blur draw

benchmarking using normal methods is very misleading, i was getting like 0.02s after drawing 9999 blur shapes

but at the same time my game was freezing for like 3 seconds, figured that only way to actually bench it, is drawing lots of shapes and check the fps

@indigo crag if u could confirm my results

[indigo crag]

happy to, I'll report back later 👍

[indigo crag]

Those are some real improvements, great stuff, really nice work
pp/blurscreen: average 0.041ms for 10 calls
RNDX: average 0.021ms for 10 calls

I do see what you mean regarding the misleading benchmarking, measuring the average time in HUDPaint results in the above ~51% improvement with RNDX, but for the FPS it's "only" 19% for me (still a great improvement compared the previous version)

[quick sky]

Did you have mcore set to 1?

[quick sky]

As having it on won't show true results too lol

it shows around 10% improvement for me when doing it full screen, which obvs is not a good benchmark, as you will never draw blur on full screen more than once

test with small shapes, which rndx will win by a high margin, because it doesnt blur whole screen then scissors it to whatever you gave it

[indigo crag]

that makes sense, I tried it with the full screen minus a 100px margin all around. It didn't cross my mind how inefficient the non-shader implementation is by blurring the whole screen even when it's not needed

Yeah I tried with and without multicore, the numbers I wrote down were with multicore, I dont remember the results without

I'll do more tests tomorrow

[quick sky]

gmod default one also uses shaders

i get like 10% perf with mcore on

[indigo crag]

Yeah I mean like the shader shader

[quick sky]

but blur will always be expensive no matter u do with shader model 3 lol

if we had a higher version, could do lots of tricks to make it so cheap

[indigo crag]

Someone posted a paper about some especially efficient blurring algorithm on here some time ago, I didn't look into it much, but it seemed interesting
I have to see if I saved it somewhere

[quick sky]

was it jaffies

/svetov

[indigo crag]

hmm don't remember

[quick sky]

cuz he went me one about blur long time ago, and thats what we currently doing

still, shader model 4 allows more tricks to do it more faster

[indigo crag]

Found it, not a paper, a presentation or smth
https://community.arm.com/cfs-file/__key/communityserver-blogs-components-weblogfiles/00-00-00-20-66/siggraph2015_2D00_mmg_2D00_marius_2D00_notes.pdf

[quick sky]

well, the issue rn with double pass, the old way

is u have to fucking call render.UpdateScreenEffectTexture() which is ran on cpu and so heavy

kawase blur, was the one jaffies sent me before ye

we are forced to do single pass, to avoid doing ops on the cpu to draw the blur, which will be heavy for some people with shit pc

[indigo crag]

yeah, I mean right now it's already way way better than what we had previously

[quick sky]

dont forget that it aint stronger blur like one from before

but its still better than gmod blur tbh lol

there is still room for improvement, like using smaller rendertarget which can speed it up by like 50%

[indigo crag]

and being able to use it in 3D2D without any custom implementation, that is soo nice

[quick sky]

yeah i was so surprised when it just worked first time lmao

[indigo crag]

yeah I mean it's already noticeably better than pp/blurscreen , further improvements are just more cherries on top

Thanks again for your great work, also the others that jumped in and helped 🙏

I'll do some more tests tomorrow and start replacing the old blur everywhere

[quick sky]

[quick sky]

ok pushed even more improvements, getting now 125 fps lol

[past prairie]

Damn

[indigo crag]

I can't find the message, but iirc you mentioned a change that traded quality for performance, and now that I compare the new and old version side by side, I think it is very noticeable. There's like this shimmer in contrasty areas. Do you think there might be room for improvement in the implementation? (first pic is latest, second one is release 1.2)

[quick sky]

You can do blur twice and it will look nice

I may add an option to select how strong the blur can be

[indigo crag]

yep I tried twice and it looks nice, but then its as slow as pp/blurscreen more or less

[quick sky]

It will still be faster than default one lol

But will probably be slower than old one

You can just do twice blur for full screen and single blur for small ones

As you won't notice it too much if your drawing it behind something

It will be better as even if you could notice it, it's still better for performance

[floral trail]

Just an update regarding the new angle function on rndx:
I've migrated my hud from Circles! to rndx and the circle is not only rendered much cleaner (Circles! had issue with visible pixels on certain hardware), but performs so much better, these are the results after a quick benchmark before and after the migration

Circles! avg: 0.652ms
RNDX avg: 0.034ms

edit: made the benchmark again but with a cleaner approach in terms of caching, still performs around 95% better, thanks again for making this library and getting back on my issue

[quick sky]

benchmarking like this kinda is terrible, u gotta check the fps with drawing shitton of them