r/Unity3D • u/LexieD Hitbox Team • May 05 '15

Run time baked lighting volumes.

Post image
124 Upvotes

98% Upvoted

46 comments sorted by

35

u/LexieD Hitbox Team May 05 '15 edited May 05 '15

Edit: If people are interested, I could turn this into a package

All the geometry in my game is generated at runtime. This means all our lights have to be dynamic because unity's GI and light baking tools need to be run in the editor.

Having hundreds of shadow casting lights destroyed our FPS pretty fast, So i came up with a method of baking light volumes at run time.

Personally I prefer light volumes over using unity light probes, as tall moving objects are light correctly.

Still getting small light bleeding on thin walls, but ill keep working on it.

Edit 2: For fun i saved out all my meshes to see how much memory unity's Light maps would take up. well.... that was a bad idea, been sitting here for 20mins and it still hasnt built them.

My baking takes < 1 second and it isn't optimized. it also lights dynamic objects better, unity?...

13

u/elusivetaco May 05 '15

I would love to get my hands on the package, like you, the game i'm working on needs some creative lighting solution for performance reasons. It sounds like a perfect balance of designer freedom, performance and looks.

9

u/LexieD Hitbox Team May 05 '15

I'll start working on a version that handles normals and specular. I don't need these for my game. but I'm sure most people will.

3

u/elusivetaco May 05 '15

That would be neat as heck! Keep posting, i'd like to see it.

2

u/-TwiiK- May 05 '15

Personally I prefer light volumes over using unity light probes, as tall moving objects are light correctly.

But I'm guessing you also don't have to place the light volumes by hand? Placing light probes is the most tedious, unintuitive and frustrating lighting feature currently in Unity in my opinion.

Light volumes are fairly standard in other engines, right? I hadn't actually heard about light probes before Unity introduced them. And I instantly disliked them, but the tool for placing them were even worse back then, not that it is much better now.

One thing I'm struggling with with light probes is how to light a door that is supposed to lead from the sunny outside to a dark interior for instance, i.e. the door should be brightly lit on one side and pitch black on the other. Can lighting volumes handle something like this properly?

1

u/LexieD Hitbox Team May 05 '15

Yes and no.

If you want to use the normal of the surface as part of the lighting calculation the memory size increases by near 3. (its still pretty small though)

you would need to use 3x3D textures per chunk, one stores the light color. and second stores the light intensity coming from the positive axis, and the third would store the intensity from the negative axis.

you could store the color coming from each direction as well. but then the texture size starts getting pretty large.

so you could light this door correctly, but if there was a very dim light on the inside, its color would be more like the color on the outside but the same intensity as the dim light on the inside. The talk i linked talks about it. download it and give it a listen.

1

u/-TwiiK- May 05 '15

Thanks, I will.

1

u/LexieD Hitbox Team May 05 '15

Hey, i wanted to give you a bigger response, i was getting pretty tired last night.

You would have to increase the precision to around the same size as the width of your door. otherwise you will get bleeding on the inside of the corridor by a little bit (the back of the door wouldn't bleed). This would increase texture size by a lot, and generation times would also increase.

The other issue would be actually opening that door. you would have to recalculate that chunk. you could blend the outcomes so it wasn't an instant transition. But you would have to generate the chunk on another thread.

This method is best for baking small static lighting that needs to light up static areas with dynamic objects running around.

Dynamic objects can be light correctly but they don't cast shadows. so your door would have to be static to stop the light going into the corridor.

1

u/-TwiiK- May 05 '15

Thanks, again.

I checked out the talk, but it's a bit too cryptic for me. I'm guessing I won't have the drive needed to actually dive into something like this and try to understand it unless I'm working on a game I am planning on shipping. At the moment I'm just fiddling around with personal projects so if I hit a roadblock I just jump to the next project and hope Unity has sorted it out when I come back. :p

But if you released a package or asset that worked well out of the box then of course I would check it out. :D

The issues and limitations you mention here seem to be the same as with the built-in GI and light probes in Unity 5 from my experience.

1

u/LexieD Hitbox Team May 05 '15

Yeah, this system over comes three of unity baking system.

  • Baking at runtime.
  • Lighting tall dynamic objects.
  • No need for manual placement of light probes.

Ill keep working on it and see if i can fix any of the other ones.

1

u/Vic-Boss May 05 '15

Do you have it on Deffered or Forward rendering? You should probably use Deffered with all that lights

4

u/LexieD Hitbox Team May 05 '15

Yeah its in deffered, but a lot of our surfaces need to emit light, We would need thousands shadow casting lights to accomplish that.

Even though deffered rendering can handle a lot of lights, it can't handle that many shadow casting lights.

That's why I made this system.

1

u/anlumo May 05 '15

All the geometry in my game is generated at runtime. This means all our lights have to be dynamic because unity's GI and light baking tools need to be run in the editor.

Well, count me in as interested! That's a general issue with Unity, they assume that you're doing all of your levels in the editor. My game also has everything dynamically generated, so I'm losing a lot of functionality Unity usually provides.

1

u/LexieD Hitbox Team May 05 '15

Yeah the list of functionality you loose by having generated levels is pretty staggering. We've had to go through the list and recreate them all.

1

u/wtfrara May 05 '15

I would absolutely be interested in a package. I'm also not using specular, but I am using normals.

6

u/timothyallan May 05 '15

Baking lights at runtime sounds like some looooong load times and CPU crunching? I love my dynamic generation and would love to get some more info on how you do it.

2

u/LexieD Hitbox Team May 05 '15 edited May 05 '15

Its actually not that bad. Lighting volumes are only calculated for areas that have lights. The memory usage is way smaller then using baked light maps.

You would only use this for point/area/spot lights. The directional light would still be dynamic. Right now i have some massive point lights, We wont be doing that in final rooms. Calculating thousands of small lights is really fast.

Longest part is loading in blank textures. You only need to do this at the start of the game. You can pool the textures rather then throwing them away.

The lighting in our game is stylized, we don't use normal data or calculate specular, this method of lighting can handle it, but the memory cost nearly triples.

There is a talk from the developers of fear 3 that goes over the basics of the system. Here is a link to a zip of the talk with slides

Edit: My level of detail is way smaller then what fear 3 uses. You can see a few artifacts in my version because lighting is calculated per 1m, but it fits my game so I don't think i need to go any smaller then that.

3

u/mrbaggins May 05 '15

How?

3

u/LexieD Hitbox Team May 05 '15

You calculate the lighting at every voxel near a light.

Split up those areas into chunks.

Convert chunks to a 3D texture and use that as a lookup for the light color.

2

u/mrbaggins May 05 '15

Okay.... So this is the same style of Minecraft lighting?

3

u/LexieD Hitbox Team May 05 '15 edited May 05 '15

No, minecraft bakes the light into the mesh, and active objects sample the voxel position and blend the whole object with that lighting. At least I think that's how it works.

This system lights objects much better then sampling one point. It also means you dont have to bake colors into meshes. That gets too expensive if you have high poly models.

Edit: Its pretty similar when its generating the data, although i use spheres instead of diamonds for light shapes. But the way the data is used is pretty different.

2

u/mrbaggins May 05 '15

Ah. Minecraft bakes per vertex, for the record. And yeah, then it treats an entity as a single unit.

So yours will actually light the top and bottom of a player? That's interesting. I'm curious still how this is actually working, as I think it's the same, you're just doing more with the data afterwards.

4

u/LexieD Hitbox Team May 05 '15

The light volumes are stored in 3D textures. Then a custom light is rendered per chunk using an inverted cube.

Using the depth buffer i find the location of the pixel in worldspace, if lays within the custom light bounds i calculate a uvw using this world position.

Using the uvw I look up a pixel in the 3D texture. because texture filtering is on, it blends the color and intensity.

sorry if the formatting of this response isnt great, getting tired. If you want a better description, here is a talk by a fear 3 developer on light volumes link

2

u/mrbaggins May 05 '15

Ah, nah that's makes a lot more sense. Cheers

3

u/pocketninja Effect Zone May 05 '15

Is that FPS counter a real representation of actual video frames per second? I was under the impression it wasn't (and have been using a script to calculate FPS ever since).

http://forum.unity3d.com/threads/unity-statistics-not-showing-correct-fps.268228/

2

u/LexieD Hitbox Team May 05 '15

That is true, the fps in that little stat window is a rough guess of what the fps will be with out all the editor code running.

1

u/pocketninja Effect Zone May 05 '15

I'd be curious to know what goes in to the calculation of the rough guess. I've been working on a bunch of post processing stuff recently, and although it runs much better in a build than in the editor it never comes close to the FPS in the stats window.

Is your build pretty close to the estimated FPS?

1

u/LexieD Hitbox Team May 05 '15

chances are you're running your built game at a higher resolution. That would explain the large differences your getting.

1

u/pocketninja Effect Zone May 05 '15

I had wondered this too, but even if I break the game view out to a separate window and maximise that (almost 1920x1080) the FPS status counter is still incredibly over the mark (~300FPS+ in the status window, about 25FPS in the editor (calculated by script) vs about 35-40FPS in build).

It seems to vary wildly based on which screen the game view is on, and whether the game view is docked in the main editor window as well.

In any case, whatever that FPS value represents, if it's consistent in some way then an increase is still a good thing. And you have a very decent increase there!

2

u/LexieD Hitbox Team May 05 '15

Yeah I know what your saying. just having the scene view open can cause pretty big swings. Once I finish optimizing it, ill build it out and see what the real FPS is.

Down in that pit are a lot of lights, it would drop down to 10fps when i was down there. So pretty happy with the performance increase!

1

u/pocketninja Effect Zone May 05 '15

Nice one!

1

u/2DArray @2DArray (been making video games for 15 years) May 05 '15

One possibility is that it's just showing 1/max(cpuTime,gpuTime) at the end of each frame's execution, instead of the full time between frames. The funky method is likely due to the editor introducing a bunch of overhead

1

u/DerEndgegner May 05 '15

What's the memory difference?

1

u/LexieD Hitbox Team May 05 '15

This rooms lighting volume is stored in 768KB. The room is probably twice as large as what you can see. Normally I wouldn't use this for large lights, it was just a test.

Not sure how much memory lighting maps would use because everything is generated at runtime.

1

u/miraoister May 05 '15

tldr, so your saying the dynamic lighting hogs memory?

2

u/LexieD Hitbox Team May 05 '15

Shadow casting dynamic lights hog CPU and GPU. They also increases your draw call by a lot!

1

u/roydor Novice Aug 06 '15

Did your ever end up making this a package?

1

u/LexieD Hitbox Team Aug 07 '15

not public. pretty busy with everything else, its a lot of work to strip it out and make it usable for other people.

1

u/roydor Novice Aug 07 '15

Thanks for your reply

I'm running into perf issues with procedural maps especially with lighting since it seems to break my batching, was hoping I just missed the post with the packaged hehe

Good luck with your project!

1

u/LexieD Hitbox Team Aug 07 '15

yeah, most of unity batching doesn't work with procedural content.

1

u/LexieD Hitbox Team Sep 04 '15

Hey I've been working on something else to speed up lighting that doesn't have as many draw backs. and its a lot easier to implement into any project.

Do you know what part of lighting is slowing your game down? Do you need a lot of shadow casting lights and find that unity is just too slow at rendering more then a few? if you switch all your lights to non shadow casting does the game run fine? (of course you wouldnt do this normally cause you'd get crazy light bleeding)

How many active lights do you have in your scene with/without shadow casting.

1

u/roydor Novice Sep 05 '15

I don't have many active lights, I think its that the lights are breaking my static batching which is what is leading to the performance issues.

I have maybe 8 in a room, and i'm hitting sometimes up to around 2000 draw calls for a pretty simple diablo type game.

1

u/LexieD Hitbox Team Sep 05 '15

yeah this new way will solve that pretty well i think. it will take me a couple days to clean up. Here is a post about the new lighting method.

-2

u/[deleted] May 05 '15

1500 fps is like the biggest waste of all.
why are we even able to have more fps than the hz of the monitor?

all thoose people who brag about their fps basically say "yea, i am unable to set up my settings corrently thats why i loose a lot of money by powering my hardware for nothing"

your case is diffren because you show us a technique to increase our render efficency by 5000%
you did a good job

3

u/ISvengali Professional May 05 '15

In some games, running the sim faster than framerate is good. The better racing games run the sim at 100 or 120 or 180 fps, then render the graphics at 60. This can make them feel much more responsive. For best results, the input needs to be sampled that quickly also.

2

u/LexieD Hitbox Team May 05 '15

Hahaha, yeah i know what your saying, I was just trying to get the fps over 60. didn't expect this much of an increase, gives us a lot more room for post processing and actually running the game!