Smoothing Lightmaps Across Faces / Brushes
by Dale Best · in Torque Game Engine · 03/05/2007 (6:19 am) · 8 replies
As far as we can see from the Torque Engine, lightmaps do not get created in a smooth fashion across faces. For example, if you have a cylinder, each strip of it will have a uniquely colored face, instead of being lit smoothly (ie. flat shaded instead of gourard shaded).
My question is this: I see that in the Torque Constructor updates, they have implemented this feature and I was wondering if anybody else has perhaps implemented something similar into Torque itself already?
Not being familiar with how exactly lightmaps are generated in Torque, I would imagine that it would be quite a complex change. However, at its heart it should only require the use of a set of vertex normals per surface (each one being created from averaging the adjacent faces which are within a certain angle tolerance value), and then the lightmap for that face would be generated from these interpolated light values at each UV, instead of a single harsh color that is merely set for the entire face. These normals could be set to be calculated from only faces on the actual brush, or it could go through any neighboring brushes and look for adjacent faces so that things like inclined sections of ground made up of multiple brushes would have a much more natural lighting appeal to them as well.
Any takers?
My question is this: I see that in the Torque Constructor updates, they have implemented this feature and I was wondering if anybody else has perhaps implemented something similar into Torque itself already?
Not being familiar with how exactly lightmaps are generated in Torque, I would imagine that it would be quite a complex change. However, at its heart it should only require the use of a set of vertex normals per surface (each one being created from averaging the adjacent faces which are within a certain angle tolerance value), and then the lightmap for that face would be generated from these interpolated light values at each UV, instead of a single harsh color that is merely set for the entire face. These normals could be set to be calculated from only faces on the actual brush, or it could go through any neighboring brushes and look for adjacent faces so that things like inclined sections of ground made up of multiple brushes would have a much more natural lighting appeal to them as well.
Any takers?
#2
Smoothing groups only work on DTSs as their vertex normals are calculated in the exporter (but that would actually be up to the individual exporters), and are then only used for dynamic lighting or burnt in vertex colors as DTSs are not lightmapped.
DIF Brushes (which are lightmapped) do not have their normals calculated in building tools (ie. MAX, Quark, etc.) as .MAP files do not store normals. Their normals are only calculated in Map2Dif (they are only face normals based on each plane of the brush), and therefore smoothing-type information is lost. The point is moot regardless as the lightmapping code (as far as I can see anyways...) only uses a single face normal when generating the lightmap color for each face, instead of caring about the shared vertex normals (which you need for smooth lighting).
03/05/2007 (8:32 am)
Thanks for the reply Stefan, but nope.Smoothing groups only work on DTSs as their vertex normals are calculated in the exporter (but that would actually be up to the individual exporters), and are then only used for dynamic lighting or burnt in vertex colors as DTSs are not lightmapped.
DIF Brushes (which are lightmapped) do not have their normals calculated in building tools (ie. MAX, Quark, etc.) as .MAP files do not store normals. Their normals are only calculated in Map2Dif (they are only face normals based on each plane of the brush), and therefore smoothing-type information is lost. The point is moot regardless as the lightmapping code (as far as I can see anyways...) only uses a single face normal when generating the lightmap color for each face, instead of caring about the shared vertex normals (which you need for smooth lighting).
#3
The fact that normals are not stored inside .MAP files does not say anything. With the same reasoning, older Map2Dif versions would not have leaks or have offset brushes, which they do and it is a well known limitation of the exporter. :) You can make the lighting seem smoother across edges by fiddling with the exporter (and it has been done). Whether it is called smoothing groups or not is another story, I just picked that word since it felt closest.
03/05/2007 (8:48 am)
The Constructor beta is under NDA so can not talk about it.The fact that normals are not stored inside .MAP files does not say anything. With the same reasoning, older Map2Dif versions would not have leaks or have offset brushes, which they do and it is a well known limitation of the exporter. :) You can make the lighting seem smoother across edges by fiddling with the exporter (and it has been done). Whether it is called smoothing groups or not is another story, I just picked that word since it felt closest.
#4
So it doesn't matter if the exporter is changed to include normals inside of the .MAP files, and consequently chaning Map2Dif to read in this data. Even if this change was made, the lightmapping code itself needs to be modified to do a different set of calculations based on gourard shading instead of flat shading, in which case, the "smoothed" vertex normals that you would need could merely be calculated at light-time (based on the surrounding face normals), and do not need to come through the entire tool-chain.
The objective of my post isn't to argue about if it can be done, or the best way to do it. I posted with the intention of asking if anyone else has managed to do this in the existing tool-chain of Torque (not including Constructor, as that most likely wont be out until my grandchildren are making games), and to see if they would like to share how it was done (if not provide the solution entirely!).
I don't want to "fiddle with the exporter" in order to "make the lighting seem smoother".
I *want* the lighting to *really be* smoother :)
03/05/2007 (9:17 am)
My point is that the lightmapping logic uses face normals, not vertex normals for calculating the actual lightmaps. This makes it impossible for there to be smooth lighting across non-coplanar faces via lightmaps. It just can't work without taking into account your neighbors.So it doesn't matter if the exporter is changed to include normals inside of the .MAP files, and consequently chaning Map2Dif to read in this data. Even if this change was made, the lightmapping code itself needs to be modified to do a different set of calculations based on gourard shading instead of flat shading, in which case, the "smoothed" vertex normals that you would need could merely be calculated at light-time (based on the surrounding face normals), and do not need to come through the entire tool-chain.
The objective of my post isn't to argue about if it can be done, or the best way to do it. I posted with the intention of asking if anyone else has managed to do this in the existing tool-chain of Torque (not including Constructor, as that most likely wont be out until my grandchildren are making games), and to see if they would like to share how it was done (if not provide the solution entirely!).
I don't want to "fiddle with the exporter" in order to "make the lighting seem smoother".
I *want* the lighting to *really be* smoother :)
#5
Good luck :)
03/05/2007 (11:05 am)
There was a plan a while ago where someone showed screenshots of a cave which had smoothed edges. That was with an updated map2dif, not sure if it is out yet. There was also another person who posted a terrain made in Constructor, with smooth groups.Good luck :)
#6
I'll look for that plan, but at the moment the only info on GG that I've found even remotely mentions this topic (which is strange, given that smooth lighting should be a right, not a privilege!) is one by John Kabus back in 2003 (before he did TLK I assume...) www.garagegames.com/mg/forums/result.thread.php?qt=11119, where he also asks the same question as me.
Snap! Did another search and found a reply from John in another thread that also asks the same question back in 2005 in the TLK forums www.garagegames.com/mg/forums/result.thread.php?qt=24676) where he mentions that TLK definitely does only do flat shading on surfaces, and his suggestion is to use static DTSes for smooth lighting... However, the problem with this solution is that they do not take on actual lightmap information (ie. shadows), as they only use burnt-in vertex coloring.
I guess John gave up on his dream of smoothed lightmaps when creating TLK ;)
03/05/2007 (11:18 pm)
Thanks Stefan :)I'll look for that plan, but at the moment the only info on GG that I've found even remotely mentions this topic (which is strange, given that smooth lighting should be a right, not a privilege!) is one by John Kabus back in 2003 (before he did TLK I assume...) www.garagegames.com/mg/forums/result.thread.php?qt=11119, where he also asks the same question as me.
Snap! Did another search and found a reply from John in another thread that also asks the same question back in 2005 in the TLK forums www.garagegames.com/mg/forums/result.thread.php?qt=24676) where he mentions that TLK definitely does only do flat shading on surfaces, and his suggestion is to use static DTSes for smooth lighting... However, the problem with this solution is that they do not take on actual lightmap information (ie. shadows), as they only use burnt-in vertex coloring.
I guess John gave up on his dream of smoothed lightmaps when creating TLK ;)
#7
The solution was to create a new interior editor, Constructor, which supports extended features that are not map friendly like normal smoothing and static meshes.
Synapse Gaming also developed Constructor's lighting system, so compatibility between it and Torque is extremely high - it's almost like building directly in the engine. Constructor provides in-editor lighting (an as-you-work preview), which shows exactly how the interior looks in the engine, smooth shading and all.
03/06/2007 (4:06 pm)
Nope, I didn't give up. The problem always comes down to the tool chain - your interior creation tool needs to support normal smoothing and provide those normals to map2dif (which none of them do).The solution was to create a new interior editor, Constructor, which supports extended features that are not map friendly like normal smoothing and static meshes.
Synapse Gaming also developed Constructor's lighting system, so compatibility between it and Torque is extremely high - it's almost like building directly in the engine. Constructor provides in-editor lighting (an as-you-work preview), which shows exactly how the interior looks in the engine, smooth shading and all.
#8
That would be the easy part as far as I am concerned. The difficult part (although, it shouldn't be too bad) would be to modify the actual lighting system to take in X normals per lightmapped face, instead of just a singular normal, and then do interpolated lightmap creation.
We're just in the middle of deadlines so I don't have the 3 or so days that it would probably take to do this kind of change. I guess I'll just have to reply to my own post here in a month's time with my own answer... :)
03/06/2007 (11:39 pm)
You wouldn't necessarily need the tool to supply smoothing/normals to map2dif. You could quite easily have a "poor man's" version in which you calculate your own smoothed vertex normals by specifying a tolerance for planar angles either on a per-brush basis, or a per DIF basis (much easier changes to do for map2dif).That would be the easy part as far as I am concerned. The difficult part (although, it shouldn't be too bad) would be to modify the actual lighting system to take in X normals per lightmapped face, instead of just a singular normal, and then do interpolated lightmap creation.
We're just in the middle of deadlines so I don't have the 3 or so days that it would probably take to do this kind of change. I guess I'll just have to reply to my own post here in a month's time with my own answer... :)
Torque Owner Stefan Lundmark