I just flew in and boy are my arms tired.
by David Chan · 06/11/2009 (1:57 pm) · 7 comments
Okay, now that we've got the bad jokes out the way I'd like to introduce myself. My name is Dave Chan and I work at pureLIGHT Technologies. We make a static lighting solution that has been in use for a few years in architecture and simulation. My back ground is in videogames. I worked at BioWare for almost 6 years. When I started at pureLIGHT I thought that the games industry could use a powerful tool like pureLIGHT and everyone agreed. As luck happens we did a demo for Torque guru Logan Foster who put us in touch with the Garage Games folks. It was instant chemistry. We understood the indie ethic that GG has and they understood the potential that pureLIGHT brings to their game engine. The rest is as they say, history. There have already been quite a few questions about pureLIGHT posted so I am going to try and answer a few of them here.
penbit
It looks absolutely great!
I have a question about this comment though
"Because all the lighting information is baked into your material, very little if any dynamic lighting and shadowing need to occur"
Since the prototype I intend to make relies heavily on dynamic lights & shadows, how can I benefit from purelight? (example: think of splinter cell or thief games, where the player can/will toogle the lights in the mission on and off.
So, after my lights are baked, can the player and ai cast regular shadows?
If an area's lights are baked in this fashion, what are my chances of using dynamic lights?
Thanks, keep up the good work guys! (It looks like after searching for an engine for such a long time, torque3d will be my last stop:))
We have had great success using pureLIGHT in hybrid scenes combining static and dynamic lighting (such as adding a flickering candle to the Den scene). We are working to make pureLIGHT function well with Advanced Lighting, such that you can have a dynamically lit character (with dynamic shadow) walk through a pureLIGHT scene. As for approximating shadow locations and such (ie a characters shadow from an object light), you can have dynamic lights placed (for vehicles and characters) that are different or in addition to those used for pureLIGHT.
We have also had success baking alternate sets of lightmaps, and using code to cycle between them; for example, you could fairly easily bake a room with lights turned on and lights turned off, and then use code to swap out the lightmaps. The dark room would have all the dramatic and subtle indirect lighting (such as light through a window).
Greg G
Super exciting I can't wait to use this. Sorry if this was posted and I missed but what are the exact number of steps to get a scene out of Torque3D and into purelight? Can I place lights in torque 3D and then export those to purelight? How exactly does that interface work?
The process us currently to take geometry from Max / Maya / Blender / Other, run this through preLIGHT (which generates unwrapping / manages lightmap resolution), bake it in pureLIGHT, and then load the results into Torque. Characters, weapons, dynamic lights, etc are all then setup and managed in Torque like usual. Because pureLIGHT allows baking of small sections / individual meshes and such, its very possible to bake changes or extra sections without needing to redo an entire scene.
Gerald Fishel
Good stuff. Hard to tell from those screenshots and Youtube video what the actual quality of the lightmaps are, but it's obviously a huge leap forward from from any of the previous lightmap solutions in Torque.
One of the problems we've had with some automated light baking systems that we've tried is that they don't unwrap optimally with complex geometry, and in fact I have yet to see an automatic unwrapping algorithm that works great in those cases, and it has been difficult to get them to handle manually unwrapped geometry easily.
It will be a tough sell to get us away from Mental Ray at this point, but if it will handle manual unwrapping, along with the realtime preview, it might be possible :P
We used to use Mental Ray for our architectural lighting, but the workflow was one of the main reasons we developed pureLIGHT in the first place. While pureLIGHT allows you to use your own mapping (occasionally handy for extreme geometry), its automatic unwrapping is quite robust (even on complex shapes) and will always provide consistent, high quality, lighting. (You do not have to worry about seams or other common artifacts). Additionally, preLIGHT lets you easily manage the lightmap resolution for different objects, allowing you to get the most visual bang for your video memory buck. Here are some shots to show a level with and without pureLIGHT.



Hey, this looks amazing. The radiosity calculation is fantastic.
But I did not see any shaders in the example. Will it work with normal- and spec mapping? If yes, then it could create quality similar to Source or Unreal-Engine.
I would love to see an example like this.
HangingGardens is a good demonstration of pureLIGHT with shaders - otherwise our demos are focused more on the lighting than any noisy effects. We currently do not support the full directional lightmaps that Unreal and Source use, though we are exploring options to make best use of baked lighting with next generation effects.
Oliver
Great work :)
The examples are strongly focused on indoor environments. What about Outdoor, how das the lightmapping work with all the ohter stuff like. HDR, Rays, shadows, normals, specs, paralax, DOF 'shaderstuff' etc. together?
Do you have a similar video of an outdoorenvironment?
What about the performance of this system (indoor/outdoor)?
Do i ship the lightmap with the product or will they be generated at startup?
thanx, and amazing work :)
Oliver
Lightmaps should work just fine with any other post process effects. We have used pureLIGHT with great success in outdoor environments, though due to size and noisy textures, the results tend to be less dramatic than indoor scenes (hence the bias in our demo). The biggest trade-off for outdoor environments will be that you may (potentially) need more / larger lightmaps (which pureLIGHT can provide) - only performance concern is that these lightmaps can start using large amounts of video memory. There are a number of solutions though, the first being to leverage preLIGHT’s scene management capability and focus lightmap resolution where you actually need it. You can also compress lightmaps (greyscale works fairly well for basic exterior sunlight, especially if you add in color via the material). If you are talking about _extreme_ environment sizes, you could use standard dynamic lighting on the terrain but bake a house or building sitting on the terrain - thus getting all the subtle indirect light on the building where it’s really needed.
In general though, because the lighting is baked you get a substantial performance boost by having baked in lighting, and using dynamic lights only where needed.
Do i ship the lightmap with the product or will they be generated at startup?
Though pureLIGHT has a real-time, iterative process, the actual lighting still has to be baked. (Though thanks to this process, you can actually accomplish such baking on a standard consumer PC - HangingGardens was built and baked on a laptop). Because lightmaps are baked, you will be shipping the final lightmaps with your games (not unlike a set of specialized texture assets).
ando
If PureLight is baked into the world environment would it have any effect on a character? Would the character light according to light and shadow? For example it would be odd to go inside a dark cave and the character is still fully bright.
Basically your map will have two sets of lights. While these could be shared (we do have the ability to flag certain dynamic properties on the pureLIGHT lightsources), you could easily adjust and customize each set for optimal effect. This means that pureLIGHT is used on the background (ie the walls of your cave) and a set of dynamic lights are used to actually light and shadow the character.
As an artist I realy would love to put PureLight through its paces and create some true T3D examples.
We are very excited to hear this, and are looking forward to what you can come up with. If you have any questions as to how best produce a certain effect or scene, feel free to ask!
Luke Lamothe
I assume that it will work on DTSs as well as DIFs and Terrain?
As well, it wont take up the 2nd UV channel that T3D meshes support, correct?
Thanks :)
Currently pureLIGHT only works on collada files brought into Torque - though we are looking at options to take data generated in Torque and load it / Unwrap it in pureLIGHT.
The 2nd UVW channel is key to lightmapping - this is how we get lightmaps mapped to a surface that may have a tiling texture with alternate mapping solutions. There are a few options around this depending on your scene, and you can also use Vertex Lighting which does not require any dedicated uvw channel.
Gerald Fishel
When you say you support manual unwrapping, that means you support the unwrapping as a separate UV channel in the imported object(s)?
There are 2 major problems that always seem to occur with automatic unwrapping. The first is the spacing out of tiny UV faces, and when you have objects with small areas of high density polys and larger areas of large polys, the small areas end up taking up and wasting more lightmap space than the larger areas which is annoying.
The other problem usually comes from long skinny objects, which if you're lucky will get to use 10% of a lightmap, because unwrappers insist that texture stretching is *always* undesirable. Which it usually is, but texture stretching on lightmaps is preferable to miniscule lightmap coverage on long skinny objects :P
I will be interested in seeing how your unwrapping handles these things.
pureLIGHT, by default, supplies lighting on the 2nd UVW channel. You can manually provide this mapping information, though for 95% of cases the automatic unwrapping is more than sufficient. preLIGHT’s automatic unwrapping is designed to make the most out of lightmaps as quickly and efficiently as possible.
While fragmented meshes can result in many small pieces, preLIGHT will ensure that there are no overlaps or seams, and that only the bare minimum of a space is used between the pieces. If such a mesh is still a problem, one of preLIGHT’s key features is the ability to manage the resolution of different meshes; so in the case you describe, I would export the large flat surface and give it a higher resolution, and then export the fragmented portion either with lower resolution or as a Vertex Lit asset.
For long skinny sections, stretching is generally a bit dangerous but preLIGHT will work with non square lightmaps; meaning you could have all the long portions fit within a 2048x64 lightmap with little wasted space. The uglier case in our experience is the dreaded L shape; preLIGHT contains an extremely aggressive unwrapping approach for such cases that breaks large L shapes down into component rectangles.
One point related to the unwrapping though, is that pureLIGHT has some advanced filtering techniques used the lighting itself; this is what produces the characteristic smooth quality of pureLIGHT lighting. Because of this filtering, even an extremely fragmented lightmap can still look perfectly smooth to the end user - meaning you can likely get away with lower resolution and still get the visual results you are looking for.
In the unlikely case that the above still doesn’t work for your particular mesh, then you can provide a manual unwrapping - while you can risk lighting artifacts this way, you are definitely able to have minor stretching and differently scaled sections within a single lightmap.
I'd like to thank our Technical Director Andrew Czarnietzki for taking time out of his busy schedule to help answer these questions. Keep them coming folks. We plan to have full tutorials up on using pureLIGHT at some point in the near future. I'll keep everyone posted as they are made available.
penbit
It looks absolutely great!
I have a question about this comment though
"Because all the lighting information is baked into your material, very little if any dynamic lighting and shadowing need to occur"
Since the prototype I intend to make relies heavily on dynamic lights & shadows, how can I benefit from purelight? (example: think of splinter cell or thief games, where the player can/will toogle the lights in the mission on and off.
So, after my lights are baked, can the player and ai cast regular shadows?
If an area's lights are baked in this fashion, what are my chances of using dynamic lights?
Thanks, keep up the good work guys! (It looks like after searching for an engine for such a long time, torque3d will be my last stop:))
We have had great success using pureLIGHT in hybrid scenes combining static and dynamic lighting (such as adding a flickering candle to the Den scene). We are working to make pureLIGHT function well with Advanced Lighting, such that you can have a dynamically lit character (with dynamic shadow) walk through a pureLIGHT scene. As for approximating shadow locations and such (ie a characters shadow from an object light), you can have dynamic lights placed (for vehicles and characters) that are different or in addition to those used for pureLIGHT.
We have also had success baking alternate sets of lightmaps, and using code to cycle between them; for example, you could fairly easily bake a room with lights turned on and lights turned off, and then use code to swap out the lightmaps. The dark room would have all the dramatic and subtle indirect lighting (such as light through a window).
Greg G
Super exciting I can't wait to use this. Sorry if this was posted and I missed but what are the exact number of steps to get a scene out of Torque3D and into purelight? Can I place lights in torque 3D and then export those to purelight? How exactly does that interface work?
The process us currently to take geometry from Max / Maya / Blender / Other, run this through preLIGHT (which generates unwrapping / manages lightmap resolution), bake it in pureLIGHT, and then load the results into Torque. Characters, weapons, dynamic lights, etc are all then setup and managed in Torque like usual. Because pureLIGHT allows baking of small sections / individual meshes and such, its very possible to bake changes or extra sections without needing to redo an entire scene.
Gerald Fishel
Good stuff. Hard to tell from those screenshots and Youtube video what the actual quality of the lightmaps are, but it's obviously a huge leap forward from from any of the previous lightmap solutions in Torque.
One of the problems we've had with some automated light baking systems that we've tried is that they don't unwrap optimally with complex geometry, and in fact I have yet to see an automatic unwrapping algorithm that works great in those cases, and it has been difficult to get them to handle manually unwrapped geometry easily.
It will be a tough sell to get us away from Mental Ray at this point, but if it will handle manual unwrapping, along with the realtime preview, it might be possible :P
We used to use Mental Ray for our architectural lighting, but the workflow was one of the main reasons we developed pureLIGHT in the first place. While pureLIGHT allows you to use your own mapping (occasionally handy for extreme geometry), its automatic unwrapping is quite robust (even on complex shapes) and will always provide consistent, high quality, lighting. (You do not have to worry about seams or other common artifacts). Additionally, preLIGHT lets you easily manage the lightmap resolution for different objects, allowing you to get the most visual bang for your video memory buck. Here are some shots to show a level with and without pureLIGHT.



Hey, this looks amazing. The radiosity calculation is fantastic.
But I did not see any shaders in the example. Will it work with normal- and spec mapping? If yes, then it could create quality similar to Source or Unreal-Engine.
I would love to see an example like this.
HangingGardens is a good demonstration of pureLIGHT with shaders - otherwise our demos are focused more on the lighting than any noisy effects. We currently do not support the full directional lightmaps that Unreal and Source use, though we are exploring options to make best use of baked lighting with next generation effects.
Oliver
Great work :)
The examples are strongly focused on indoor environments. What about Outdoor, how das the lightmapping work with all the ohter stuff like. HDR, Rays, shadows, normals, specs, paralax, DOF 'shaderstuff' etc. together?
Do you have a similar video of an outdoorenvironment?
What about the performance of this system (indoor/outdoor)?
Do i ship the lightmap with the product or will they be generated at startup?
thanx, and amazing work :)
Oliver
Lightmaps should work just fine with any other post process effects. We have used pureLIGHT with great success in outdoor environments, though due to size and noisy textures, the results tend to be less dramatic than indoor scenes (hence the bias in our demo). The biggest trade-off for outdoor environments will be that you may (potentially) need more / larger lightmaps (which pureLIGHT can provide) - only performance concern is that these lightmaps can start using large amounts of video memory. There are a number of solutions though, the first being to leverage preLIGHT’s scene management capability and focus lightmap resolution where you actually need it. You can also compress lightmaps (greyscale works fairly well for basic exterior sunlight, especially if you add in color via the material). If you are talking about _extreme_ environment sizes, you could use standard dynamic lighting on the terrain but bake a house or building sitting on the terrain - thus getting all the subtle indirect light on the building where it’s really needed.
In general though, because the lighting is baked you get a substantial performance boost by having baked in lighting, and using dynamic lights only where needed.
Do i ship the lightmap with the product or will they be generated at startup?
Though pureLIGHT has a real-time, iterative process, the actual lighting still has to be baked. (Though thanks to this process, you can actually accomplish such baking on a standard consumer PC - HangingGardens was built and baked on a laptop). Because lightmaps are baked, you will be shipping the final lightmaps with your games (not unlike a set of specialized texture assets).
ando
If PureLight is baked into the world environment would it have any effect on a character? Would the character light according to light and shadow? For example it would be odd to go inside a dark cave and the character is still fully bright.
Basically your map will have two sets of lights. While these could be shared (we do have the ability to flag certain dynamic properties on the pureLIGHT lightsources), you could easily adjust and customize each set for optimal effect. This means that pureLIGHT is used on the background (ie the walls of your cave) and a set of dynamic lights are used to actually light and shadow the character.
As an artist I realy would love to put PureLight through its paces and create some true T3D examples.
We are very excited to hear this, and are looking forward to what you can come up with. If you have any questions as to how best produce a certain effect or scene, feel free to ask!
Luke Lamothe
I assume that it will work on DTSs as well as DIFs and Terrain?
As well, it wont take up the 2nd UV channel that T3D meshes support, correct?
Thanks :)
Currently pureLIGHT only works on collada files brought into Torque - though we are looking at options to take data generated in Torque and load it / Unwrap it in pureLIGHT.
The 2nd UVW channel is key to lightmapping - this is how we get lightmaps mapped to a surface that may have a tiling texture with alternate mapping solutions. There are a few options around this depending on your scene, and you can also use Vertex Lighting which does not require any dedicated uvw channel.
Gerald Fishel
When you say you support manual unwrapping, that means you support the unwrapping as a separate UV channel in the imported object(s)?
There are 2 major problems that always seem to occur with automatic unwrapping. The first is the spacing out of tiny UV faces, and when you have objects with small areas of high density polys and larger areas of large polys, the small areas end up taking up and wasting more lightmap space than the larger areas which is annoying.
The other problem usually comes from long skinny objects, which if you're lucky will get to use 10% of a lightmap, because unwrappers insist that texture stretching is *always* undesirable. Which it usually is, but texture stretching on lightmaps is preferable to miniscule lightmap coverage on long skinny objects :P
I will be interested in seeing how your unwrapping handles these things.
pureLIGHT, by default, supplies lighting on the 2nd UVW channel. You can manually provide this mapping information, though for 95% of cases the automatic unwrapping is more than sufficient. preLIGHT’s automatic unwrapping is designed to make the most out of lightmaps as quickly and efficiently as possible.
While fragmented meshes can result in many small pieces, preLIGHT will ensure that there are no overlaps or seams, and that only the bare minimum of a space is used between the pieces. If such a mesh is still a problem, one of preLIGHT’s key features is the ability to manage the resolution of different meshes; so in the case you describe, I would export the large flat surface and give it a higher resolution, and then export the fragmented portion either with lower resolution or as a Vertex Lit asset.
For long skinny sections, stretching is generally a bit dangerous but preLIGHT will work with non square lightmaps; meaning you could have all the long portions fit within a 2048x64 lightmap with little wasted space. The uglier case in our experience is the dreaded L shape; preLIGHT contains an extremely aggressive unwrapping approach for such cases that breaks large L shapes down into component rectangles.
One point related to the unwrapping though, is that pureLIGHT has some advanced filtering techniques used the lighting itself; this is what produces the characteristic smooth quality of pureLIGHT lighting. Because of this filtering, even an extremely fragmented lightmap can still look perfectly smooth to the end user - meaning you can likely get away with lower resolution and still get the visual results you are looking for.
In the unlikely case that the above still doesn’t work for your particular mesh, then you can provide a manual unwrapping - while you can risk lighting artifacts this way, you are definitely able to have minor stretching and differently scaled sections within a single lightmap.
I'd like to thank our Technical Director Andrew Czarnietzki for taking time out of his busy schedule to help answer these questions. Keep them coming folks. We plan to have full tutorials up on using pureLIGHT at some point in the near future. I'll keep everyone posted as they are made available.
About the author
Got my start at BioWare in 1999. First project was MDK2 and last project was Mass Effect. Since then I've worked on indie titles and other games like Prey and Splinter Cell. Got my start at pureLIGHT late last year as the Product Manager.
#2
Yeah I had to do some heavy lifting to get our tools where the workflow was manageable with Mental Ray, but the end results are amazing. We can do iterative baking with various quality settings pretty easily and relatively quickly now. However, the final high-quality bake on a complex level still takes a day on our little render farm :o And the licensing for the stand-alone MR is a PITA.
Yeah the problem with the non-square lightmap scenario is that not all hardware supports that gracefully. In some cases we would just break the geometry down into smaller pieces, but in other cases the precision of the shadows doesn't matter as much and stretching out the lightmaps still gives a better overall look while not wasting texture space or using oddly dimensioned textures. It doesn't have to be correct as long as it looks good :P
In any case, it's good to know that it supports manual unwrapping.
I just have two more questions.
1) Is there a command-line or network interface, or a library interface, or does it all have to be done with the pureLIGHT GUI?
2) When? This really does sound like an excellent product, and may be the tipping point for finally succumbing to the pressure and upgrading our current project to T3D. Any ETA on when it will be available for the masses?
06/11/2009 (2:48 pm)
Cool, thanks for the answers.Quote:
We used to use Mental Ray for our architectural lighting, but the workflow was one of the main reasons we developed pureLIGHT in the first place.
Yeah I had to do some heavy lifting to get our tools where the workflow was manageable with Mental Ray, but the end results are amazing. We can do iterative baking with various quality settings pretty easily and relatively quickly now. However, the final high-quality bake on a complex level still takes a day on our little render farm :o And the licensing for the stand-alone MR is a PITA.
Quote:
For long skinny sections, stretching is generally a bit dangerous but preLIGHT will work with non square lightmaps; meaning you could have all the long portions fit within a 2048x64 lightmap with little wasted space. The uglier case in our experience is the dreaded L shape; preLIGHT contains an extremely aggressive unwrapping approach for such cases that breaks large L shapes down into component rectangles.
Yeah the problem with the non-square lightmap scenario is that not all hardware supports that gracefully. In some cases we would just break the geometry down into smaller pieces, but in other cases the precision of the shadows doesn't matter as much and stretching out the lightmaps still gives a better overall look while not wasting texture space or using oddly dimensioned textures. It doesn't have to be correct as long as it looks good :P
In any case, it's good to know that it supports manual unwrapping.
I just have two more questions.
1) Is there a command-line or network interface, or a library interface, or does it all have to be done with the pureLIGHT GUI?
2) When? This really does sound like an excellent product, and may be the tipping point for finally succumbing to the pressure and upgrading our current project to T3D. Any ETA on when it will be available for the masses?
#3
06/11/2009 (3:30 pm)
Thanks for the info David, it all sounds interesting. I also found the thread on beyondunreal forums about VCTF-HangingGardens. Interesting read there as well.
#4
Right now the only means of rendering is the GUI interface. A big part of the workflow is beong able to see what is happening. We have talked about network rendering, but it hasn't gone past the "to be investigated" stages. As for when, we plan to ship when T3D does. We also hope to do a limited beta test with a group of users, but haven't worked out the details on that with Garage Games yet. Just to dangle the carrot even closer there may be some incentives for early adopters as well, but I can't say much at the moment ;)
@penbit
The Hanging Gardens map was a labor of love for our Technical Director Andrew and his cousin Nathan. Seeing how T3D is coming along, I see no reason why there can't be that level of art in Torque when it's released. Polished with pureLIGHT of course :)
06/11/2009 (4:00 pm)
@GeraldRight now the only means of rendering is the GUI interface. A big part of the workflow is beong able to see what is happening. We have talked about network rendering, but it hasn't gone past the "to be investigated" stages. As for when, we plan to ship when T3D does. We also hope to do a limited beta test with a group of users, but haven't worked out the details on that with Garage Games yet. Just to dangle the carrot even closer there may be some incentives for early adopters as well, but I can't say much at the moment ;)
@penbit
The Hanging Gardens map was a labor of love for our Technical Director Andrew and his cousin Nathan. Seeing how T3D is coming along, I see no reason why there can't be that level of art in Torque when it's released. Polished with pureLIGHT of course :)
#5
Alright. Please think about providing some way to stick pureLIGHT in the middle of a custom workflow rather than having to use the GUI for it :D I'm sure the preview is really useful, but so is being able to kickoff a render job directly from a level editing tool after making some level adjustments when you already know that the lighting is setup correctly, so you can just move on and start working on something else while it goes. That's another big reason that we like Mental Ray; we can just click a button in our level editor and let it go right to the render servers.
What would be really awesome would be a network or service-based renderer that can kick back the previews to the client if requested.
Just some ideas. I'm sure it's great how it is, I'm just a big fan of custom tools, and thus a big fan of tools that can be leveraged from other tools :p
06/11/2009 (6:25 pm)
@David,Alright. Please think about providing some way to stick pureLIGHT in the middle of a custom workflow rather than having to use the GUI for it :D I'm sure the preview is really useful, but so is being able to kickoff a render job directly from a level editing tool after making some level adjustments when you already know that the lighting is setup correctly, so you can just move on and start working on something else while it goes. That's another big reason that we like Mental Ray; we can just click a button in our level editor and let it go right to the render servers.
What would be really awesome would be a network or service-based renderer that can kick back the previews to the client if requested.
Just some ideas. I'm sure it's great how it is, I'm just a big fan of custom tools, and thus a big fan of tools that can be leveraged from other tools :p
#6
Understood. As I mentioned before, we are keeping track of features people want and some may indeed make it into future versions.
06/11/2009 (8:11 pm)
@Gerald,Understood. As I mentioned before, we are keeping track of features people want and some may indeed make it into future versions.
#7
06/11/2009 (11:36 pm)
David: Thank you for taking the time and answering my question! I appreciate this.
Torque 3D Owner Kenneth Holst
Default Studio Name