obj/mtl support, SnapPlane bug (causing collision brushes to disappear)

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/~po
lzer/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


_______________________________________________
Gtkradiant mailing list
Gtkradiantzerowing.idsoftware.com
http://zerowing.idsoftware.com/cgi-bin/mailman
/listinfo/gtkradiant

Hi.

Thanks for the patches! I'll commit the obj-patch as soon as
I had the chance 
to do a some tests with it. Can you send me a sample-map
that uses an 
obj-model with material? I have no such maps.

Your second patch will not go into the trunk directly, I'm
afraid.
We had problems with untested q3map2-patches before.
I will put your patch into a subdirectory called
"optional_patches". Users who 
wish to give it a try can apply it without much extrawork.

I'm afraid I can't help you much with your questions about
the epsilons and 
plane snapping. I never worked with the q3map2 source or
q3map2 in general,
so I'm not qualified to judge what a specific value should
be.
I doubt that there will be a one-size-fits-all solution.
q3map2 is used in 
many projects with different requirements. Changing a
"trivial" thing for 
project A could break the maps of project B, etc.
However, If you find a solution that works for you, please
keep sending the 
patches so that I can add them to the repository. Hopefully
they help someone 
else too ;)

Namespace


Am Montag, 17. Dezember 2007 schrieb 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/~po
lzer/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
>
>
> _______________________________________________
> Gtkradiant mailing list
> Gtkradiantzerowing.idsoftware.com
> http://zerowing.idsoftware.com/cgi-bin/mailman
/listinfo/gtkradiant



-- 
www.codecreator.net | GPG: 0xD4DB516D

_______________________________________________
Gtkradiant mailing list
Gtkradiantzerowing.idsoftware.com
http://zerowing.idsoftware.com/cgi-bin/mailman
/listinfo/gtkradiant

On Mon, Dec 17, 2007 at 07:01:21PM +0100, namespace wrote:
> Hi.
> 
> Thanks for the patches! I'll commit the obj-patch as
soon as I had the chance 
> to do a some tests with it. Can you send me a
sample-map that uses an 
> obj-model with material? I have no such maps.

http://emptyset.endofthein
ternet.org/~polzer/nexuiz/maps/unofficial/subseatrack_r3.pk3

(.map and .obj included). Note that the map does NOT make
use of
q3map2's autoclipping, but uses a Blender exported .map, as
I made that
before making the patch against the SnapPlane problem. It
may be a good
idea to try deleting all worldspawn brushes except the
skybox ones, and
setting the model's spawnflags to 6 to test my patch.

It's a conversion of a track from supertuxkart, the obj was
written by
opening the .ac file from STK in Blender and saving as
.obj.

> Your second patch will not go into the trunk directly,
I'm afraid.
> We had problems with untested q3map2-patches before.
> I will put your patch into a subdirectory called
"optional_patches". Users who 
> wish to give it a try can apply it without much
extrawork.

I understand, but I just fear that the patch will then never
get the
required testing, thus be stuck in that directory forever,
and my work
would be for nothing.

Nobody would ever try the patch, as there will be no
pre-built binaries
with it. I have no idea how to make Windows binaries either
- as I have
neither Windows nor Visual Sudio 2005, and scons seems to
have no
support for cross compiling.

Best regards

Rudolf Polzer


_______________________________________________
Gtkradiant mailing list
Gtkradiantzerowing.idsoftware.com
http://zerowing.idsoftware.com/cgi-bin/mailman
/listinfo/gtkradiant

On Mon, Dec 17, 2007 at 10:52:06PM -0600, Timothee Besset
wrote:
> Well some of us can still have a good look through the
changes and roll
> binaries out. Just keep sending them 

One thing I am working on is making it finally possible to
cross compile
q3map2... I am so far that I have a working Makefile to
build q3map2 on
Linux natively (without scons).

However, it still needs libxml2, glib, libpng and libmhash -
and I
haven't had the time to cross compile THESE. Also, no idea
how the
libxml2-config script works when cross compiled... current
state is
http://emptyset.endoftheinternet.org/~pol
zer/nexuiz/Makefile-q3map2.txt,
but it even still contains unneeded files (e.g.
libs/mathlib/line.o is
not used by anything, which I noticed when trying the
Makefile in
ZeroRadiant and fixing it). Also, I wonder why I need three
different
sets of CFLAGS... I tried merging them, but then it failed
to build.
Probably because of different .h files of the same name.

BTW, not all files the q3map2 compile needs are contained in
ZeroRadiant
(like libjpeg), and apparently the install script of
ZeroRadiant doesn't
work yet. Also, scons doesn't build q3map2 yet...

Best regards

Rudolf Polzer


_______________________________________________
Gtkradiant mailing list
Gtkradiantzerowing.idsoftware.com
http://zerowing.idsoftware.com/cgi-bin/mailman
/listinfo/gtkradiant

On Tue, Dec 18, 2007 at 03:54:08PM -0800, Forest Hale
wrote:
> Timothee Besset wrote:
> > Yes, we still need to add q3map2 compile to the
scons build for 
> > ZeroRadiant. That should be pretty trivial with
the architecture already 
> > in place.
> 
> On IRC Rudolf was asking why ZeroRadiant doesn't use
autotools, I
> explained our previous conversation on the subject, but
he does have a
> point - Radiant is pretty much the only project using
scons, which
> makes it by definition weird/hard to compile/etc :P

Especially editing the scons files is hard for someone like
me who has
never used scons... OTOH, editing Makefiles is -
unfortunately - a very
common task, especially when cross compiling to OS X or
mingw32, I often
had to fix the mess autotools left behind (most common
lately: libtool
claiming that it can't do dynamic libraries, and building me
a .a
instead of the .dll I wanted - had to edit the libtool
script to be able
to make a libmodplug-0.dll).

Let's see when I get my q3map2 Makefile done so that it also
can cross
compile - might be a nice addition for GtkRadiant, so people
are able to
build q3map2 easier... and gcc's dependency output could be
used to find
all the files that are needed by q3map2, with the goal of
making a
q3map2-only distribution.

What is XML used for in q3map2? There is this XMLDump.xml
file - does
GtkRadiant use it? If not, I could try getting rid of the
libxml
dependency... glib can't be gotten rid of... and libmhash is
a very
unusual library (it's used by GtkRadiant only on my system,
which has
lots of packages installed), does q3map2 use it for any
cryptographic
purposes or would any other hash function do too? My final
goal would be
a q3map2-only distribution that's easy to compile and set
up, so you can
delegate map building to other computers easily, and so that
you can
just compile a new q3map2 to put it into an existing Radiant
without
much hassle. The purposes I see it using mhash for is to
build long
unique IDs... and to put a MD4 checksum into the AAS file.
Maybe I'll
take some freely licensed MD4 and MD5 routine and put them
in my
"standalone q3map2" project, should I ever get to
it.

> On a separate note, maybe Rudolf could make his changes
optional using
> a commandline option, which would ensure that any maps
relying on the
> old (buggy) behaviors can still use the old mode.
> 
> However from discussions on IRC it sounds like his
patch is a
> universal improvement.

Could do this, but it actually consists of three things:

- the additional normal generation methods: they use the
previous
  way when no special spawnflags are set (that is, just 6).
- the "find best normal" bug fix: very rarely
happens (only when a
  triangle is exactly symmetrical to a 45 degrees plane, and
has an
  angle of more than 45 degrees against the coordinate
plane
  perpendicular to the 45 degrees plane); even roundoff
errors make this
  bug not happen. I see no need to "optionalize"
this part of the fix,
  as the bug it fixes probably never happens due to roundoff
errors in
  the preceding calculations - I only noticed it when
reading the code.
- the snap planes fix - could easily make this into an
option, like a
  command line option that basically says "don't fix
plane distances
  when normal snapping" so when someone gets problems,
he can just set
  -ne_nofixdist and go back to the old behaviour. On the
same note, I'd
  also make an additional option "don't snap planes
generated by
  autoclipped models at all". I am not convinced that
the latter is
  always a good idea - even if it doesn't cause any bugs, it
will make
  the bsp file larger than it needs to be.

As for the change in -ne behaviour - although it would be
logical, I
don't think it should be done any more. Maybe some mappers
already use
-ne 0.00000000001 (smaller number) to lessen the SnapPlane
bug. When
-ne gets changed the way I proposed, this will cause MUCH
LESS snapping
for these users, and the bugs that happened when SnapPlane
got
completely disabled could happen again until they readjust
their -ne.
Also, there could be an issue with roundoff-errored normals,
like
'0.00001 0.00001 1.00000000' that would not get snapped
(while
currently, they would even get snapped with -ne 0).

Still, the patch may require much testing - I can see one
case where it
could cause additional problems: assume a map with lots of
complex
models... that could just compile because of the SnapPlane
bug. Trying
to compile it without the bug would bail out because of some
limits of
static structs in q3map2. There may be maps that are
currently at the
very edge of these limits...

Best regards

Rudolf Polzer


_______________________________________________
Gtkradiant mailing list
Gtkradiantzerowing.idsoftware.com
http://zerowing.idsoftware.com/cgi-bin/mailman
/listinfo/gtkradiant