[Gtkradiant] [1.5] obj/mtl support, SnapPlane bug (causing collision brushes to disappear)

[Rudolf Polzer]

Hi,

I made two patches against GtkRadiant/q3map2:


Completed the support for .obj format in PicoModel:
http://emptyset.endoftheinternet.org/~polzer/nexuiz/objsupport-q3map2.diff

It takes the material name as shader name, so you may want to use _remap
for it, or edit the material names by hand. I could not reproduce the
crashes regarding mtl files described in the comment, though.


Fix against SnapPlane bug which caused collision brushes to disappear
sometimes:
http://emptyset.endoftheinternet.org/~polzer/nexuiz/q3map2-modelfix.diff

This actually does multiple things:
- SnapPlane gets an added "center" argument. It makes sure that the
  distance between the plane and the given center stays the same - in
  other words, the "dist" of the plane is adjusted so that the plane is
  rotated around center when snapping the normal. That way, the plane
  gets changed by much less when normal snapping when it's far away from
  the origin. This fixes the big model clipping bug.
- The code that looks for the right coordinate axis to extrude by in the
  model code gets fixed. It did a comparison to find the largest of
  three numbers, but didn't account for the case that there may be TWO
  biggest ones (it chose none then). This could cause some triangles
  which are exactly symmetric to a 45 degrees plane to disappear.
- misc_model gets added spawnflags when autoclipping:
   0: for triangle extrusion, the axial direction that's closest to the
      triangle normal is used (general purpose, makes sure you can stand
      on a spike - but can sometimes behave badly near the 45 degrees
      angle)
   8: for triangle extrusion, the original normals are used (general
      purpoose, but may cause spikes where you slowly glide down)
  16: for triangle extrusion, ALWAYS use the up or down direction (ideal
      for terrain, so the extruded "plates" fit together exactly)
  24: extrude by zero length (idea by LordHavoc, but may require engine
      changes)
  I also tried to make pyramid building as an alternative work... but I
  #if 0-ed out the code becase the pyramids' planes got snapped to
  death.
  A future idea: How bad would it be to not snap planes from imported
  autoclipped models AT ALL?

Also, I'd propose changing normalEpsilon. The current value of 0.00001
allows 0.99999 get snapped to 1.0. This may sound like almost nothing -
but it actually is equivalent to tilting a plane by up to 0.256 degrees
(arccos 0.99999). I'd add two more zeroes to normalEpsilon, then it
corresponds to a snap angle of 0.027 degrees.

Maybe it would be better to compare the "small" values to normalEpsilon
when checking if the normal can be snapped to an axial one - it would
then allow a much smaller angle though, so maybe THEN normalEpsilon
should get raised to 0.001, which corresponds to 0.057 degrees.

One thing I don't understand though - why does plane snapping cause
holes (previously even really large ones) in models at all? Shouldn't
front and back plane of the prism get snapped the same way, so that
plane snapping can only cause holes when it changes one of the side
planes? To me it looks like front and back plane do not get the same
"chances" to get snapped... for whatever reason. But with my patch
against the SnapPlane bug, I couldn't even get a grenade sized hole with
the default normalEpsilon.

All the best

Rudolf