From: Lionel F. <fu...@gm...> - 2013-07-15 21:21:35
|
todo 2013/7/13 sam...@gm... <sam...@gm...> > Why I want to abandon lightmapping > > 1) It's a long and boring process. Each steps need to be done one by one > 2) I want to start to use an object library, so tracks can share objects. > You cannot modify an object linked in blender. The only way is to modify > the original (and of course it's useless because each track are lighted > differently). > 3) When you use lightmap it's exclusive. An object cannot receive light > from lightmap and a dynamic light > > For me the #2 is very important. My future track already use a library. > The blend of the track contain only reference to objects in other blend. > > > 2013/7/12 Lauri Kasanen <ca...@gm...> > >> Hi, >> >> I've discussed this on IRC with samuncle. The point in having both SSAO >> and a baked AO map is the difference in quality, let me elaborate on >> that: >> >> The baked map can easily have high-quality creases that do not flicker; >> with dynamic SSAO, creating contact shadows (bigger blobs, not small >> creases) is the main objective, and it flickers in all known SSAO >> implementations. >> > Yup, mostly, but I don't see the flickering as really annoying in most implementations (and it's wrong that it's the case in all of them - recently, NVIDIA's HBAO compute shader-based implementation doesn't use randomness at all, and I know HBAO is used in the latest Tomb Raider - not sure if they use randomness there or not). But you got the point: baked AO is of better quality than SSAO. > >> Since dynamic SSAO can not capture small creases with even close as >> good quality as a baked one, it would save resources to not even try. >> So dynamic AO = big contact shadows, baked = small creases - nothing >> would be calculated twice in this setting. >> > Err, I would say the opposite: SSAO works on a small range, while baked AO can work for everything, and is only limited by the texture resolution (which could make it impossible, if too small, to represent small creases). I see both as complementary. > >> >> Re the current state: >> > - direct shadows would be totally absent, which would be _really_ >> noticeable. >> >> Only four maps have any lightmaps currently, the rest do not. This is >> because it's a lot of additional artist work I hear. >> > Yup, but the work is already done, so better avoid throwing it if it's for getting something of worse quality. > >> Since the majority of the maps do not have any shadows currently, and >> there are no complaints that I've seen about it, I'm not sure if its >> importance is overstated here. It would, in other words, not be a >> regression to status quo. >> > I'd say that there are no complaints because there never have been shadows ^^. But I admit that it's my personal view that it's one of the most lacking graphical features for STK (together with proper ambient occlusion, lighting, and good/more animations). > >> It's mainly the moving things which should have shadows in order to >> please the eye. The karts currently fake it, and lightmaps cannot >> provide that for moving lights but static geometry. >> > Agreed. I think we should not remove lightmaps except if we can replace them with something of a similar or better quality (and I doubt we can do that for some time). The work has already been done for some tracks, so keeping them should not trigger additional work, while it doesn't prevent you from developing alternatives. We can still add the possibility to just create ambient occlusion maps if you like, that doesn't mean we need to remove lightmaps. We can give tools to the artists, it's up to them to choose and use them or not (though we can give guidelines :)). Re samuncle: > Why I want to abandon lightmapping > > 1) It's a long and boring process. Each steps need to be done one by one > 2) I want to start to use an object library, so tracks can share objects. > You cannot modify an object linked in blender. The only way is to modify > the original (and of course it's useless because each track are lighted > differently). > 3) When you use lightmap it's exclusive. An object cannot receive light > from lightmap and a dynamic light > > For me the #2 is very important. My future track already use a library. > The blend of the track contain only reference to objects in other blend. > On #1: as it seems, a part at least of the process could be automated, but that's some more work to do... It's important to consider, but not an intrinsic limit of the technique. On #3: that's just a limit with our current implementation, nothing prevents a shader from computing dynamic lighting and adding baked lights together. #2 is what bothers me most. Maybe an object in a Blender library could have one lightmap texture per track (e.g "lightmap-lighthouse.png"), and the correct one is chosen at export time based on the name of the track? I admin I don't know if such a thing would be possible and/or easily doable. |