area lights w/ buffer shadows

[astralpancakes]

Playing around with setting up an array of spotlights casting buffer shadows to get soft shadows without having to raytrace. My wild guess^W^Weducated assumption is that this is how mental ray et al do those shweet quickfast soft shadows.

Nice results, esp. considering the speed, but a bit fiddly to adjust at the moment. Seems to need a really low shadow bias. Bumping SpotBl seems like an acceptable alternative to adding more lights to soften banding, SpotSi affects overall brightness in addition to lightcone size (since the individual lights start overlapping). Left the rest of the settings pretty much alone. I guess you could increase Samples and Soft to get even softer shadows, but it’ll get soft close to the shadow casting objects too.

Specular highlights are likely to go crazy too, so it’s probably best to turn it off for the lights in the array and just add an extra, specular-only light, if you really want it in there.

Some tests (not too concerned with getting the overall brightness equal or making a nice scene):

Raytraced, 16x16 samples: 4min 25s

–

16x16 shadow map lights: 31s

–

32x32 shadow map lights: 2min 7s

A fairly big increase in render time vs small quality increase. Still a lot faster than raytrace though.

–

16x16 shadow map lights using irregular buffers: 3min 25s

Probably the nicest result, but approaching raytrace times. Some banding visible, so you’d want 32x32 or something lights here as well -> even slower.

It’d be fairly trivial to set up a script that generates the array for you, I guess. It’d be nice to have something that would let you try out different sample amounts (ie number of lights) easily. Though what I’m hoping is that some dev sees this and decides to add a proper shadow map area light.

Something that looks a bit nicer in the viewport, at least:

:spin:

[Ace_Dragon]

This technique has been known to old Blender users since before the days of raytracing, in fact, it’s the old method used to get soft shadows in Blender before it had proper arealights.

[endi]

Yeah I always use this trick years ago when we have no raytrace.

[toontje]

Then you will LOVE light cuts. Grab a build at graphical/

[astralpancakes]

Oof, figures. :<

So how come there’s only raytracing for area lights?

[harkyman]

astralpancakes: because a buffered shadow is created by actually making a sort of “render” (z-values only) of the scene from the perspective of the lamp, then using that to determine whether objects in the scene are lit by the lamp or not. Area lamps use ray shadows because they sample each pixel they are trying to render on the fly – the shadow buffer method works because you are creating the shadow from a specific point in space. Area lamps cover an area.

Also, this arrayed spot lamp technique is the one I used for the interiors in my animation. It took a while to get things just right, but render times were kept very very low (over 5000 frames total), and the results were very good.

[Tea_Monster]

Not trying to be a troll, but why is it possible for one of us to set up some buffered shadow lights and get a good result, and the Lightcuts project takes millions of years to render a scene and comes up with those weird banded shadows everywhere?

Honestly not trolling, I just want to know why. Isn’t there some setting somewhere that can be adjusted for this? One guy had some node setup that blurred the shadows so that the image lost those strange banding effects.

[harkyman]

Tea_Monster: lightcuts relies on raytracing. These shadows are buffered shadows (which can be soft to begin with) duplicated and overlapped, which produces a very nice effect. Buffers only work for directional, contained light (i.e. Spot Lamps), so they are inappropriate for something like lightcuts which needs omnidirectional casting. Personally, I was excited for lightcuts in the beginning, but the severe long render times, banding and poor animatability have made me think that we will need a different method of indirect lighting/global illumination.

[Tea_Monster]

Thanks for the info Harkyman. I liked the IBL patch that (I think it was broken) submitted. I’ve not worked with it (I’m downloading a build now), but it looked very promising and fast from what I saw.

Lightcuts looks very problematical at the moment. Maybe that will all be worked out in time by Uncle Ziev. I hope so. As he has put, it would be great to have 2 different solutions for GI in Blender.

Do you or anyone else know of a quick primer for setting up the IBL? I wasn’t aware that you needed to use raytracing for lightcuts for example.

[astralpancakes]

Well okay, with everyone screaming WE’VE KNOWN THIS FOR YEARS!!1 I’m not sure whether I should bother with this. In any case, I hadn’t thought about this much at all before, and figured I’d do some tests, heh. I’m sure there’s one or two other people who hadn’t either.

@harkyman

astralpancakes: because a buffered shadow is created by actually making a sort of “render” (z-values only) of the scene from the perspective of the lamp, then using that to determine whether objects in the scene are lit by the lamp or not. Area lamps use ray shadows because they sample each pixel they are trying to render on the fly – the shadow buffer method works because you are creating the shadow from a specific point in space. Area lamps cover an area.

Yes, I know how the different shadow types work. Not sure how you interpreted my question there.

The way I see it a readymade area light that uses shadow buffers would be far more useful than the slow raytracing area light that’s currently in there. Or it could be a sampling setting for the current spotlight – doesn’t matter. Yes, it would be directional (so is the current area light, more or less), and yes, it would have a lightcone, like the current spotlight, but I don’t see how that matters much.

There’s no reason you couldn’t have a omni light with buffer shadows btw. 3ds max at least does this. You just need several buffers, one for every direction, ie 6 at a minimum, possibly more.

I’m not particularly interested in GI (or IBL, really), it’s slow and annoying and pretty useless for animation. And I’ll admit I’m not sure what lightcuts is, exactly. I’m trying to force myself into a Renderman-type school of thinking where I even try to avoid raytracing unless it’s absolutely necessary.

[harkyman]

Sorry I misunderstood your question. I was coming at it from the programmers standpoint – i.e. why don’t we just implement buffered shadowing for area lamps alongside the ray ones? And the answer from the programming standpoint was that you can do multiple sampling with ray areas without creating a whole bunch of instances of lamps and buffers, which you can’t do with buffered shadows, so they really work on different principles. I never try to assume technical knowledge on the part of artists. Sorry.

Personally, I think that a GI solution of some kind, even a not-super-accurate one, would make a great addition to Blender Internal right now. I’ve had some ideas on how to do it. It would have to be fast (like AAO fast), nice for animation and give a reasonable approximation of a better solution. Most features now use some sort of GI, and it really shows.

[mzungu]

@harkyman

Personally, I think that a GI solution of some kind, even a not-super-accurate one, would make a great addition to Blender Internal right now. I’ve had some ideas on how to do it. It would have to be fast (like AAO fast), nice for animation and give a reasonable approximation of a better solution. Most features now use some sort of GI, and it really shows.

Harky, have you peeked at broken’s IBL patch at all? (ref this thread for links) Seems it would be a great start for what you’re talking about - something falling between env-colored AO and the lightcuts project - and evidently a pretty fast solution since it works with AAO. Man, it would be great if you could pick up that ball and run with it! (May not be what you’re on about at all, tho… I’m not sure about all that’s going on “under the hood” there… )

[astralpancakes]

@harkyman

Sorry I misunderstood your question. I was coming at it from the programmers standpoint – i.e. why don’t we just implement buffered shadowing for area lamps alongside the ray ones? And the answer from the programming standpoint was that you can do multiple sampling with ray areas without creating a whole bunch of instances of lamps and buffers, which you can’t do with buffered shadows, so they really work on different principles. I never try to assume technical knowledge on the part of artists. Sorry.

Personally, I think that a GI solution of some kind, even a not-super-accurate one, would make a great addition to Blender Internal right now. I’ve had some ideas on how to do it. It would have to be fast (like AAO fast), nice for animation and give a reasonable approximation of a better solution. Most features now use some sort of GI, and it really shows.

Ahh! Not sure if that was more technical explanation or not, but yeah, fair enough.

AO is pretty much supposed to be the fast, inaccurate, reasonably approximate GI solution for animation work, I think. As far as I know AAO is quite an ace up the sleeve for Blender. A full GI solution would be a nice addition (though not much use for animation work), but even that might be a niche nicely filled by Yafray, now that development of that seems to (slowly?) be picking up again.

It’s not like I mind new features, like IBL, but what I’d personally prefer to see at this point is improvements on what’s already there. Improved shadow buffer lamps as mentioned, faster raytracing for softshadows and glossy reflections/refractions, ambient lamp type, more accurate control over the diffuse and specular parts of individual lamps, better interplay between AO and lights etc.

[Michael_W]

@harkyman

Sorry I misunderstood your question. I was coming at it from the programmers standpoint – i.e. why don’t we just implement buffered shadowing for area lamps alongside the ray ones?

Having a way to internally treat area lights as arrays of spots with buffered shadows could be interesting for realtime viewport previews with the GLSL code. Even if these things prove too expensive for realtime games, the viewport feedback for pre-rendered content could be very advantagous… Perhaps a “quality” setting that varies the amount of spots used in the array would provide a quick tweak…

[tyrant_monkey]

@astralpancakes good tests, I follow the same approach working with buffered shadows I learnt most of my lighting from reading digital lighting and rendering the authour works for pixar so is an advocate for working with buffered shadows, I find raytracing in Blender can be devasting to render times so I try and keep that button deactivated or stick to lighting techniques that don’t require raytracing. the only limitations is that we don’t have deep shadow maps then you could work with transparent surfaces and the are pretty good for hair and fur rendering.