Quark errors /// To many points

#1 Matthew,
Thanks for sending the screencapture of the map2dif error window--that greatly helps figure out exactly what is causing a mapping problem:
holodeck.st.usm.edu/vrcomputing/vrc_t/tutorials/errors/img/errmsg_editgeom1295.j...
The reason I use the DEBUG version of map2dif (and included it with QuArK4Torque) is primarily to get these messages.

Ok, that said, the title bar indicated the failure to compile occurred at line 1295 in editGeometry.cc. Looking at that line, we have the error:

AssertFatal(finalNumPoints <= MaxWindingPoints, "Internal Error: too many points!");

And we also see its in the function: EditGeometry::fixTJuncs()

TJuncs are T-junctions where one plane intersects another forming a T; map2dif has to break up the intersected surface into two new surfaces. So, this is our first clue.

And, the value assigned to MaxWindingPoints is:

static const U32 MaxWindingPoints = 32;

This value was found by doing a search on MaxWindingPoints (it was set in morianBasics.cc).

The WindingPoints are simply the number of edges on any given plane, with the max value being set to 32 in this compiler. So now we know what we're looking for: a plane that is being broken up into too many faces causing one or more of the new surfaces to exceed the number of winding points.

And after looking at your map file, it was immediately apparent that the railroad tie brushes were intersecting both the rail brushes and platform brushes too many times. holodeck.st.usm.edu/vrcomputing/vrc_t/tutorials/errors/img/errmsg_editgeom1295ex...

There are two solutions:
1) lower the top of the platform 1 unit and raise the bottom side of the rails 1 unit so none of the brushes actually touch. It shouldn't normally be visible.
2) break the rail brushes and platform brushes into smaller sections (try 2 or 3). QuArK is real good at extending textures across multiple brushes. You can also use the tag face option and wrap the textures to other brushes so there is no visible seam.

So, you're the artist--you decide :)

But while we're on this example let me point out a couple other problems.

1) The rrtracksand tie folder in the qkm file (QuArK's map format for those that don't know) you sent has a detail entity with a group folder containing 5 platform brushes. Move the brushes out of the group folder up a level directly under the detail entity. If you want, group the detail entities into folders (don't rename the entity itself because this would rename the class it belongs to and map2dif would get real lost).

2) The platform top brush surface was off grid. Map2dif can handle this by rounding off the brush vertex coordinates but this can lead to undesirable/unpredictable results. A problem in the current version of QuArK4Torque has been potential vertex drift when dragging faces of brushes; although non-integer coordinates can also occur when rotating brushes, inclining surfaces, creating complex polyhedrons, etc.

In any case, I would recommend getting the latest release (release candidate 2 of the upcoming 6.3 release. This fixes the vertex problem completely; you can get the official version at:
dynamic.gamespy.com/~quark/
This URL is also where you can get updated QuArK add-ons for Torque as changes are made: new entities, better compile menus, new commands, etc.

At some point down the road, after the dust settles a bit on the 6.3 release I will create a new QuArK4Torque bundle that will include a new map2dif (with BadGuy's door stuff included; hopefully Melv or someone will have solved the mirror/translucency issues; etc).

3) And finally, (and this may have been intentional), judging from the scale you are using for the tracks (look at Test Guy in the image above), I wanted to ask if you know what units you're working with? Basically, 1 QuArK unit is 1 inch; Test Guy stands 6 feet 2 inches.

Well, I hope this has been helpful. Happy mapping!

P.S. I've been collecting these error messages as I come across them; I would appreciate any mappers sending me their error experiences/solutions so I can compile them into an error FAQ that would benefit us all. It could also lead to an improved messaging system from map2dif

#2 Gotcha. Had to read it over a few times but now I see what your saying.
I will get the 6.3. I am already using the a version of map2dif that includes the door functions by Badguy.

I was under the impresion that the as long as my railroad ties where "details" they would effect the bottom surface.

About the error list. Trust me if they can be made I will find them and forward them to you.

Thanks for the help
Matt

#3 Well, the detail brushes should not act that way as you say, but having the brushes in groups under the detail entity messes up map2dif. That might be nice addition to map2dif (search subdirs within the detail entity class).

And since the platform was off grid, it actually intersected the ties. I haven't tested this but perhaps even though specified as detail, intersecting details might still have to be "chopped" up by map2dif since all faces of details are rendered.

Which brings up another point: using details to solve rendering problems is not always the best solution because you're rendering all faces which adds to the poly count and lowers fps.