[Gtkradiant] Reached milestone in q3map2 math precision fixes

[Timothee BESSET]

I think those defines should be enabled by default. I don't feel we
should expect our users to compile their own builds, and it's not like
trunk has a stable codebase for the editor that is intensively used in
production right now.

TTimo

On Mon, Jan 10, 2011 at 1:27 AM, Nerius Landys <nlandys at gmail.com> wrote:
> Hi guys, I've committed some code back to trunk pertaining to q3map2 fixes.
> See commit r416.  The changes are not dangerous at all because almost all of
> the code is inactive due to #defines in q3map2.h.  So you have have to turn
> the changes on yourself by setting these to 1 in q3map2.h:
>
> #define EXPERIMENTAL_HIGH_PRECISION_MATH_Q3MAP2_FIXES   1
> #define EXPERIMENTAL_SNAP_NORMAL_FIX                    1
> #define EXPERIMENTAL_SNAP_PLANE_FIX                     1
>
> Right now all 3 of these are set to 0 in SVN (disable).
>
> Here are some results from running regression tests that are in trunk:
>
> "r417 w/ defines" means you turn on
> EXPERIMENTAL_HIGH_PRECISION_MATH_Q3MAP2_FIXES, EXPERIMENTAL_SNAP_NORMAL_FIX,
> and EXPERIMENTAL_SNAP_PLANE_FIX in q3map2.h.
>
> regression test         | r417                    | r417 w/ defines
> ------------------------+-------------------------+------------------
> base_winding            | working                 | working
> coarse_snap_normal      | broken                  | working
> degenerate_winding      | working                 | working
> disappearing_sliver     | working                 | working
> disappearing_sliver2    | working                 | working
> disappearing_sliver3    | broken                  | working
> duplicate_plane         | working                 | working
> plane_aliasing          | working                 | working
> segmentation_fault      | working                 | working
> snap_plane              | broken                  | working
> sparkly_seam            | working                 | working
>
>
> Also, I was able to compile Icy Fantasy map (a very complex map with lots of
> thin triangles) without any disappearing triangles.  I used to have to use
> various tricks such as deleting brushes and replacing them with individual
> path mesh triangles.
>
>
>
> Bottom line: If you've had problems with disappearing terrain or triangles
> in your maps, give these changes a try.  I'd like to get some feedback.
>
> The majority of the improvements have to do with the brush winding
> calculations.
>
> Maybe if we feel confident enough that these changes don't break anything we
> can flip the #defines to "on" by default sometime in the future.
>
> If you have any other bugs in q3map2, I think we should get a regression
> test for it.  Since q3map2 code is somewhat heuristic, the only way to be
> confident that it works properly is to have regression tests.
>
> - Rambetter
>
>
> _______________________________________________
> Gtkradiant mailing list
> Gtkradiant at zerowing.idsoftware.com
> http://zerowing.idsoftware.com/cgi-bin/mailman/listinfo/gtkradiant
>