Map2Dif Errors and solutions
by FruitBatInShades · in Artist Corner · 11/23/2004 (2:18 am) · 23 replies
Please use this thread to ask any questions or provide feedback. I want to keep the main thread as a clean resource/tutorial.
This is an old thread I am moving to the art forums. This is just a place for me to share problems and solutions I have found with quark and map2dif, I hope you find a solution to your problem here :o)
StairMaker
Using the new stairmaker in Quark 6.4 produces stairs that generate winding errors. Go to the stairmaker and select 'Old style' and this seems to solve this problem.
Winding Errors
Bad Winding errors are quite common and seem to be related to the scale of textures on small faces. When doing things like furniture I seem to get this error quite often.
I originally thought it was down to the small faces. To keep the textures even I usually put the base texture on 1 face and wrap texture. It seems that this can cause problems and rectifies itself if you scale the texture to face but this means the textures are not to scale on all faces :(
It seems that when a face is intersected by too many other brushes you get winding errors. Check that not too many brushes touch others in a detailed map, such as lots of beams or railway tracks.
This error is also generated when you have triangular brushes touching each other (try the stairmaker in 6.4 to see and example). Thin areas of polys are fine on their own, but put a few together (Glue) and map2dif gets confused.
Always use the detail entity for any objects that do not need to cause surfaces to divide, these are things such as decorative objects (tables, chairs etc.) and structural items that do not need to create a new poly (i.e wodden beams on a cieling, a bar, a fireplace).
The dreaded coplanar node error!
This would seem to be a rounding error, if you turn floating point off, it dissapears. Most of these errors I have resolved by looking for overlapping faces. These don't often appear in the editor as they are usually 0.00001 of a float. Try glueing and tagging the faces in the affected area. This seems to resolve about 50%, when I solve the other 50% I'll let you know :)
I've just solved a load of coplanar errors, but this is a fudging technique and doesn't help you stop them in the first place :( It seems that this error is generated for another reason. Where my maps have been failing and I could not find overlapping faces, I tracked down the faulty brush by old fashioned hard work.
This error seems to get generated when a series of brushes with differing angles meet. I will provide details in the tutorial but for know find the offending brush and reduce the angles it covers.
This is hard to explain but when a brush thats does not have 90 degree angles, meets a series of other brushes, that do not have 90 degree (How do I do that degree circle?) angles, map2dif seems to get confused. I have had to cut the offending brushes so they are simpler and do have 90 angles.
This is an old thread I am moving to the art forums. This is just a place for me to share problems and solutions I have found with quark and map2dif, I hope you find a solution to your problem here :o)
StairMaker
Using the new stairmaker in Quark 6.4 produces stairs that generate winding errors. Go to the stairmaker and select 'Old style' and this seems to solve this problem.
Winding Errors
Bad Winding errors are quite common and seem to be related to the scale of textures on small faces. When doing things like furniture I seem to get this error quite often.
I originally thought it was down to the small faces. To keep the textures even I usually put the base texture on 1 face and wrap texture. It seems that this can cause problems and rectifies itself if you scale the texture to face but this means the textures are not to scale on all faces :(
It seems that when a face is intersected by too many other brushes you get winding errors. Check that not too many brushes touch others in a detailed map, such as lots of beams or railway tracks.
This error is also generated when you have triangular brushes touching each other (try the stairmaker in 6.4 to see and example). Thin areas of polys are fine on their own, but put a few together (Glue) and map2dif gets confused.
Always use the detail entity for any objects that do not need to cause surfaces to divide, these are things such as decorative objects (tables, chairs etc.) and structural items that do not need to create a new poly (i.e wodden beams on a cieling, a bar, a fireplace).
The dreaded coplanar node error!
This would seem to be a rounding error, if you turn floating point off, it dissapears. Most of these errors I have resolved by looking for overlapping faces. These don't often appear in the editor as they are usually 0.00001 of a float. Try glueing and tagging the faces in the affected area. This seems to resolve about 50%, when I solve the other 50% I'll let you know :)
I've just solved a load of coplanar errors, but this is a fudging technique and doesn't help you stop them in the first place :( It seems that this error is generated for another reason. Where my maps have been failing and I could not find overlapping faces, I tracked down the faulty brush by old fashioned hard work.
This error seems to get generated when a series of brushes with differing angles meet. I will provide details in the tutorial but for know find the offending brush and reduce the angles it covers.
This is hard to explain but when a brush thats does not have 90 degree angles, meets a series of other brushes, that do not have 90 degree (How do I do that degree circle?) angles, map2dif seems to get confused. I have had to cut the offending brushes so they are simpler and do have 90
#2
11/23/2004 (2:21 am)
Did you notice that GG posted your findings recently in the resources section? :)
#3
11/24/2004 (8:43 am)
Yes, sorry to not mention before, I did convert a number of these to Resources in the QuArK FAQ section.
#4
I have now had thousands of errors and figuired out what causes most of them. The general problem seems to be when too many brushes join in a small space. I think Map2Dif gets confused. Simple right angle junctions should not cause an error but they do when you have junctions on different levels, where a floor meets the corner of a wall for example.
The illustration below shows the type of junctions that throw D.Moore and coplanar errors. You're more likely to get a coplanar error if the brush is crossing one of these joints.
Before anybody starts going, nah, nah, nah. Sometimes these junctions do work, its when you've got too many in an (as yet) undefined volume.
The other common one when you a portal reference from D.Moore is that you have a brush that sits right next to a portal. Move brushes away one by one from the portal and see which one is causing the error.
11/24/2004 (8:49 am)
Where is D.Moore and can I smack him?I have now had thousands of errors and figuired out what causes most of them. The general problem seems to be when too many brushes join in a small space. I think Map2Dif gets confused. Simple right angle junctions should not cause an error but they do when you have junctions on different levels, where a floor meets the corner of a wall for example.
The illustration below shows the type of junctions that throw D.Moore and coplanar errors. You're more likely to get a coplanar error if the brush is crossing one of these joints.
Before anybody starts going, nah, nah, nah. Sometimes these junctions do work, its when you've got too many in an (as yet) undefined volume.
The other common one when you a portal reference from D.Moore is that you have a brush that sits right next to a portal. Move brushes away one by one from the portal and see which one is causing the error.
#5
Brush subtraction is pretty good but it does seem to suffer from the occasional rounding error. If you're doing a brush subtraction across a brush that is used to seal the interior (external wall etc) then compile and check before saving and moving on.
If you do a lot of subtractions and find you now have a light leak, it may be impossible to fix. Some leaks are impossible to fix as the figuires look correct in the map file, but seem to get rounded out after map2dif (yes with floating point). Spend the extra time testing any cuts in the external brushes, it will save you time in the long run.
11/24/2004 (9:11 am)
Quark and brush subtractionBrush subtraction is pretty good but it does seem to suffer from the occasional rounding error. If you're doing a brush subtraction across a brush that is used to seal the interior (external wall etc) then compile and check before saving and moving on.
If you do a lot of subtractions and find you now have a light leak, it may be impossible to fix. Some leaks are impossible to fix as the figuires look correct in the map file, but seem to get rounded out after map2dif (yes with floating point). Spend the extra time testing any cuts in the external brushes, it will save you time in the long run.
#6
Oh and, Dmoore is long gone :P
He worked at Dynamix while he was still learning C++ and that's probably also why it's so.. uh, well yeah.. He's the creator of many stupid error messages! :)
Aaand my favourite
11/24/2004 (11:48 am)
Hehe, really nice thread! Very informative. Keep up the good work.Oh and, Dmoore is long gone :P
He worked at Dynamix while he was still learning C++ and that's probably also why it's so.. uh, well yeah.. He's the creator of many stupid error messages! :)
Quote:
Error, bad assumption (2, not 1) Go smack Dmoore (portal 0)
Aaand my favourite
Quote:
This should never happen. Go talk to Dmoore.
#7
I think I have finally solved this one, let hope I can explain.
A portal must overlap the opening by a few units.
The front face (the one you look at from outside) must not be parallel/glued to/in line with the brushes of the opening. In a simple object this will work. If you have a more complicated object that has other bursh faces that are parallel to the portal, you may get this error.
The solution is simple, just set the portal back a few units from the outside face of the opening brushes. So the face that you look through from either side of the protal should be set back a few units so that those faces are not parallel.
That probably makes no sense, Here are some diagrams.
11/24/2004 (12:17 pm)
Portals and planes (D.Moore)I think I have finally solved this one, let hope I can explain.
A portal must overlap the opening by a few units.
The front face (the one you look at from outside) must not be parallel/glued to/in line with the brushes of the opening. In a simple object this will work. If you have a more complicated object that has other bursh faces that are parallel to the portal, you may get this error.
The solution is simple, just set the portal back a few units from the outside face of the opening brushes. So the face that you look through from either side of the protal should be set back a few units so that those faces are not parallel.
That probably makes no sense, Here are some diagrams.
#8
Portal brushes must be completely embedded on all sides by normal solid brushes. Portal brushes should not align exactly on the face of another solid world brush. Portal brushes do not recognize detail brushes as solid brushes, you cannot anchor a portal brush in a detail brush.
The largest face of the portal brush will be used to determine where the portal starts or stops or it will randomly pick one face of the brush if there are two equal sized faces. This is why you will flatten your portal brushes to control where the portal zone begins and ends.
You can use as many portal brushes as necessary for your shape. If a portal zone brush is not useful The Torque engine will automatically perform back face culling to reduce the number of drawn polygons. This means any polygon face that is facing away from your viewpoint and cannot be seen will not be rendered.
edited from: The Worldcraft manual Thanks Dirkk
11/25/2004 (3:07 am)
More on PortalsPortal brushes must be completely embedded on all sides by normal solid brushes. Portal brushes should not align exactly on the face of another solid world brush. Portal brushes do not recognize detail brushes as solid brushes, you cannot anchor a portal brush in a detail brush.
The largest face of the portal brush will be used to determine where the portal starts or stops or it will randomly pick one face of the brush if there are two equal sized faces. This is why you will flatten your portal brushes to control where the portal zone begins and ends.
You can use as many portal brushes as necessary for your shape. If a portal zone brush is not useful The Torque engine will automatically perform back face culling to reduce the number of drawn polygons. This means any polygon face that is facing away from your viewpoint and cannot be seen will not be rendered.
edited from: The Worldcraft manual Thanks Dirkk
#9
Grrr, arggh. I've just spent 6 hours looking for a leak in a 2 day map. I am not a happy bat, but still I shall share as usual.
There is an old bit of advice that may be of use to you. When you have a leak:-
1. go into the mission editor
2. Open the sun object
3. Click the misc button
4. Set the ambient to "0.3 0.3 0.3 1"
5. Set the color to "0 1 0 1"
Watch as your world become a grimy night-vision version of its former self. Now you can look around the building and see the bright green leaks. If you've left a hole you should be able to see it.
If you haven't left a gaping hole and light seems to be seeping in through edges of walls or floors, FORGET THIS TECHNIQUE. IT WILL DRIVE YOU MAD!
Why? because if there isn't a strong glowing green blob, chances are the actual fault lies nowhere near the apparent points of entry (glowing bits). It damn annoying that a leak on one side of the map will make leaks apparently appear everywhere!
1. Go back and thoroughly check that all your portals are tightly sealed
2. Check that some daft idiot hasn't attached the portal to a detail brush (who, me!)
3. Find a nice big bear and drop a melon on its head from your fruit tree :o) The pain when he attacks will make the last 6 hours a distant memory.
11/25/2004 (1:23 pm)
F*@#in Light LeaksGrrr, arggh. I've just spent 6 hours looking for a leak in a 2 day map. I am not a happy bat, but still I shall share as usual.
There is an old bit of advice that may be of use to you. When you have a leak:-
1. go into the mission editor
2. Open the sun object
3. Click the misc button
4. Set the ambient to "0.3 0.3 0.3 1"
5. Set the color to "0 1 0 1"
Watch as your world become a grimy night-vision version of its former self. Now you can look around the building and see the bright green leaks. If you've left a hole you should be able to see it.
If you haven't left a gaping hole and light seems to be seeping in through edges of walls or floors, FORGET THIS TECHNIQUE. IT WILL DRIVE YOU MAD!
Why? because if there isn't a strong glowing green blob, chances are the actual fault lies nowhere near the apparent points of entry (glowing bits). It damn annoying that a leak on one side of the map will make leaks apparently appear everywhere!
1. Go back and thoroughly check that all your portals are tightly sealed
2. Check that some daft idiot hasn't attached the portal to a detail brush (who, me!)
3. Find a nice big bear and drop a melon on its head from your fruit tree :o) The pain when he attacks will make the last 6 hours a distant memory.
#10
This one was me being stupid but I thought I'd share it anyway. I thought I had a problem because when I was inside my interior, nothing was rendered on a particular floor. I scratched my head and asked for help and the obvious was pointed out!
"If there is no opening for light to get into the interior, torque will not render it."
So if you've got your portals in place and you find the same thing as in the image below, all is well. The room is properly sealed.
If you get textures that do not render properly or only show up when you get close, it is probably that the textures are not in powers of 2 (16, 32, 64, 128, 256, 512, 1024). Textures sizes must be powers of 2, so 32x64 is ok, but 32x63 will give the problem below.
11/27/2004 (3:17 pm)
Rendering problemsThis one was me being stupid but I thought I'd share it anyway. I thought I had a problem because when I was inside my interior, nothing was rendered on a particular floor. I scratched my head and asked for help and the obvious was pointed out!
"If there is no opening for light to get into the interior, torque will not render it."
So if you've got your portals in place and you find the same thing as in the image below, all is well. The room is properly sealed.
If you get textures that do not render properly or only show up when you get close, it is probably that the textures are not in powers of 2 (16, 32, 64, 128, 256, 512, 1024). Textures sizes must be powers of 2, so 32x64 is ok, but 32x63 will give the problem below.
#11
If a model seems to use the really low MIP mapping textures but Map2Dif throws no errors at all you may have a zone problem. Not sure how to fix it but I know what causes it! Close off any interior gaps one by one, compile and find the one that is confusing Map2Dif (not that that's hard). I don;t have a solution, just leave that gap closed and add another one elsewhere, Sorry!
The only way to really identify this problem is that when you close that gap, the surface count goes down by a larger number than it should.
11/30/2004 (3:32 am)
More zone and portal wierdnessIf a model seems to use the really low MIP mapping textures but Map2Dif throws no errors at all you may have a zone problem. Not sure how to fix it but I know what causes it! Close off any interior gaps one by one, compile and find the one that is confusing Map2Dif (not that that's hard). I don;t have a solution, just leave that gap closed and add another one elsewhere, Sorry!
The only way to really identify this problem is that when you close that gap, the surface count goes down by a larger number than it should.
#12
12/01/2004 (7:31 pm)
Dave Moore is an awesome programmer, and I would hire him again in a minute. Stefan's remarks were uncalled for. I don't mind people trying to solve problems, but constantly taking undeserved potshots at the people that helped create Torque will not win any points with the GG crew, nor will it help solve any problems. We can do without the editorial, satirical, and b.s. remarks. We are people too, please treat us as such.
#13
I have moaned my arse off about QuArK and Map2DIF. I have screamed, had temper tantrums and sulked. I have deleted huge models I thought were unsalvageable. As anyone who has been following my work knows, IT'S BEEN A NIGHTMARE!
I have studied hard, researched and tested many scenarios and ways of joining brushes, making rooms and details and had light leaks coming out of my ears.
I guess this advice will go unheeded, hell I had similar advice and didn't belive it either.
QuArK and Map2DIF are not as bad as you think they are! I have tracked down 90% of light leaks and they are usually my fault in the model!
Shock! Horror!
Whilst building the models i check constantly to ensure they do not leak. At some point they all start to leak, this is usually noticed at these points:-
1. You add a new portal
2. You add a new light
3. You edit an external brush
The thing is, when a leak happens, it affects THE WHOLE MODEL! Not because the lightmaps are crap (who said that!) but because once that first leak appears whilst editing, ALL the leaks show up together!
and what has caused 90% of my leaks? Brushes that overlap! These occur in complex models because its hard to see all the lines when a map gets complicated and brush subtraction can be dodgy. Its easy to drag a brush down through another one when your aligning it. Watch out for this.
IMHO - The other 10% are problems with the brush calculations as zones are calculated, but I have learned a few techniques that reduce the possibility of this happening. I will cover these later as its more a way of working than general advice.
The main problem with QuArK and Map2DIF is that there is no good inofrmation available. No comprehensive tutorials or explanations of how they work. I do intend to write a tutorial/manual when if I finish the pack.
12/02/2004 (4:05 am)
The FruitBat removes his shades and confessesI have moaned my arse off about QuArK and Map2DIF. I have screamed, had temper tantrums and sulked. I have deleted huge models I thought were unsalvageable. As anyone who has been following my work knows, IT'S BEEN A NIGHTMARE!
I have studied hard, researched and tested many scenarios and ways of joining brushes, making rooms and details and had light leaks coming out of my ears.
I guess this advice will go unheeded, hell I had similar advice and didn't belive it either.
QuArK and Map2DIF are not as bad as you think they are! I have tracked down 90% of light leaks and they are usually my fault in the model!
Shock! Horror!
Whilst building the models i check constantly to ensure they do not leak. At some point they all start to leak, this is usually noticed at these points:-
1. You add a new portal
2. You add a new light
3. You edit an external brush
The thing is, when a leak happens, it affects THE WHOLE MODEL! Not because the lightmaps are crap (who said that!) but because once that first leak appears whilst editing, ALL the leaks show up together!
and what has caused 90% of my leaks? Brushes that overlap! These occur in complex models because its hard to see all the lines when a map gets complicated and brush subtraction can be dodgy. Its easy to drag a brush down through another one when your aligning it. Watch out for this.
IMHO - The other 10% are problems with the brush calculations as zones are calculated, but I have learned a few techniques that reduce the possibility of this happening. I will cover these later as its more a way of working than general advice.
The main problem with QuArK and Map2DIF is that there is no good inofrmation available. No comprehensive tutorials or explanations of how they work. I do intend to write a tutorial/manual when if I finish the pack.
#14
12/02/2004 (10:41 pm)
Ok... stupid question: Why hasn't anyone changed the "smack dmoore" message to something that makes sense? It would take a few mintues and would save people alot of trouble.
#15
12/03/2004 (10:51 am)
Actually Tom, a rewrite of the Map2Dif parser is currently underway. It is a temporary solution, but it should eliminate many stupid headaches (such as the very cryptic error messages, and the Valve220 restrictions).
#16
12/03/2004 (11:17 am)
So this is a small step and not the milestone 5 work i assume is several months away? As long as an artist can read and grok the message that solves alot of time.
#17
12/06/2004 (10:50 am)
No, it is not the milestone 5 rewrite, which is likely to be TSE specific.
#18
12/06/2004 (11:56 am)
I have a question about portals for you fruitbat. Are portals supposed to eliminate any terrain that is inside the portaled area from being rendered? Because i am following your instructions for portal placement but i am still seeing terrain rendered in my underground structures.
#20
12/06/2004 (12:16 pm)
Apologies 
Torque Owner FruitBatInShades
Hiss, Spit, growl! I hate the lightmapping, its awful! It causes me constant headaches and should not do so, the geometry is fine, its the way map2dif does its light calculations that are at fault. :P
In the current version of map2dif (torque 1.3 head) you cannot allow light to enter a building. Its that simple, if you do you will get light anomolies. Do NOT turn the lightmap resolution up as sugessted in other threads, this just makes the DIF huge and basically just applies a blur filter to the faulty areas.
Light Leaks
1. Go and Tag/Glue every face. Laborious, but it will solve 50% of light leaks as they are usually a < 0.01 gap in the architecture somewhere.
2. Make a floor piece that the model sits on and fit it underneath. The lightmapping seems to get confused and let let in through the floor unless all exterior sections are at least 16 units thick (or the width of the lightmap scale). Make the floor piece about 32 units wider than the model and 32 units deep.
3. Unfortunately, you have to overlap brushes. You can do some nice modelling, but unless the brushes are flush and at least 16 units they will create a light leak.