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

[namespace]

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/~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
>
>
> _______________________________________________
> Gtkradiant mailing list
> Gtkradiant at zerowing.idsoftware.com
> http://zerowing.idsoftware.com/cgi-bin/mailman/listinfo/gtkradiant



-- 
www.codecreator.net | GPG: 0xD4DB516D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://zerowing.idsoftware.com/pipermail/gtkradiant/attachments/20071217/fff4f0cb/attachment.pgp