The impact of the Shadow Light plugin and the behavior of Shadow Caster on the CPU on mobile devices

Post reply
0 favourites
  • 11 posts
From the Asset Store
The Device
$6 USD
A futuristic device, can be used as radarscreen, optionscreen, infodisplay, research device, ...
vtrix's avatar
vtrix

  • Good afternoon Ashley, I am currently testing the Shadow Light plugin and the behavior of Shadow Caster. I have a question about the effect on the processor. I'm using penumbra mode, and I've noticed that when you increase the layout size (50000x50000) and add a large number of objects with shadow caster behavior, the CPU load increases.

    Explain in more detail how this plugin works. As I understand it, the plugin calculates shadows for all objects in the layout at once, even for those objects that are already in the shadow?

    If this is the case, it may make sense to review the work of this plugin and make a calculation of shadows from a certain number of objects that are outside the viewport, just as it is implemented with the calculation of collisions in Construct 3 (collision cells). Or add the option to manually set the distance in the plugin at which the condition for casting shadows will be triggered.

    In the last screenshot, I disabled Penumbra mode for clarity.

    I think this will help us save CPU on mobile devices.

  • The easiest way to help is to share a minimal project that demonstrates what you're talking about, and then I can open it and take a look.

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • Ashley I made an example for you. Which shows that the CPU is spent on calculating shadows from objects that are already in the shadow and far beyond the viewport.

    drive.google.com/open

  • If an object is outside of the expected culling area, should it be able to cast shadows into the viewing area?

  • That's right, it's difficult to optimise because if the shadow light was actually in the bottom-right corner of the layout while the view is in the top-left, it might still be casting shadows in to the viewport, so it has to look over a very large area.

  • I understand you Ashley. But if you look at the examples that I made, you can see that the size of the layout and the length of the shadow does not greatly affect the CPU consumption.

    The CPU is affected by the number of ShadowCaster objects. the ShadowLight plugin continues to calculate shadows for objects that are already in the shadow. Please note that I am now talking about Penumbra mode (Light height=0). To optimize, we need to remove the shadow calculation for objects that are in the shadow.

    I understand that this may be a difficult task for you, but 2 years ago I could not even dream of the weights that Construct 3 can now easily do with its large optimization. The community needs to optimize ShadowLight for using shadows on mobile devices.

  • AshleyI'll leave it here. If you have time, read it.

    simblob.blogspot.com/2012/07/2d-visibility.html

  • To optimize, we need to remove the shadow calculation for objects that are in the shadow.

    It's possible that will actually be slower, since it is potentially a lot of extra work to do raycasting and intersection-with-visibility tests, compared to ignoring that and just processing all the objects.

  • > To optimize, we need to remove the shadow calculation for objects that are in the shadow.

    It's possible that will actually be slower, since it is potentially a lot of extra work to do raycasting and intersection-with-visibility tests, compared to ignoring that and just processing all the objects.

    I don't know much about programming but I've seen a lot of games on android with dynamic shadows and it was very fast and without a lot of load on the device (Yes it was done on other engines). Or is it a problem with HTML5 games and you should not expect improvements in this direction in Construct 3 in the future?

  • There are probably a wide range of possible algorithms and approaches to this, and individual games can often pick approaches that are specialised to their specific use case. In Construct we have to make features general-purpose enough to apply to lots of games, and as we have limited resources we can't afford to implement one feature multiple ways so you can choose. So we aim to do a reasonably good general-purpose feature that ought to work well for a decent range of games. If you push it really hard though with extreme cases like this one, it might not work so well, but that's the trade-off we make.

  • There are probably a wide range of possible algorithms and approaches to this, and individual games can often pick approaches that are specialised to their specific use case. In Construct we have to make features general-purpose enough to apply to lots of games, and as we have limited resources we can't afford to implement one feature multiple ways so you can choose. So we aim to do a reasonably good general-purpose feature that ought to work well for a decent range of games. If you push it really hard though with extreme cases like this one, it might not work so well, but that's the trade-off we make.

    I have been studying Construct since 2017, and I constantly meet a request to add a lighting plugin on the forums. At the moment, the ShadowLight and ShadowCaster plugins only work well in your demo projects, but when it comes to implementing in real games, construct users face a huge performance problem, especially on mobile devices.

    Yes, you have made a huge leap in Construct 3, I understand that you have a small team, but you need to listen to the users of construct. This is my personal opinion.

Post reply
  • 11 posts
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)