shadow node cube map for point light, memory usage

Discussion area about developing with Ogre-Next (2.1, 2.2 and beyond)


jwwalker
Goblin
Posts: 256
Joined: Thu Aug 12, 2021 10:06 pm
Location: San Diego, CA, USA
x 19

shadow node cube map for point light, memory usage

Post by jwwalker »

I want to start a fresh topic about something that I discussed a bit as a digression from another topic. To recap: I am running into limits on GPU memory use, and a big part of it is the cube map texture used by a shadow node that can handle point lights. This is especially problematic when using PlanarReflections, since each potential mirror creates a compositor workspace instance with its own shadow node.

I was hoping I could fix this by modifying ShadowNodeHelper::createShadowNodeWithSettings to use a global texture (one of those guys with a name starting with "global_") for the cube map. But that doesn't work because a global texture isn't global enough, you still get a separate texture for each compositor workspace instance.

dark_sylinc wrote: Tue Dec 17, 2024 10:10 pm

Modify the Compositor Node so that the Cubemap is provided by you via connect_output. That way you can share all those "tmpCubemap" with all the workspaces. It's eating all your VRAM.

If I'm doing it programmatically instead of in a script, I'm guessing that I'd be calling CompositorNode::connectExternalRT on the shadow node. But I'm not clear on what to pass for the channel number, or whether I need to create the shadow node in some completely different way than using ShadowNodeHelper::createShadowNodeWithSettings.

User avatar
dark_sylinc
OGRE Team Member
OGRE Team Member
Posts: 5448
Joined: Sat Jul 21, 2007 4:55 pm
Location: Buenos Aires, Argentina
x 1349

Re: shadow node cube map for point light, memory usage

Post by dark_sylinc »

Hi!

I keep forgetting to reply to this thread. Sorry. :oops:

You stumbled upon a known issue, unfortunately, which is that Shadow Nodes are only shared within the Workspace, but most of the time it would be far better if they could be shared within all Workspaces. In particular because of this issue where you get countless memory copies.

Unfortunately since Shadow Nodes are a bit of a special case, known solutions to share textures with other workspaces do not apply.

It is possible with a refactor, but that requires to make quite a few changes to OgreNext to solve it.

What I can offer are several possible workarounds:

  1. If you are not using Point Lights, create the shadow node without point light support. The biggest memory drain comes from that.
  2. If you are, try reducing the cubemap's resolution.
  3. If neither option is apply or is enough, perhaps you could be able to merge those workspaces as a single workspace, which would solve the problem since shadow nodes are per workspace.

I'm sorry this answer is frustrating, because it is. This design problem was discovered way too late.

jwwalker
Goblin
Posts: 256
Joined: Thu Aug 12, 2021 10:06 pm
Location: San Diego, CA, USA
x 19

Re: shadow node cube map for point light, memory usage

Post by jwwalker »

dark_sylinc wrote: Sat Jan 04, 2025 10:10 pm

What I can offer are several possible workarounds:

  1. If you are not using Point Lights, create the shadow node without point light support. The biggest memory drain comes from that.
  2. If you are, try reducing the cubemap's resolution.

I can probably do some of that.

dark_sylinc wrote: Sat Jan 04, 2025 10:10 pm

3. If neither option is apply or is enough, perhaps you could be able to merge those workspaces as a single workspace, which would solve the problem since shadow nodes are per workspace.

As I alluded to before, one aspect of this problem is that PlanarReflections::setMaxActiveActors creates a separate workspace for each "actor". If I'm not mistaken, you created the PlanarReflections component, so maybe you have some insight into how one could merge those workspaces?

jwwalker
Goblin
Posts: 256
Joined: Thu Aug 12, 2021 10:06 pm
Location: San Diego, CA, USA
x 19

Re: shadow node cube map for point light, memory usage

Post by jwwalker »

For what it's worth, I made this a formal enhancement request: https://github.com/OGRECave/ogre-next/issues/495