Nice to hear I will keep an eye out for the v1 ^^
I still have no idea what “deferred rendering, global illumination” means ;p
Sounds like it could be neat.
I will keep an eye out for the v1 ^^
awesome! tysm : )
I made it camera independent in the recent version
but it doesn’t quite work w/ the postprocessing pipeline, Ion think any custom post process does?
Figuring out what’s up w/ that, will let you know when I have it working : )
edit: my bad it does work, skill issue, I didn’t rtfm that I needed to make a render effect first : /
edit 2: well it works but for multiple views it only calculates pbr lighting correctly for one cam : /
I still have no idea what “deferred rendering, global illumination” means ;p
global illumination is → u get lighting at places only bounced light can reach, babylon alr has that : )
that’s a different thing tho
Deferred rendering is → you do the lights in your scene as a postprocess, so it fast as frikk : D
Alright bois,
- I changed our
int
texturesfloat
so fewer texture reads now, and no gymnastics to convert it to float inside the shader. - Wrapped the texture data in 2D so now max lights are not limited by
maxTextureSize
butmaxTextureSize * maxTextureSize
- made it usable now in multiple viewports w/ multiple cameras and stuff
- updating the Storage Texture is expensive kinda, so there’s a new param
autoUpdate
, make itfalse
if your lights are kinda static and don’t need to be updated per frame. - made some other optimisations like caching some arrays (GC was taking a toll)
- added a param w/ that you can pass in
PostProcessOptions
if you want the lighting to be at a different resolution or w/e
I think this is a good spot to call v1. I’m gonna change it’s version number to 1.0 this weekend if nothing else comes up.
Yay for v1
May have found an improvement.
I am looking at the 1000 suns demo. When I move the camera, frame rate tanks You can see in the inspector that “Rendering” goes from ~1ms to up to 35ms.
I then went over to DevTools (or whatever it is called in Firefox) and made a snapshot:
If I am reading this right, getDataBuffer seems to take huge chunks there, followed by t.prototype.update
(perhaps the data texture?).
It looks like it. This is super dirty but please see: https://playground.babylonjs.com/#WZSKV4#2
I am just caching the Float32Array. If I now go batshit crazy with camera movement, I still cannot get Rendering time over 10ms. And here is the perf profile (looks better, too):
What do you think?
(N.B. idk why there is suddenly a “dom worker”??)
If I am reading this right, getDataBuffer seems to take huge chunks there, followed by
t.prototype.update
(perhaps the data texture?).
You’re so right making that buffer so many times was taking a lot : O
I am just caching the Float32Array. If I now go batshit crazy with camera movement, I still cannot get Rendering time over 10ms. And here is the perf profile (looks better, too):
sickk : D
Updated the lib w/ the fix!
followed by
t.prototype.update
(perhaps the data texture?).
yeah that’s the data texture update : / If you keep the TOTAL_LIGHTS_ALLOWED
low I think it should be faster. in the PG it’s 50k
which is prolly overkill xD
(N.B. idk why there is suddenly a “dom worker”??)
I have no clue I saw the same thing lmao xD
The lib should be updated now so the same PG from earlier should work w/ the fix : D
Let’s go for V1! Very cool to see the project getting better
I am going to start using it in my project to see if I have any issue!
v2! : )
Added rect area lights ^^
full credit to
Ooh, sweet. Out of nothing, big fat new feature thanks for sharing
I noticed something: fps drops heavily depending on camera radius:
Really nice If I am not mistaken you got area lights before BabylonJS itself!
But what about deffered shadows ?
I noticed something: fps drops heavily depending on camera radius
tysm for letting me know! I’ll check it out : D
But what about deffered shadows
?
I don’t think you can have deferred shadows? you’ll need shadow maps anyway : )
If I am not mistaken you got area lights before BabylonJS itself!
ye but also, I didn’t have to care about (case in point) shadows, integration into materials, backwards compatibility of babylon api, un-compromised quality, having every last drop of perf (I’m so lucky to have Joe_Kerr help w/ this fr), it’s prolly still somewhat buggy and lacking and most of the code here is simply yoinked from the repo I shared lol
fwiw tho feels good to expand this into smth more complete and potentially useful : )
Yeah we can’t escape shadow maps haha. I meant applying the shadows at the same time as the deferred lighting stage. More generally I am wondering if your plugin supports shadow mapping because it was not mentionned before
Even though you made it and it works so great work
More generally I am wondering if your plugin supports shadow mapping because it was not mentionned before
Oh yeah nope, the lib doesn’t support shadows.
The reason was that the light sources are supposed to be used as small localized lights w/ efficiency above all else.
that’s why every light, (point or the new rect area) has a range attribute that should be kept as low as possible for culling and some shader benefits.
but if you think that shadows might be a necessity, I’ll try to add them in the next major update : )
Haha no pressure! I have no idea if they are a necessity to be honest, I don’t know enough about deferred rendering right now, and have no idea how shadows are handled in these kind of renderers.
And I have still plenty to play around with the current version ^^
We have area light support since a couple weeks thanks to @srzerbetto so we were first lol
dammit! xD I’ll win next time >:D
that’s so sheesh tho ggs : )
I stand corrected haha Area light for everyone !