[idea] baked dynamic environmental shadows

[the itis]

I'll keep this simple and straight to the point. Apparently there will be two types of shadows in PE: shadows for things that move (dynamic shadows generated by light sources interacting with height and specular maps), and shadows for things that don't move (environmental 'stuff', these are baked on during prerendering of the map, I *assume*).

 

There is a problem with baked shadows: they don't shift with the time of day. Making every environmental art asset contain dynamic shadows is not feasible, I assume, because of the resources required. Using a computationally light method that requires minimal programming, can the PE team make baked shadows that shift depending on the time of day? I think they can. Here's my idea.

 

 

1) For each piece of environmental art ID'd as requiring a shadow, generate a baked on shadow into the environment by rotating the light source representing the sun through it's full morning -> evening cycle.

 

2) For each baked on shadow-circle (oval, actually), generate a perspective-correct shadow mask. This mask should be transparent to the MAP textures (onto which the shadow-oval is baked), but entirely OPAQUE to the shadow layer. Cut from this shadow mask the shape of the object's shadow. This cutout is opaque to the map textures and transparent to the shadow layer.

 

3) Overlay the shadow mask onto the shadow-oval generated in 1, and rotate it as a function of the time of day. You now have a baked on shadow that shifts with the time of day.

 

The nice thing about this method is that you only need to do this process once per environmental asset. Every time an art piece is inserted into a map, add it's shadow-oval as an additional texture. Bake everything, drop the correct corresponding mask onto it afterwards and use the same general script regime (rotate X radians per game time Y) to control the rotation.

 

 

Sorry for the low-fi graphics, I hope it gets the point across.

Edited May 6, 2013 by the itis

[Pipyui]

Interesting thought.  I've considered this issue briefly myself, and though I have no graphical processing knowledge, and to say that I understand exactly what you wrote would be grossly inaccurate, I have my concerns.

 

If I understand correctly, this shadow map would always be a solid oval rendered from the trigonometry of the sun and the edges of the object.  Then, a 2D rendition of the object would represent the shadow and reveal the shadowmap underneath.  As the 2D render would rotate, so would the shadow move.

 

My concern is that this only seems to work for objects symetric along the axis perpendicular to the sun's movement (if that even made sense).  Such that while this may be accurate:

 

This would not be:

 

So far the best idea I've managed to come up with (and by best, I mean really aweful) is to maybe create two 2D planes for each shadowed environment piece.  The regular one would be parallel to the screen and be visible to the player, but this would be bisected by another, invisible 2D render of the object derived and placed at a normal to the first only used to generate shadows (and maybe hit boxes):

 

Trouble is, I don't know just how to account for light sources from at or close to directly above.

Edited May 6, 2013 by Pipyui

[AwesomeOcelot]

That's not the way shadows from the sun work, the sun rises and sets, goes from East to West. Also that would work quite well for a light source rotating around an object, the scenes in PE are prerendered complex 3D scenes that are painted over, preventing this from working: a) what happens with objects that are next to each other, b) with anything that casts a shadow on itself, or c) as Pipyui said things that aren't cylinders and boxes? It's not just shadows, every rock, shrub, brick, and tree would be lit differently depending on the time of day, and look at them, they're not repeated assets.

[Pipyui]

Well, to be fair, I think the OP tried to account for sun movement by using shadow elipses rather than circles, such that his example would be better represented as such (I'm sorry I don't have gimp on the machine I'm using, not that it would make my drawings much better):

 

As said though, this does not account for shadowing other objects, or irregular shapes.  Shelf shadowing, or at least an aproximation of it, seems to have already been handled with normal maps as shown in the demo video.

 

My own implementation mentioned previously using dynamic lighting should "work" with irregular shapes, and other-shadowing has already been shown in the demo video and should work here, however this method only provides a very crude approximation of a 3D model shadow.  Things would get weird as objects get more irregular (pretend the bases of the two planes are attached, I'm sorry I'm so very bad at this.  If it comes to it, I'll use gimp next time):

It's clear here that angled lighting would produce less accurate shadows.  A 45 degree or so light would even create a two-protrusion shadow.  And lighting from the top is still unaccounted for (I don't think I can just staple another plane on in the x-y plane to produce even remotely accurate shadows).

 

Does this idea have any merit at all?  Maybe a little?  Probably not.  It's all I've got though.

Edited May 7, 2013 by Pipyui

[the itis]

Thanks for thinking about my post guys. I think you both have some good points, it was a naive attempt at solving a complicated problem. Pipyui, I'm going to address your points by first addressing AwesomeOcelot's concerns.

 

 

That's not the way shadows from the sun work, the sun rises and sets, goes from East to West. Also that would work quite well for a light source rotating around an object, the scenes in PE are prerendered complex 3D scenes that are painted over, preventing this from working: a) what happens with objects that are next to each other, b) with anything that casts a shadow on itself, or c) as Pipyui said things that aren't cylinders and boxes? It's not just shadows, every rock, shrub, brick, and tree would be lit differently depending on the time of day, and look at them, they're not repeated assets.

 

The first issue about the sun rising from east to west is trivial. Rather than making a shadow circle, as I've drawn for simplicity, it makes an oval. More accurately, it looks more like a p orbital with a node/minimum in shadow density when the sun is at it's peak. Since part 1 generates a radial distribution of shadow 'states' it doesn't matter the arc that the sun takes- all shadows that are generated are captured. Additionally, objects whose shadows interact or self-shadow would still generate this radial shadow projection. If two environment objects are placed close enough that their shadow maps overlap, then they overlap. Just as if two textures were placed overlapping, and you were able to view them both.

 

The hairy issue you both have raised, which I didn't address in the first post, is how to deal with complex shapes whose shadow-mask can't be represented by a simple cut-out that is translated radially. I agree, I think the solution is to generate these cut-outs via silhouetted projections interacting with the shadow mask.

 

 

Where the projection intersects with the the mask, it creates a cutout. This means that rather than a static shadow mask rotating around a shadow map, there is instead a dynamic shadow mask being generated by a projected polygon intersecting with the mask, being generated as the sun ascends and descends. To capture the multifaceted nature of buildings, there would likely need to be 4 basis object projections (generated at 0 deg, 90, 180, 270 and 360). These would be at the correct corresponding position of the sun with the projected polygon based on one of the four bases (but still projected for all sun positions between the 4 predefined polygon positions).

 

Linear algebra handles this projection quite easily, any graphics programmer would be quite comfortable with it. 4 basis sets might be too much, you could potentially get away with 2 or 3, it would take some experimentation to figure out. The question now is: is this a benefit to just generating dynamic shadows on the fly for buildings (i.e. is what I'm proposing worth a damn)? I don't know. Computationally, generating these shadow masks on the fly via projected polygons sounds very similar to generating shadows (on the fly projections) dynamically. I think this idea is similar to what you're suggesting Pipyui, but I'm not following you 100%.

Edited May 7, 2013 by the itis

[AwesomeOcelot]

It seems like a lot of work. Also there's the much bigger problem of, even with correct shadows from the position of the sun, the whole lighting would also have to change in the scene not just cast shadows, it would be strange to have the same lighting but the shadows moving. My suggestion was to do renders of the shadow map for each hour of daylight, compress those down, so that if you visit an area it will be forever in that hour until you travel or set the party to wait.

 

Rather than making a shadow circle, as I've drawn for simplicity, it makes an oval.

That may work for simple shapes, but not for complex ones. It's not simply a case of stretching a 2 dimensional shape.

 

Additionally, objects whose shadows interact or self-shadow would still generate this radial shadow projection. If two environment objects are placed close enough that their shadow maps overlap, then they overlap.

Not shadows overlapping, shadows onto other objects.

 

To capture the multifaceted nature of buildings, there would likely need to be 4 basis object projections (generated at 0 deg, 90, 180, 270 and 360).

You don't need 360 degrees for shadows formed by the Sun, even on the equator.

 

Linear algebra handles this projection quite easily, any graphics programmer would be quite comfortable with it.

I don't think so, you might be able to do this for simple shapes, but not things like trees.

Edited May 7, 2013 by AwesomeOcelot

[Frenetic Pony]

I can clarify this, there is NOT going to be any shadows for things that move, IE no shadows from moving lightsources, the game isn't going to have access to the information it needs to do so, the only information it has are the things you actually see on screen.

 

This is great for some things! You get a lot of cool stuff with that, dynamic lighting (without shadows) is fine, no particular worries about the number of polygons or texture size or variety, as you aren't really doing any of that. But what you don't get is any real way to do dynamic shadows (beyond a very limited point).

 

 

I've also thought about how you might hack around a moving shadow from the sun at least, but your proposal isn't going to work. I think they're doing what I originally suggested, a cached shadow map of the entire scene, giving the ability to move the shdows around (in a 2d fashion) if desired, and of course the ability to cast onto dynamic objects just fine.

 

And that's one of the keys, you get shadows that move a bit if you want (tree leaves swaying in the leaves) and correct shadows for casting onto dynamic objects just fine, just like you would do in any other game, but with basically unlimited quality, as most of the shadow map is pre computed why not super sample like crazy?

 

To ACTUALLY get the same effect for a moving sun you'd need to do something like take that shadow map texture, sample the differing depths along the suns path over a hemisphere, storing say 1024 samples and treating each pixel of the shadow map as a 1d texture in and of itself, necessitating essentially a huge 3d texture for each level which you can't move and has to be loaded all at once, instead of how PE does it now, where you only need to load the sections of the shadow map (probably just stored as tiles) in the immediate area around the player.

 

I.E. too much work programming wise and spec wise for reward gained. Besides, the game and night/day transition looks fine as it is. Better to spend time doing other cool things like getting SSAO and cloud shadows to work instead, or effects like rain and fog and etc. Heck fog of war isn't implemented yet.

Edited May 8, 2013 by Frenetic Pony

[the itis]

Yea, step 1 is exactly that: generating a shadow map for the entire path of the sun. Doing it for an entire rendered map makes sense tho, and I agree about the resources vs. pay-off.

 

It's a fun problem to think about tho.

Edited May 10, 2013 by the itis

[Pipyui]

Indeed.  Though it wouldn't kill me to live without of course, I'd love to see shadows that moved with the sun.  I mean, the only real advantage to fixed isometric camera is eyecandy, and I for one want my eyecandy, damnit!

 

No but really, I just like how a scene can change with time of day.  The forest behind my house looks cheery as any other during the day, but when the sun falls, the light turns golden, and the shadows stretch across everything, things get kinda somber and surreal.

 

Of course, I also see the merit in static shadows.  Details can be much more accurate and defined, and the forced perspective allows the artist to portray light and shadow exactly as they like.

 

I prefer "dynamic" - whether or not they're generated real-time - shadows though, simply because it helps immerse me, where weird inconsistencies like "stuck" shadows warp my head a little.  I like the subtle change of scenery that comes with it, and to imagine that I'm not walking on a time-stuck painting.

Edited May 10, 2013 by Pipyui