The Inner working of the Undercity Demo

#1 I do like the curved surfaces, makes it feel much more organic than lots of flat, rectangular walls.

How much of a performance hit does the dynamic lighting give?

#2 Hehe, I saw that demo come together, and you guys did a great job on that level! You should definitely show the light and shadows being affected by the overhead fan.

#3 @Steve, the lights themselves have very little performance impact. Having them cast shadows is typically what ends up costing you, but there are a bunch of options for what type of shadow map it can use, and the shadows have LOD so that if you're out of range or the like, they won't update (if I remember correctly).

#4 Beautiful screenshots. One question on the 02 screenshot, the purpleish stuff on the ground near the camera. Are those decals or part of the texture?

#5 Awesome!
Can't wait to see some video.

#6 Hey Logan,

Few questions and nitpicks, first do you have anisotropic filtering on? The textures seem to get very muddy after a few feet. The second image also has a strange blurring of the floor texture right at the bottom any idea what this is about? Also I notice the shadows mostly go to full black, does this demo support some kind of ambient lighting system so we don't have to have this happen? Also I'm happy to hear the amount of .dts models in the scene it sounds promising, any idea how many textures, and what the average resolution is? Lastly, I noticed you said that there was no use of .diff/bsp brushes, why did you decide to go this route? Wouldn't building atleast the base level out of bsp have many benefits, or does T3D work better with .dts models?

#7 And how about visibility culling without BSP? How is it working?

#8 Hi, Logan Foster, Where you get the Torque3D, I have purchased it, but nothing is available in my account.It there a beta one already available for T3D owner?

#9 @Huan: The beta is not yet available.

#10 GG gave out several copies to key peeps call "TORQUE3D HANDS ON PREVIEW" it shows up on some peoples mini-profile.

#11 *wipes drool off mouth* ... Wow. :)

#12 Sorry for the delay in posting any responses/updates I got caught yesterday finishing some work for Lore Aftermath and didn't have a chance to look at capturing any video until much later in the evening.

With that said here is a quick video I took and pulled together of the environment. The first half just quickly shows off how dynamic the lights are updating in real-time as the light's position and color change as well as how it reacts to animated objects in the scene such as the fan blades, the player model or the spinning healthkit item. The second half of the video is just me walking around some of the environment to show it off a bit more.


Note: I had to capture the video with Camtasia so the framerate isn't great. Also I am posting this while the video is being processed by Vimeo so there might be a 30 minute delay until its ready.

#13 @Steve

A few lights don't cause too much of a performance hit, but using a lot of lights like we did, and I will fully admit in a careless manner too since the goal was to just make it look nice and not optimal, will cause degredation. So with that said it's something you really need to use intelligently if you want to hit a wide range of PC without hindering performance.

In a perfect world however a person would actually use lightmaps to handle most of the lighting on this level (since the lighting is fairly static) and have only a few dynamic lights which cast shadows onto everything else.

@Michael

Thanks.

@JC

Purplish stuff? That might be the treadplate on the stairs that you are refering to picking up the blue and green lighting that in that scene, however it shouldnt be appearing purplish (unless you are talking like a real faint purple hue).

@Brian

I am unsure if antisotropic filter is on or not... but probably not.

With regards to the Ambient lighting, there is only the faintest of ambient lighting in the scene (I am personally not a fan of pitch black darkness). There are two reasons for this. The first is that ambient lighting is a vicious lighting hack from back in the days when games couldn't do more than just a directional light and we needed a way to fake how the light rays bounce and fill light throughout your scene (ie. radiosity). The big issues with it is that it casts the same even amount of light from all directions which can cause depth and form to be lost and depending on the system can make your scene look washed out. The other reason for not using much ambient is that we really just wanted to show that this scene was being lite solely by rays from the lights, there were/are no hacks or cheats involved. Here is a really good article posted by one of the guys who develops Mental Ray, discussing the problems with Ambient Lighting (and how to best correct them, but in a higher end radiosity solutions).

With regards to textures I belive there are about 20 textures in use in this scene (most are about 512x512) including normal maps.

With regards to DIFs, GG informed us when we started this that the DIF format is basicly going to be considered as a deprecated format for T3D and we should use Collada instead. This made me very happy, though it worried Adrian a little bit initially since hes familiar with BSP. While I know that there are some benefits to DIF, from an artistic standpoint it's a pain in the ass to work with and slows down productivity. There is no possible way I could have built such a scene like I did as a BSP, nevermind do all the necessary tweaks and adjustments to it in real-time. Plus there's the fact that if you really want to make things look next-gen its not just a matter of having high resolution bitmaps and per-pixel effects that sells the look, its also in a large part having nice smooth looking geometry whose faces don't meet at hard edges. Another thing to keep in mind too is that most game engines out there have moved away from BSP and instead use a variety of methods to simply prevent non-visible or occluded polygons from rendering (Unreal goes this route). Someone from GG would have to tell you the method they use, I just push pixels :)

@Andrea

Hopefully someone from GG that isn't swamped with getting T3D ready to release will have a moment to post some information on what they are doing.

@All

One thing to keep in mind with lighting too is that at best shaders are written to handle up to 4 lights being cast on them. I could be wrong on this but I believe that most of the stuff in TGEA (and possibly T3D but I will let someone with knowledge on this correct or confirm it) only handles 2 lights. So you really don't want to try to cram too many lights into a small area. But with that said, normal bump maps really shine when you can put at least 2 light onto the model since it gives the math 2 sets of lighting vectors to calculate from.

#14 @Logan, well, with the deferred renderer, you don't really get the exponential hit for lights that you used to with the forward renderer (since instead of rendering a certain object up to 4 times, it only has to render X lights into the light buffer, then sample from that one light buffer texture when rendering the regular geometry). So the main thing that will cause performance hits with the lights now is if you have them casting shadows.

#15 Since I am no longer under NDA to Autodesk for Max 2010 I can show some screenshots of the primary level shape/object that the Undercity demo uses.


Click here to see larger version.

As I mentioned before all of the objects that we created for Undercity are either DTS or Collada, depending on what we needed from the object. Since I was helping to test 3DS Max 2010 at the time I figured I would use it to do all the Collada export and Max 2009 to do the DTS work (since I dont have an exporter for 2010 that does DTS).

The Collada shapes were exported using the standard Filmbox plugin that most of the Autodesk software ships with, then loaded into Torque. Collision is handled by the new polysoup options (that you have probably seen demoed before). For the most part Polysoup works great out of the box, there are a few small caveats such as dont have faces on your model smaller than 0.1 units in size (the collision fails and will stop the player model dead in its tracks) but for brainless collision generation you cannot really complain :)

Some basic info on shape:
- Its almost 35,000 polygons all broken up into various different nodes.
- Smoothing groups are used to hide a lot of edges. Only when a texture changed did we consider allowing the smoothing group to form a hard edge. A lot of the detail comes from the camfering of edges which helps reduce that hard 90 degree angle you see while allowing the smoothign to properly blend between faces.
- The tunnels were made originall as straight segments and then I simply used various modifiers like Bend to give them their rounded corners.Everything was kept as an editable poly since it allows for a person to quickly add or take away edge loops quickly, much like you would when character modeling.
- The rooms were added to as time went on to make them more detailed. A lot of the shapes were dupilicated, slightly modified and reused to help fill the scene up. Other detail was quickly modelled into the room via simple modeling techinques. Basicly all of this was done to create more form to vary up the rooms as well as create more shapes for the lighting to work with to cast shadows.
- Basicly it was all very iterative. As soon as I had the basic shape setp and working, it allowed Adrian to go in and start to place stuff. Since Torque3D updates art changes on the fly, it was pretty simple for one of us to work on making the level art changes and another place it without disrupting work flow.


Click here to see larger version.


Click here to see larger version.


Click here to see larger version.


Click here to see larger version.


Click here to see larger version.


Click here to see larger version.

#16 Another thing to mention is that alot of the optimization for Torque 3D lighting has not occured yet.

So with 45 lights the system is working pretty damn sweet already.

I just commited shadow LOD into the trunk yesterday... that should improve the Undercity level to some extent (i haven't tested it).

Also as i write this i just considered that we can easily use the brand spanking new GFXOcclusionQuery object to further optimize shadow updates for tight levels like this one.

#17 @Logan: The purpleish stuff I was referring to was upon viewing the video a shadow cast by the overhead fan I believe. Wasn't purple after all, was just the tint in the shot. The fan and moving the lights around while placing gave a good demonstration of the lighting BTW.

For now I'll soak in the last sentence of Tom's post and let my mind wonder. =)

#18 So a little follow up... GFXOcclusionQuery rules.

I've cut down shadow updates in Undercity by more than half just with that. Places where it wanted to update 15-20 shadows to render the frame... its now updating 7 or 9 shadows. Frame rate is stable in debug builds in most areas of the map.

I'm now looking at a little smarter prioritization of shadow updates and adding a shadow render time budget. This should allow it to scale much better.

Did i mention that we haven't even really started optimizing things? ;)

#19 Great work Tom, you guys sure are whipping up and appetite for Torque 3D

#20 Are there potential performance problems to expect from occlusion queries in SLI / CF scenarios with alternate frame rendering?