Archived

This topic is now archived and is closed to further replies.

Constructing Brushes?

This topic is 5116 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Guest Anonymous Poster
WTF??!?! IT''S HAIR ON A STICK RETARD WHAT WERE YOU RAISED IN A BARN YOU NERD PUSSY.

Share this post


Link to post
Share on other sites
Brushes (in a level editor) are usually constructed from polygons (as opposed to triangles or quads). This is why when you create a brush with 20 polygons in q3radiant, you don''t see 20 triangles making up the end cap, just one 20-sided polygon. When the map is compiled, all the polygons from most of the brushes (there are one or two exceptions) are collected, split into triangles, and fed in a BSP generator.

When you make a brush, just keep in mind that it''s a closed convex hull, which means that to be valid it must be a solid shape like a cube or a sphere, and musn''t have any leaks. The best way to avoid leaks is to create a vertex list, and have the polygons which make up the brush share vertices, ie. in a cube, three polygons share one vertex.

Also bear in mind that invalid brushes are problematic. For example, the object on the left (looking down from above) would be a perfectly legal three dimensional mesh, but would not be a legal brush. The one on the right, however, would be.
               /                      /
----------/- --------/---
| / | | / |
| --/--- | / |
| |/ | / |
| / | / |
-----/- ---/--------
/ /
This is because if you can trace an imaginary line through a 3D mesh which enters and exits the mesh more once, you don''t have a brush. This is what many level editors strive for: brush integrity. q3radiant even goes so far as to restrict the movement of vertices which would create invalid brushes. You can''t do effective collision detection with the shape on the left, as it should, by rights, be cut into two pieces (a large rectangle and a smaller square). It''s not much of a problem, but it''s still worth noting...

And that was hilarious, AP. lol


Windows 95/NT - 32 bit extensions and a graphical shell for a 16 bit patch
to an 8 bit operating system originally coded for a 4 bit microprocessor,
written by a 2 bit company that can''t stand 1 bit of competition.

Share this post


Link to post
Share on other sites
Thanks Insanity. I have little knowledge on gtkRadiant, but what i know is every geometric object is constructed from brushes and then the polygons(triangles, strips) are made from the brushes when the .map is compiled. I was thinking if could derive some brushes from a set of polygons, or triangle soup i could speed up the collision system. However, your description is helpful, and i''m off to learn more CSG..

And...
Being a dumb stupid may be hilarious,
Promoting stupidness is facetious.

Share this post


Link to post
Share on other sites
In Quake maps the brushes are convex volumes. Because of this they are not described by the coordinates of the vertices but by planes. If you intersect all the planes you get a volume. For example a cube or rectangular block is 6 planes.

The map compiler intersects the planes 3 at a time, and this yields the vertices. These are added to the planes that were used. When this is done, then you have a list of points for each plane. Those get stored as faces, convex polygons. But those are associated with the plane they lie on. The renderer uses the faces to render triangles while the game uses the planes (and not the faces) for collision detection.

Share this post


Link to post
Share on other sites