Source for q3map2?

(G0-Gerbil) #1

Can’t remember off top of my head, but I seem to recall Ydnar (has to?) give out the source for q3map2.
I’m after the bit where it turns a .map brush definition into actual faces, or more precisely the code that will take 3 non-coplanar planes and work out the vertex where they meet.

Reason is I’m trying out a little external tool to help create certain features in radiant that otherwise would be a bast, but my 3D maths isn’t up to the initial conversion :frowning:

I need to use the .MAP planes definition of a brush and be able to convert it into a polygon mesh so I can fiddle it and then return it back to .map, but sadly I’m no good at plane intersection calculations, so was hoping I could just rip straight from the source :slight_smile:

(chavo_one) #2

I think the code is publicly available. I found it at least:
https://zerowing.idsoftware.com:666/radiant/GtkRadiant/trunk/tools/quake3/q3map2/

(G0-Gerbil) #3

Ahhhh cheers - I just had a quick poke around shaderlab.com for it, which of course didn’t take very long in it’s current incarnation :smiley:

(G0-Gerbil) #4

Ummm errr bugger - might have bitten off more than I can chew - can anyone point me to the code where a brush (infinite planes) gets converted into actual polygons (or at least actual face / winding)?

(ydnar) #5

It creates polygons from brush faces by creating a huge winding (polygon) then chopping it by all the other brush planes.

y

(G0-Gerbil) #6

Oh um ok, guess I’ll have to brush up on the maths a bit more than I’d hoped.
I’m sure it’ll do me good though (as well as working differently to how I thought), so thanks :slight_smile:

To clarify, is it a two stage process where it takes the plane you want to make into a winding, and then chops it against each other plane, storing the resulting intersecting lines.
Then at the end it takes all these (infinite) lines and builds a winding from them?

(MindLink) #7

Gerbil just trying to understand how q3map2 works or do you want to program something like that yourself? :slight_smile:
Btw. there are several methods to do the conversion from halfplane-definition to vertex/polygon-definition. The rough topic you should have a look at is polyhedral computing. (if you want to dive deep into the topic have a look at http://www.ifor.math.ethz.ch/staff/fukuda/polyfaq/polyfaq.html :wink: )… Keep in mind that most of those calculations are pretty unstable numerically, and depending on what you’re trying to do could end up being pretty messy =)
I did a conversion halfspace->vertex-stuff and ended up calculating all 3-plane intersections (points), deleting those that are outside of any of the halfspace planes and building the faces using the intersection and vertex infos. Works pretty well if you know your maths.

(G0-Gerbil) #8

I’m trying to write a little program to bevel brushes painted with a certain texture.
Now while expanding a brush is simplicity itself (take each face, calculate it’s normal from the 3 points, then shift each point along the normal by whatever amount), I want the bevels to be done properly. For this I need to know the actual vertices where the planes meet.
Initially I thought q3map would use the ‘normal’ method I’d found online. Mathematically of course, they’d prefer to just calculate the intersectrion of 3 infinite planes, but the calculations left my head cold trying to convert them to something I could use.
This way of Ydnar’s seems to make much more sense, and I’m happy enough doing plane->plane intersections (I think!), so doing that then using the resulting lines to create the winding is pretty simple, thankfully!

Also, if I use roughly the same method as q3map2, I’m less likely to end up with borked or incompatible results?

Oh and I’m also a masochist when it comes to maths, so this stuff interests me, just that a fair amount of it is currently waaaaaaay over my head :smiley:

(G0-Gerbil) #9

Cheers for the link mindkill, but I’m not up to date with proper terminology so I don’t know if what I want is on it!

Just out of curiousity, can I find the direction of the line where two planes interesect by finding the cross product of the 2 planes’ normals?
I think… that then I could find the line equation by finding a point that lies on both planes?

IE equation of a line is something like…:

y = mx+b

OK that’s a 2D example, but the m, gradiant, is basically the line direction, (the normalized cross of the two plane normals above?), leaving me with ‘b’ to find.
Ermmm, correct? :slight_smile:

(G0-Gerbil) #10

It creates polygons from brush faces by creating a huge winding (polygon) then chopping it by all the other brush planes.

Amazingly enough I got my code to work from this brief description (ok ok I looked at the source (for hours actually, before I even found the bloody routine!) to see the general stages it went through)!

Have to say, it’s a gorgeous solution to what I initially thought was a stupidly tough problem.
I love lateral thinking like this :slight_smile:
So here’s a sample import I’ve done in all it’s t-junction’ed, untextured, simplistic lighting glory!

My import is far to slow to work on an entire map at a time, but then again it’s only meant to process brushes for special effects.
(I have the idea to process only brushes in certain new entities - idea stolen blatantly from Ratty’s func_group2 entity).
Now I can import brushes and manipulate them either as planes or actual faces I should be able to do my own ‘plugin-style’ effects on brushes.
Of course, I’m erm not sure yet what they will be, but I do know it means I can do stuff radiant cant.
If I come up with any decent ideas, I might consider making the program available to everyone :slight_smile: