TarVK / pixi-shadows

Adds dynamic shadows to PixiJS
https://tarvk.github.io/pixi-shadows/dist/
MIT License
53 stars 14 forks source link

Feature Request: Buffer border #20

Open g-chanet opened 2 years ago

g-chanet commented 2 years ago

Hi, I'm currently using pixi-shadow with a pixi-viewport plugin and unfortunately I can't integrate a tempon area to manage off-screen lights and shadows, would it be possible to add a feature to define an offset rendering to fix it? thank you!

TarVK commented 2 years ago

Could you elaborate the issue a little bit? I'm not quite understanding the issue, but I also have no experience with pixi-viewport. If the problem is specific to this library, I may be able to play around and make a pixi-viewport example, and fix any potential issues with this library to make them work together.

g-chanet commented 2 years ago

image image

Currently the masks are calculated when displayed on the screen, but when they are off the screen, they are not calculated for lights collisions, I believe that increasing the render size of the mapmask or to render the in entirer could fix this problem, thanks

TarVK commented 2 years ago

Right, thanks for the images. This is not actually a scenario I've considered in the past, and I'm not entirely sure how to solve, but may have an idea. It's quite a big oversight on my end to not consider this, I think this will be a common problem, thanks for bringing it up.

The first thing that comes to my mind, is to create padding on the caster texture around the shown viewport, based on the existing light sources and their radius. Light sources that don't reach into the screen don't have to be considered at all. But all space between a light source and what can reach the viewport should be part of the caster texture.

From your understanding of this library, do you think this would solve your issue?

g-chanet commented 2 years ago

That's what I thought at first but I realize that using your plugin with pixi-viewport brings another problem. for example, let's imagine that for a line used for mask, when the zoom is at its furthest, the line can go below 1px. and the refore no longer cast all lights collisions. I would lean more towards a local rendering of the filter calculated in relation to their localtransform and applied with the offset and scale sufficient to be superimposed on the viewport. Unfortunately I don't know myself enough about shaders to be sure of what I'm saying but I think it's a lead. But your plugin are very interessing, great job!

TarVK commented 2 years ago

Hmm I'm not sure that's such a good idea. If I understand things correctly, that would mean that the further you zoom out, the more pixels have to be rendered to the caster texture and mask? Because if you render everything at a fixed local scale, but want to render everything on the viewport, you will simply need a bigger texture if there's more in the viewport. I think that would really tank performance really quickly. The padding already doesn't sound too great, but there you can at least assume the light range is fixed by something in your application. The zoom however may be huge. I think the additional problem you describe is just one that we would have to live with.

If you want to prevent those issues, a more robust way for 2d shadows could be used instead of my pixel based approach:

This approach is a bit more involved and complex, and probably requires good data structures to run efficiently in larger scenes. It's not something I'm planning to implement, but it probably makes for a better solution because it's numeric and not discretized like the pixel approach.