Block type lamp instancing

[TheDuckCow]

The idea of this system is to spawn lamp objects into the scene, to avoid needing light emission coming from material nodes. This is desirable because:

1. Lighting from meshes doesn't work in Eevee (without probes) or Blender Internal (not that we necessarily need to support new features for this long gone render engine).
2. Decrease noise in cycles. Mesh lamps add a lot of noise and take more time to render. Approximations using area lamps or even point lamps is often suitable. Average color could be inferred from the emission portion of a given texture.

There are several caveats though. The biggest is the limit on the number of lamps, e.g. the 128 lamps limit in Eevee scene (a single 12x12 grid of glowstone would blow through that limit; how would it work for a lake of lava?).

There are several ways to approach this problem. One way would be a py script that just spawns lamps intelligently in the scene. We can use this thread to brainstorm different ideas for how this could function, following comments can outline the possibilities. It will likely need to be its own function, separate from meshswap and prep materials as the consequence of adding lights may not be expected by users.

Flagging @StandingPadAnimations who has already been thinking about this issue!

[TheDuckCow]

To call out some initial ideas:

• From this prior comment, we could intelligibly group adjacent emitting blocks together with a single (or small number) area lamp. If there's a single block on it's own, then one lamp per block.
• We could also look into removing light sources that don't contribute much(like if they're a certain distance or behind the camera) in the optimizer
• Geometry nodes could be a big player here. I'm not very good with it yet, but this shows we can indeed spawn lamps into the scene - it would be quite feasible in my mind, then, to have a node layout such that any lamps farther away from the camera view are get faded out and then turned off entirely. (not sure yet if we are able to access light emission data from a lamp, since I was initially only able to instance lamps as part of a collection)
  . The "max lights" attribute clearly isn't doing anything yet, but could be used to optimize the number of lights between several different block types (if they are spawned as their own geo nodes objects).

[StandingPadAnimations]

I was thinking of using the mist pass distance to determine distance, for better compatibility with older versions

[StandingPadAnimations]

Also, maybe the distance thing could be configurable so the user can decide the distance(especially if most of the light sources are placed at a large distance from each other). Then if the user is in EEVEE and does a large distance, a warning could be thrown telling the user that they may run into issues).

[TheDuckCow]

An interesting idea - though I don't think mist-style data is available in geo nodes, and I think there's real value in investing in geo node solutions for speed benefits (I'm starting to think about how meshswap could be overhauled to leverage it). It's a fair call to support old versions of blender, but will need to weigh the pros and cons and based on number of users (in all cases, will ensure existing features continue to work wherever they do currently, new features can be limited to blender version X+)

[StandingPadAnimations]

That is a fair point. It would also help encourage users to upgrade to newer versions

[th3pooka]

So here is what i found out. adding lights to a material with using geonodes is pretty easy. and the lights appear in single renders and animation renders. But due to the Eevee limitations on lights. there can only be so many that work while it is instancing. This node set up will work for cycles super easily.

Also as far as i can tell, it has to be sperate geonodes for each material.

[StandingPadAnimations]

EEVEE won't have as many issues in the rewrite, but for now there could be a radius option added

[StandingPadAnimations]

So here is what i found out. adding lights to a material with using geonodes is pretty easy. and the lights appear in single renders and animation renders. But due to the Eevee limitations on lights. there can only be so many that work while it is instancing. This node set up will work for cycles super easily.

Also as far as i can tell, it has to be sperate geonodes for each material.

If the OBJ is one mesh, then what could be done is baking the setup a node group, and joining it with the geometry as needed for each material

Perhaps MCprep could also only add lights for the emissive materials in the scene, reducing the node count

[StandingPadAnimations]

@th3pooka I've taken the node setup and made it a group Node so it's slightly easier to use

[th3pooka]

Oh good idea! that way it can just be inserted into anything with just a couple wires @StandingPadAnimations .
Also @TheDuckCow if your wanted this could be added to prepping the materials or mesh replacement.

[StandingPadAnimations]

There is an issue though: performance

[th3pooka]

Is there a way to reduce the strain with that many lights? Even if you added the lights manually i would think it would have the same strain.

[StandingPadAnimations]

It's not the actual lights. Most of the performance issues come from distributing the points themselves (on my system it takes 2500 ms to update a change), at least in Cycles

Not sure about EEVEE though

[StandingPadAnimations]

Blender 3.x added a way to messure the performance of individual nodes in a geometry nodes setup

[StandingPadAnimations]

@th3pooka I think I know why there's a performance issue. Since the input geometry for the distribute points node is the entire obj, Blender has to distribute a lot of points, even though we only care about emissive materials. That would partially explain the issue in performance for EEVEE

There are 2 ways we can get around this

1. Separate out the emissive blocks and then instance lights on those

Pros:

• Mineways OBJs already do this, so it's much easier to deal with
• The geometry nodes setup is much simpler since we can separate based on the material
• We can separate out only the necessary blocks and anything below a certain depth can be ignored

Cons:

• Separating takes a while
• May be annoying for end-users
• Depth measurement may be difficult

2. Figure out a way to isolate just emissive materials geometry nodes wise before distributing points

Pros:

• Completly geometry nodes, the end-user doesn't realize anything
• We could easily add a max depth for instancing lights

Cons:

• This would complicate the node setup itself as well as adding the node setup itself
• Wouldn't really be useful for Mineways OBJs

Ultimately I think Option 1 is the best since it's the simplest to implement both code-wise and geometry nodes wise

[StandingPadAnimations]

And when I say performance, I mean performance in terms of modifying the geometry nodes settings. The actual lights and viewport are fine, so we could also remain with the current setup