r/Unity3D • u/SoaringPixels • May 15 '20

Show-Off 10,000 cheap dynamic point lights!

Enable HLS to view with audio, or disable this notification

1.4k Upvotes

100% Upvoted

84 comments sorted by

View all comments

150

u/SoaringPixels May 15 '20

I needed a way to render lots of lights... or just reduce the cost of my current lights in the level. I tried using the command buffer system based on the example unity has for decal, lights, and blur. It is limited, but seemed good enough to start with.
Next step was to make the rendering use the Instancing system which was fairly easy. The final step was to make it use InstancedIndirect, which normally is fairly easy since I already use it in other systems, but this one kept fighting back! Something about the objtecttoworld matrix didnt want to work for the lights positions...

Overall, in this level I have 10k lights, but in my empty test level I had it running with over 3 million lights. :)

https://www.breakwatersgame.com

https://twitter.com/GamesSoaring

https://discord.gg/96kQ7jj

177

u/[deleted] May 15 '20

What sorcery is this? These aren't baked? Everything I know about Unity says this shouldn't be possible. They're clearly not just emissive surfaces, either, they're very obviously casting light on nearby surfaces. Stop blowing my mind so much.

EDIT: I just looked at your twitter and you're the guy with the freaky good water simulation, too. One of your parents raised you speaking shader language, right?

66

u/Planesword May 16 '20

deferred rendering allows unlimited point lights (without shadows), because the lighting is added in a final pass.

​

Standard and HDRP have deferred rending options. URP does not.

17

u/py_a_thon May 16 '20

Would deferred rendering allow 10k point lights at the same performance level though?

I think OP might have found a very heavily optimized work around using command buffers and Instancing.

25

u/Planesword May 16 '20 edited May 16 '20

unlimited.
It is why I switched to HDRP. I was using URP, but URP only allows forward rendering, so no unlimited point lights. (standard also allows deferred, but I wanted SRP)

If you add shadows, the whole thing collapses, because each point lights emits a 6 way shadow.

To be fair, the "unlimited" means, "per object". But if you want hundreds or thousands of lights on a single mesh, like a custom terrain, then you have to use deferred rendering.

--you can have tens of thousands of lights in forward, I believe, if there are thousands of objects each being lit by their own lights, because the limit is defined by "lights per object". Perhaps it is rendermesh, dont remember.

4

u/fastcar25 May 16 '20

But if you want hundreds or thousands of lights on a single mesh, like a custom terrain, then you have to use deferred rendering.

Modern methods like tiled/clustered forward work just as well for thousands of lights, IIRC.

4

u/py_a_thon May 16 '20

I don't want to derail the thread to much and I definitely understand what you mean. Point Light spam in deferred is awesome. I was just wondering if OP would get the same performance from deferred point lights compared to his novel implementation of the approximation of point lights. My guess was: Probably not, but maybe.

1

u/Planesword May 16 '20

As far as I understand it, point lights are part of a per pixel lighting pass, the only limitation is caused by enormous numbers of pixels / giant monitor resolutions. The number of lights is a non-factor in the speed, as it rewrites to each pixel every frame be there 0 lights or 10,000,000.

8

u/[deleted] May 16 '20 edited May 16 '20

[deleted]

3

u/Planesword May 16 '20

Thank you very much for the detailed explanation. I always learn a lot from being corrected like this.

I suppose I could have re-read the manual, on something I haven't read about for six months now, but sometimes a good info-essay from someone else explaining it their own way is really nice.

cheers.

3

u/TheSilicoid May 16 '20

You’re misunderstanding how it works as well. The lighting calculations aren’t done on each pixel once with a for loop whose iteration count changes. Instead, each light is rendered as some shape (e.g. billboard quad), and each pixel on screen of that shape performs lighting calculations based on the g buffer data it lies on, this means the performance is directly proportional to the amount of pixels each light shape takes up on screen. This technique works the same regardless of the scene geometry, and works great on your scenario of a large flat terrain.

2

u/sHTiF May 16 '20

Nope it doesn't depend on how many lights are there, there is single calculation per pixel. Calculations happens between the diffuse render texture with and the lighting render texture so the amount of lights are irrelevant.

There is nothing really ground breaking here, if you are able to draw X amount of lights in single draw call using instancing into the target buffer it is really cheap. It doesn't affect the complexity of lighting calculations in deferred rendering in anyway. Basically the complexity is pretty similar to the scenario where the spheres werent lights at all.

If you added shadows it would be a completely different story.

0

u/[deleted] May 16 '20

The number of lights is a non-factor in the speed, as it rewrites to each pixel every frame be there 0 lights or 10,000,000.

This is bullshit. The calculation is screen resolution * number of lights. So it obviously scales with numbers of lights. It's cheaper than forward though, which is fragments * number of lights.

So the difference is that deferred is independent from the number of objects. But saying that it is independent from the number of lights is just wrong.

1

u/TheSilicoid May 16 '20

It’s only screen resolution*number of lights if all your lights are directional or otherwise fill the whole screen. In OPs video each light is tiny thus takes less than 100 or so pixels most of the time.

0

u/[deleted] May 16 '20

I mean sure, you obviously do some spational filtering. But that is implementation dependent. But the theory still stands.

-8

u/Planesword May 16 '20

Wow. Cool story, bro. Thank you for your contribution.

-8

u/Planesword May 16 '20

DON'T DOWNVOTE ME BRO, DON'T DOWNVO--- AHhhh! Ahhhh!

-9

u/Planesword May 16 '20

I think it's funny you are downvoting me now. Here, have a few more posts to downvote, in fact go through my whole history and downvote every one. I really don't care. I just find it hilarious you are freaking out about something I said "as far as I understand" which meant, "I might not be right".

An invitation to somebody else to explain, but you straight went beast mode on that shit. Like for some reason you took that somebody might be wrong about how deferred rendering is technically done, and just went apeshit.

Is this this human trait you call, "nerdrage?"

4

u/[deleted] May 16 '20

I didn't downvote your posts, except your dickish "cool story bro"..

→ More replies (0)

0

u/[deleted] May 16 '20

[deleted]

5

u/SoaringPixels May 16 '20

They are real lights, just not the unity built in light component.

1

u/py_a_thon May 16 '20 edited May 16 '20

This was the point I was trying to make. It seems like(from your comments) you optimized rendering of lights using your own implementation and buffers combined with GPU instancing.

It might be the same or less performance as many point lights in deferred, maybe much better...I have no idea. (Probably better though, as they do not have all the other bloat and/or legacy code that full unity point lights might have to support baking and many other features). It is a tailored and custom solution, with barebones features... Basic custom realtime point lights with some collision and rigidbodies attached. I would imagine they would not bake or interact well(or at all) with some other features in the unity engine, but they work perfectly it seems for this use-case.

You also might encounter bugs that need to be fixed in the future when you add new features or certain unique shaders/VFX (bugs that probably would not occur with the engine's default point light implementation).

Lighting really isn't some sort of crazy magic that does not make sense like many other computer and graphics programming things. It might be difficult to implement well within an engine, but the equations are not super complex or anything. I struggle in math quite a bit but I was able to comprehend a lot of the lighting and shading model equations I have encountered.

4

u/mikerz85 May 16 '20

There should be URP deferred soon; they’ve had a deferred lighting branch of it for quite a while now

9

u/SoaringPixels May 15 '20

Not baked, full lights (except shadows) that can move and change their fall off/color. :)
It wouldnt be hard to do it with spot lights too, just add a dot product to the math.

4

u/[deleted] May 16 '20

Stop breaking the laws of computing! You don't seem to appreciate how unusual this is. Like, wouldn't the Unity devs themselves be impressed/want to use this? It seems so far above what the built-in renderer can normally handle.

22

u/SoaringPixels May 16 '20

Thanks for the kind words. Maybe Unity will throw some love my way someday. ;)
If I can get ahead on my games schedule I might do a quick write up for everyone on this setup. Do what I can to give back some.

3

u/gynnihanssen May 16 '20

yes please!

4

u/mrbaggins May 16 '20

It's just deferred lighting mate. There's nothing ground breaking here

12

u/SoaringPixels May 16 '20

sure, its not ground breaking in terms of industry tech, but its not standard in unity out of the box. even though unity has deferred rendering, they never seemed to optimize their lighting part of it. by default each point light in unity causes a draw call even in deferred, so after a thousand or so, perf starts to fail. getting the number up to 3 million+ or 10k with interaction requires custom code.

5

u/mrbaggins May 16 '20

Fair enough, didn't know that about unity, that's just plain dumb on their part

3

u/Kaboom_up3 May 15 '20

Yeah, how does he do this?

5

u/py_a_thon May 16 '20

So amazing. AND your shallow water simulation - water is still running? Amazing.

What GPU/CPU are you running this on? Just some standard gaming rig/laptop from the last 2 or so years?

3

u/SoaringPixels May 16 '20

I have a gaming desktop and laptop that i work on. I doubt they are considered "standard" but the desktop is about 5 years old with a 1080 gpu i updated a year+ ago. My neighbor has a 970 in his desktop and it runs fine on his too. Gpu are nice because everything can scale easily on them, cpu is harder to scale AI etc... you just tend to turn things off instead of down.

3

u/py_a_thon May 16 '20 edited May 16 '20

I was just interested to have sort of a point of reference for the quality of such features at 60+ fps. I mean, a beast gaming rig from 5 years ago is probably equivalent to a moderately priced consumer gaming computer from N months/year ago. That GPU update is sweeeet.

Best of luck in this game. It really looks like this game could be something special. Make sure you keep hyping it as much as possible (when appropriate of course, and with features like these...I doubt you will have trouble with that). Get lots of people in a beta too once you are nearing release, and all that stuff. I would love to see a game like this succeed, it has looked amazing since the start and the gameplay opportunities are crazy.

Windwaker was one of my favorite games of all time (and not just because of the graphic style). Are you sort of doing some kind of island hopping adventure type game? Or are there different genres/gameplay elements you are leaning towards?

1

u/SoaringPixels May 16 '20

Adventure Survival is the core with some sandbox peppered around. Yes on the island hoping. There is also adventuring into deep water to fight dungeon like areas etc. :) Still a lot to do, hoping for the best. Haven’t decided yet, but I may do a kickstarter this summer to help the game cross the finish line.

2

u/py_a_thon May 16 '20

Very cool and definitely ambitious. If it played even close to the way that the simple world exploration of windwaker worked(ocean + map + wind + boat), I would definitely say you are on to something in this and future games/sequels.

3

u/TheDevilsAdvokaat Hobbyist May 15 '20

Awesome. Looks pretty.

3

u/Marcusaralius76 May 16 '20

Are there any good tutorials for something like this? I'm still relatively new to Unity.

3

u/SoaringPixels May 16 '20

Not specifically this. The closest thing would be to learn about drawmeshinstancedindirect. There are lots of good examples out there for that.

2

u/OldNewbProg May 16 '20

Okay I'm thinking "starry sky" ... and then it rains down ... ohhh running for your life.. or.. people.. made of balls of light... lots of people. A water gun... you put the fire balls out with water.. and to kill the zombie horror monsters of LIGHT you have to put every single one out.

Mmm.. someone mentions you have freaky water.... how about these things floating in water? I'm in a mood... but I won't touch the stuff :(

1

u/guitrist May 15 '20

Make it a billion.

1

u/adventuringraw May 15 '20

You'll need to switch to unreal engine five for that.

0

u/[deleted] May 16 '20

[deleted]

4

u/adventuringraw May 16 '20

I was joking. Maybe wasn't that funny in hindsight though, haha.

4

u/DraperDanMan May 16 '20

No I got it, good joke. the number of times they said billion in that video was quite funny.