If by = snore, you mean it takes a long time, then I acutally found it to be faster than ut3's previous standard bakes. It depends on weather you set a lightmass importance volume or whatever it's called though
It's basically the same as adding any other volume, only you choose the 'light something importance something' from the dropdown menu. And then you'll get some pretty fast builds, even on production quality (depending on level size ofc)
Yeah baked = snore as in boring. I've been baking this kind of stuff for about 8 years now, since the ps2. What is the voxel stuff you're talking about.
Basically a 3d volume grid of ambient light points that gets baked at the same time as your lightmaps, and as dynamic models move through the volume their lighting changes to match the environment. It basically means you get a bit better ambient and subtle directional lighting for dynamic models.
From someone who's been using UE3 for awhile, its a nice change. Yes, baked GI is nothing new, however the lightmap optimization and packing it now does it quite awesome (taking areas of high contrast and up rezing them on the lightmap, and light areas being reduced to a few pixels). The other big thing here, is dominant direction lighting is now supported. This means lightmaps are still baked, however specular lighting and light environment shadows are done dynamically from one light. So dynamic and static shadows blend properly now so you can't tell which is which and specular highlights work as intended. Dynamic meshes now light a whole lot better taking into account static shadow casters. Worth playing with!
I think he meant baked = lame. Probably wants something more like Geomeric's "Enlighten" engine.
@Vassaago - I've seen the videos and screenshots, but have never seen a game or heard of a UE3 licensee integrating this. The programmers at my studio seem to scoff at the idea that could run in UE3 in realtime.
which has been there since quake3 if not before. (referring to baked light volume). But imo it's cool whatever gives best performance/quality ratio... I just wonder how they deal with destructable stuff? does that require multiple bakes? Or must all breakable stuff be rendered with real-time shadows (I guess so).
Or must all breakable stuff be rendered with real-time shadows (I guess so).
If you're using their built in fracture, then no. Bakes like normal (uses lightmaps) but the outer pieces that form around the core of object do not self shadow / cast shadows. Debris physics chunks are dynamically lit.
which has been there since quake3 if not before. (referring to baked light volume)
The volume is really only used to determine how far photons should go when calculating lighting. Obviously if you only need them in a small area, bake times can be sped up and background lighting approximated. The nice side affect is that the volume is also used for the character lighting sample points.
Yeah gamedev the proper merging of dynamic shadows (characters) and static bakes (building) is what struck me the most when running through the UDK level provided.
Does lightmass also bake colors? Like Beast (right?) for Mirrors Edge? If so that's kinda big aswell.
DEE, I find it disappointing to see that on the Marcus screen you posted, there is no presence of 'dark in the cracks' effect on the character standing in the shade, as opposed to the nice occluded shading of the inside wall.
Is the realtime screen space AO from GoW2 present in UDK ?
Does lightmass also bake colors? Like Beast (right?) for Mirrors Edge? If so that's kinda big aswell.
Yes it does. Although they have removed the awesome RNM tech ( "Radiosity Normal Mapping" ).
I guess they thought 3 X RGB lightmaps per surface was overkill for their gritty environments.
You still get the intensity from each direction representated in the normals but you wont get colours.
On a second note, anyone know if it's adjustable like in CE2?
Indeed it is. You can make global changes by finding the post process chain (just search for it in the content browser) and adjusting the AO node. Lots of control including intensity and fade distances.
DEE, I find it disappointing to see that on the Marcus screen you posted, there is no presence of 'dark in the cracks' effect on the character standing in the shade, as opposed to the nice occluded shading of the inside wall.
Well, you're seeing a few things there. The reason the wall looks as if it has so much AO is because Lightmass also bakes AO into your lightmaps and then SSAO is applied on top. I'm also not sure if you can view SSAO in lighting only mode. Something to test real quick.
Yes it does. Although they have removed the awesome RNM tech ( "Radiosity Normal Mapping" ).
I guess they thought 3 X RGB lightmaps per surface was overkill for their gritty environments.
On the flip side though, ditching the RNM's and using dominant direction lights means consistent specular highlights and correct directions for them. Nothing was more frustrating than the RNM's blurring my spec highlights and even flipping the direction for modular pieces that had been rotated.
Lightmass sounds like a nice improvement to the engine overall but way late in the game in my opinion. I'd be curious to know how they autogen their second uv set for lightmaps and what the quality is like. What does a sphere or cylinder look like when it's unwrapped by the engine.
in UT3 it was very, very bad, the auto-uv'ing. Like 99% of cases unusable for me.
And I don't know if you should see it as late; Beast was there before Lightmass, Epic has just made their own solution now. Also I haven't really seen a convincing realtime GI system so far; the one from Cryengine 3 doesn't look as good as a decent lightmass bake and is way heavier on performance.
I think he meant baked = lame. Probably wants something more like Geomeric's "Enlighten" engine.
@Vassaago - I've seen the videos and screenshots, but have never seen a game or heard of a UE3 licensee integrating this. The programmers at my studio seem to scoff at the idea that could run in UE3 in realtime.
CCP games is integrating it, but into their own engine so I can't really tell about any performance in Ue3, but it's pretty fast (on very 'current gen' kind of configurations). Enlighten is not yet 'radiosity on the fly', it still has a notion of static vs dynamic. The pre process is pretty quick tough. What's especially nifty is the kind of data the engine outputs. There are two kinds reflecting the same realtime calculation of diffuse radiosity based on the 'baking'. One is 'lightmap space' textures and the other is a 3d grid but both are spherical harmonics so normal maps are easily taken into account, on both static and dynamic meshes.
Enlighten only outputs indirect lighting, the direct lighting is up to the engine (including usual problems like shadows). You easily connect that contribution of light to process the indirect light.
Some potential easy use, or that i've seen: light a whole scene just with the light coming from the windows based on a cubemap. Change the cubemap, change the whole indirect light realtime ; lighting a room just with the light from a television where a video feed plays ; building complex area lights like neon signs or disco floor comes for a fixed cost ; You don't use ambient: the skybox is emissive ; etc
The day screen based occlusion takes normal maps into consideration...
It's just a performance issue. If you already have normal maps in a screen buffer like in deferred rendering (see starcraftII) than you're good, otherwise it is often a lot more expensive than just rendering the whole scene vertex normals in one batch.
Sorry for not keeping this thread in the right direction
malcom the 2nd uv set is not auto-uved, There's an auto-uv tool but that's only used if an LD finds an old asset that doesn't contain 2nd uvs and they dont want to manually create UVs
So artists are unwrapping the meshes manually before they are exported from max?
For cleaner and more detailed light maps, manually unwrapping to a 2nd UV channel is ideal due to the messy nature of flatten mapping (although its fine to do if you want to stitch pieces back together). Unreal Editor has a feature in the Static Mesh Editor to auto generate UV's, which basically flatten maps the entire mesh but can result in messy lightmaps.
Its a matter of preference. Spend more time in a lightmap channel and the more quality out of lighting you'll get.
Cool thanks for the info. I'm well versed in manually unwrapping and baking environments but I'm always looking for a better automatic solution, doesn't sound like epic has anything magical in this respect.
To be honest I don't think you'll find a decent substitute for good artist created uvs.
What if there was a robot sent from the future who's sole purpose was to UV map things?
@ Malcolm - I have been guilty of the following in regards to semi-auto UVmapping: I get the mesh with properly UVmapped diffuse channel (with overlaps and shell stacking), dupe that UV channel, and scale UV's to mesh to make sure they have a somewhat even pixel rez across all areas and no overlaps, then I scale down all the less important/less screentime parts and re-pack by hand.
There is a handy-dandy tool/visual mode in UDK that shows you lightmap complexity with pixel density. Been using that a lot.
i'm still amazed that theres not been an auto pack program made yet that really works well. it seems like its a part of the process that could be done with a program seems like finding the best possible ways to pack something could be a verry mathmatical thing. i spend the majority of my unwraping time packing i fit them all in, but oh my i have spare room so enlarge everything and pack a bit more, oh no i scalled too much,, shrink back some.. so tedius
Lamont that robot was me on many a game. I personally find reusing the diffuse uv's to be a waste of time as I can regenerate a clean quality map in less time by hand. I could write a whole paper on lightmap packing resolution and do's and don'ts with all the research I've done on this subject. We've got a custom workflow in maya on our current project which I helped define takes about 3-5 clicks for 85% of our models. Every once in a while you will get a troublesome one like a high res tree with seamless twisty branches and you'll have to put time in.
Rhinokey sounds like you are talking about diffuse packing not lightmaps. If you're scaling your lightmaps by hand I would recommend just using the stretch to fit with the auto uv packing in whatever app you are using this will try to use all the remaining space.
i'm still amazed that theres not been an auto pack program made yet that really works well. it seems like its a part of the process that could be done with a program seems like finding the best possible ways to pack something could be a verry mathmatical thing. i spend the majority of my unwraping time packing i fit them all in, but oh my i have spare room so enlarge everything and pack a bit more, oh no i scalled too much,, shrink back some.. so tedius
Well, there's so much stuff you'd have to set up before it could pack decently. You'd be going over the mesh designating desired, allowed, and prohibited seam edges. You'd have to tell it areas you want to mirror or stack versus unique texels. You'd have to somehow tell it which areas get higher texel resolution priority if you have smaller details you need to have clear. And you have to teach the tool how to organize the packed map, so you're not hunting for parts when you're painting.
We investigated it briefly at my last studio, and it just ended up faster and better unwrapping and packing by hand. Somebody will write the tool eventually, but it's a ways off.
i didnt mean unwraping .. just packing so it would not have to worry about allowed seams or anything like that, just a check to tell it to keep overlaps together or a way to link overlaps so they dont seperate, and a check box to make it scale everything uniformly so it does not skew your pixel density i'd never allow a computer algorythym to determin where to divide my uvs (well not till i see a super smart one)
what i would like would to unwrap my model flip and mirror what i want, put the pixel density how i want it, then set a padding, like how close the pieces can fit, then have the robot put them in the most efficient way possible.
Replies
http://www.hourences.com/book/tutorialsue3lightmass.htm
It's basically the same as adding any other volume, only you choose the 'light something importance something' from the dropdown menu. And then you'll get some pretty fast builds, even on production quality (depending on level size ofc)
It's probably something along the lines of an Irradiance Volume:
http://developer.amd.com/media/gpu_assets/Tatarchuk_Irradiance_Volumes.pdf
Basically a 3d volume grid of ambient light points that gets baked at the same time as your lightmaps, and as dynamic models move through the volume their lighting changes to match the environment. It basically means you get a bit better ambient and subtle directional lighting for dynamic models.
@Vassaago - I've seen the videos and screenshots, but have never seen a game or heard of a UE3 licensee integrating this. The programmers at my studio seem to scoff at the idea that could run in UE3 in realtime.
The volume is really only used to determine how far photons should go when calculating lighting. Obviously if you only need them in a small area, bake times can be sped up and background lighting approximated. The nice side affect is that the volume is also used for the character lighting sample points.
Does lightmass also bake colors? Like Beast (right?) for Mirrors Edge? If so that's kinda big aswell.
DEE, I find it disappointing to see that on the Marcus screen you posted, there is no presence of 'dark in the cracks' effect on the character standing in the shade, as opposed to the nice occluded shading of the inside wall.
Is the realtime screen space AO from GoW2 present in UDK ?
I believe it is, you can see it in the editor.
On a second note, anyone know if it's adjustable like in CE2?
that's what I meant with q3 has been doing this, too. It is nice indeed.
Yes it does. Although they have removed the awesome RNM tech ( "Radiosity Normal Mapping" ).
I guess they thought 3 X RGB lightmaps per surface was overkill for their gritty environments.
You still get the intensity from each direction representated in the normals but you wont get colours.
On the flip side though, ditching the RNM's and using dominant direction lights means consistent specular highlights and correct directions for them. Nothing was more frustrating than the RNM's blurring my spec highlights and even flipping the direction for modular pieces that had been rotated.
And I don't know if you should see it as late; Beast was there before Lightmass, Epic has just made their own solution now. Also I haven't really seen a convincing realtime GI system so far; the one from Cryengine 3 doesn't look as good as a decent lightmass bake and is way heavier on performance.
btw Malcolm, just test the damn thing, it's free
Enlighten only outputs indirect lighting, the direct lighting is up to the engine (including usual problems like shadows). You easily connect that contribution of light to process the indirect light.
Some potential easy use, or that i've seen: light a whole scene just with the light coming from the windows based on a cubemap. Change the cubemap, change the whole indirect light realtime ; lighting a room just with the light from a television where a video feed plays ; building complex area lights like neon signs or disco floor comes for a fixed cost ; You don't use ambient: the skybox is emissive ; etc
It's just a performance issue. If you already have normal maps in a screen buffer like in deferred rendering (see starcraftII) than you're good, otherwise it is often a lot more expensive than just rendering the whole scene vertex normals in one batch.
Sorry for not keeping this thread in the right direction
http://www.crytek.com/technology/presentations/
For cleaner and more detailed light maps, manually unwrapping to a 2nd UV channel is ideal due to the messy nature of flatten mapping (although its fine to do if you want to stitch pieces back together). Unreal Editor has a feature in the Static Mesh Editor to auto generate UV's, which basically flatten maps the entire mesh but can result in messy lightmaps.
Its a matter of preference. Spend more time in a lightmap channel and the more quality out of lighting you'll get.
@ Malcolm - I have been guilty of the following in regards to semi-auto UVmapping: I get the mesh with properly UVmapped diffuse channel (with overlaps and shell stacking), dupe that UV channel, and scale UV's to mesh to make sure they have a somewhat even pixel rez across all areas and no overlaps, then I scale down all the less important/less screentime parts and re-pack by hand.
There is a handy-dandy tool/visual mode in UDK that shows you lightmap complexity with pixel density. Been using that a lot.
Rhinokey sounds like you are talking about diffuse packing not lightmaps. If you're scaling your lightmaps by hand I would recommend just using the stretch to fit with the auto uv packing in whatever app you are using this will try to use all the remaining space.
Well, there's so much stuff you'd have to set up before it could pack decently. You'd be going over the mesh designating desired, allowed, and prohibited seam edges. You'd have to tell it areas you want to mirror or stack versus unique texels. You'd have to somehow tell it which areas get higher texel resolution priority if you have smaller details you need to have clear. And you have to teach the tool how to organize the packed map, so you're not hunting for parts when you're painting.
We investigated it briefly at my last studio, and it just ended up faster and better unwrapping and packing by hand. Somebody will write the tool eventually, but it's a ways off.
what i would like would to unwrap my model flip and mirror what i want, put the pixel density how i want it, then set a padding, like how close the pieces can fit, then have the robot put them in the most efficient way possible.