...
by Redacted · in Torque Game Engine · 06/03/2004 (11:53 pm) · 20 replies
...
#5
Thw windingbrush is a badface brush or a bad bsp brush.
I get this if i messup a roofbrush and drag one of the top edges somewhere.
Im no expert on this but i get that error then .
06/04/2004 (5:02 am)
Hi JosephThw windingbrush is a badface brush or a bad bsp brush.
I get this if i messup a roofbrush and drag one of the top edges somewhere.
Im no expert on this but i get that error then .
#7
Ofcourse you can drag indiviuals.
Im not expert on convex things i only tell you how i fix my problems :)
Its not happens always for me ,but sometimes i make mistakes.
And if i delete the brush and make a new one it works.
I try to tell you my story when i get that winding error.
I dont have a perfect solution .
06/04/2004 (1:33 pm)
HEHEOfcourse you can drag indiviuals.
Im not expert on convex things i only tell you how i fix my problems :)
Its not happens always for me ,but sometimes i make mistakes.
And if i delete the brush and make a new one it works.
I try to tell you my story when i get that winding error.
I dont have a perfect solution .
#8
What that typically means is that a very narrow brush plane has been deleted. This is most likely due to round-off of floating point (yes, there are still problems with floating point coords). What this means is that a pair of vertices have been joined creating an invalid face (each face must have at least 3 vertices). The second message is simply a variation of the problem where the invalid face cannot be located in the BSP tree.
Although the floating point coordinates you have appear to be fine, I think the problem comes in when map2dif slices and dices as it breaks up each surface into its smaller pieces....at that point in time is when I think the errors are being introduced.
Ok, a solution....not the best one or one you want to hear:
--locate the offending brush and change the geometry
--move vertices to integer coordinates
--make sure brushes only intersect other brushes at edges (not in the middle of a face unless they are detail)
--all the above??
What Billy is referring about deleting and readding does sometimes fix the problem...I think because of the order in which map2dif slices and dices would be changed. Hope this helps.
And, since your map appears to be rather small, I could probably locate the problem brush in a hurry and/or give some ideas about fixing it if you want to eamil it to me.
06/04/2004 (1:59 pm)
Joseph,What that typically means is that a very narrow brush plane has been deleted. This is most likely due to round-off of floating point (yes, there are still problems with floating point coords). What this means is that a pair of vertices have been joined creating an invalid face (each face must have at least 3 vertices). The second message is simply a variation of the problem where the invalid face cannot be located in the BSP tree.
Although the floating point coordinates you have appear to be fine, I think the problem comes in when map2dif slices and dices as it breaks up each surface into its smaller pieces....at that point in time is when I think the errors are being introduced.
Ok, a solution....not the best one or one you want to hear:
--locate the offending brush and change the geometry
--move vertices to integer coordinates
--make sure brushes only intersect other brushes at edges (not in the middle of a face unless they are detail)
--all the above??
What Billy is referring about deleting and readding does sometimes fix the problem...I think because of the order in which map2dif slices and dices would be changed. Hope this helps.
And, since your map appears to be rather small, I could probably locate the problem brush in a hurry and/or give some ideas about fixing it if you want to eamil it to me.
#10
07/22/2004 (7:40 pm)
I've been having a similar problem with this that just doesn't seem to want to go away. I traced everything back to a couple of brushes and deleted them and re-added them by duplicating some other brushed. Now I noticed that when I did this the textures became mis-aligned naturally. So (in quark) I did the tag face and project from tagged and that fixed the misalignment. Now I say all this because after the duplication the map compiled fine, but when I changed the texture alignment it gave me that basewinding < 3 points error. I double checked and sure enough by changing the texture the error would occur...leaving it alone it was fine. I have noticed this a couple times where changing alignment on textures throws that error. Not sure why.
#11
07/23/2004 (12:23 am)
So after reading through some more forum threads I discovered that my problem could possibly relate the dreaded floating point problem which has been resolved so I hear. Anywho the map2dif I'm using is off of a recent HEAD, but when I compile anything with FP on it gives me a vislink error. I turn it off and it's fine. I also tried the marbleblast map2dif as it was said that version does work with FP, but the same problem.
#13
07/23/2004 (9:32 am)
If you use the rotate buttons, rather than dragging the rotate handles, you'll get much less screwed up results, in my experience.
#15
I'm still fuzzy on a lot of Torque, but all other vertex comparisons throughout map2dif (editGeometry.cc being most prevalent) treat points as U32. Is this where the information is getting lost? Could a clean up of map2dif resolve this problem?
07/23/2004 (4:37 pm)
Snooping around in morianUtil.cc, in the function createBoundedWinding, all of the relevant variables are Point3D (each coordinate being an F64) or F64. Where's the rounding? I haven't seen a number in a .MAP file that should bork this.... or am I thinking about this all wrong?I'm still fuzzy on a lot of Torque, but all other vertex comparisons throughout map2dif (editGeometry.cc being most prevalent) treat points as U32. Is this where the information is getting lost? Could a clean up of map2dif resolve this problem?
#17
07/23/2004 (7:23 pm)
So I'm not the orginal poster of this message, but I seriously think map2dif hates me. I cannot seem to get floating point untits to work. Well I can on the default torque starter map, but not on my others. What would I be looking for when looking at the .map file to find a problem? 
#18
The F64's are there basicly to store the results on the plane clippings. The selfClip() code is a good start (I use it myself in some other code) but it doesn't handle degenerate cases at all (it assumes you have a perfect closed convex volume). AS part of the rewrite I will be fixing this issue. I also have code in place to help map2dif to handle invalid/malformed brushes more gracefully and with far more useful error reporting.
Best advice I can give you with map2dif is that, if you are having problems with your geometry, it is time to rethink your geometry. I have seen some truly amazing and creative things come from artists working around "bad" geometry.
Mark,
It's not personal....map2dif hates everyone =)
07/23/2004 (9:59 pm)
Bryce,The F64's are there basicly to store the results on the plane clippings. The selfClip() code is a good start (I use it myself in some other code) but it doesn't handle degenerate cases at all (it assumes you have a perfect closed convex volume). AS part of the rewrite I will be fixing this issue. I also have code in place to help map2dif to handle invalid/malformed brushes more gracefully and with far more useful error reporting.
Best advice I can give you with map2dif is that, if you are having problems with your geometry, it is time to rethink your geometry. I have seen some truly amazing and creative things come from artists working around "bad" geometry.
Mark,
It's not personal....map2dif hates everyone =)
#19
07/24/2004 (3:23 am)
Reordering the brushes will oftentimes fix these errors as well. If you know the brush causing the error, simply move it to up the tree to be the first. Sometimes a different brush will now cause errors, but sometimes you'll get lucky and everything will work fine.
#20
I'm looking forward to your Map2Dif. It's needed a good rewrite for a long time. Degenerate cases would be VERY nice. ;)
To sum up here's a few tips from the general frustrations w/ Map2Dif:
* Make your interiors neat and tidy. Snap to grid is your friend.
* Don't try to make your detailing too small or with too many verticies close together.
* Just because it looks OK to you doesn't mean that it's good geometetry for Map2Dif.
* If you hit a snag where it compiled OK before, delete your recently created brushes one at a time and recompile after each deletion to locate the troublesome brush.
* As Erik said in the previous post, something in Map2Dif doesn't clean up properly. If your brushes have "odd" geometry, putting them in the beginning of the .MAP file sometimes helps.
07/25/2004 (10:13 am)
@Matt: It was really a half educated stab in the dark since someone had mentioned rounding, I was wondering if some resolution wasn't lost somewhere in the casting. Not that Torque hasn't been known for that. To sum up here's a few tips from the general frustrations w/ Map2Dif:
* Make your interiors neat and tidy. Snap to grid is your friend.
* Don't try to make your detailing too small or with too many verticies close together.
* Just because it looks OK to you doesn't mean that it's good geometetry for Map2Dif.
* If you hit a snag where it compiled OK before, delete your recently created brushes one at a time and recompile after each deletion to locate the troublesome brush.
* As Erik said in the previous post, something in Map2Dif doesn't clean up properly. If your brushes have "odd" geometry, putting them in the beginning of the .MAP file sometimes helps.
Torque Owner Redacted