[Gtkradiant] [1.5] obj/mtl support, SnapPlane bug (causing collision brushes to disappear )
spam at codecreator.net
Mon Dec 17 12:01:21 CST 2007
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 ;)
Am Montag, 17. Dezember 2007 schrieb Rudolf Polzer:
> I made two patches against GtkRadiant/q3map2:
> Completed the support for .obj format in PicoModel:
> 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
> 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
> 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
> 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
> 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
> Gtkradiant mailing list
> Gtkradiant at zerowing.idsoftware.com
www.codecreator.net | GPG: 0xD4DB516D
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://zerowing.idsoftware.com/pipermail/gtkradiant/attachments/20071217/fff4f0cb/attachment.pgp
More information about the Gtkradiant