• Advertisement

Archived

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

Making a class for polygons

This topic is 5711 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

I am adding collsion detection to my code and I''ve decided to make a polygon class. I am unsure how to internally represent the polygon in a class. Should I just make room for an array of 3 vectors? What if I later want to deal with quads? Anyone use pointers to different sized arrays? My problem with this is that I don''t like having seemingly random vector declaration clusters all over the place? How have you guys dealt with individual polygons in your code? Thanks in advance.

Share this post


Link to post
Share on other sites
Advertisement
quote:
Original post by executor_2k2
...I''ve decided to make a polygon class.

What was the rationale behind this decision? Why did you decide to make a polygon class? What cardinal properties does a polygon represent, and what operations does it perform?

Polygons in computer graphics are implicit structures; they exist because of the presence of vertices (which is why you''ll find that neither Glide nor OpenGL nor Direct X Graphics nor any other self-respecting graphics API has a polygon structure, but every one has [multiple] vertex structure[s]).

Polygons can easily be represented as mere indices referring to specific vertices in a repository (see index buffers in DXG).

Anyway, to solve your problem:

// N-sided polygon declaration
struct Polygon
{
vector< Vertex > vertices;
};
 
OR
 
struct Polygon
{
Vertex * vertices;
};

I prefer the former as it removes the responsibility for memory management.

Share this post


Link to post
Share on other sites
Common 3D cards (if not all) render only triangles and not polygons. If you want real POLYgons make them up from triangles/faces.

As said before you shouldn''t define the face explicit, with values for each vertex. Rather use references on a vertexarray (or vertexbuffer) either by index if your vertices are fixed in number (easier for DrawPrimitive calls in D3D) or by pointers if you want more flexibility.

If needed you can then implement collision detection on those faces.

As Polygons are sets of faces, aline intersects a polygon if it intersects any one face making up the polygon.

---------------------------
I may be getting older, but I refuse to grow up

Share this post


Link to post
Share on other sites
quote:
Original post by Oluseyi
[quote]Original post by executor_2k2
...I've decided to make a polygon class.
What was the rationale behind this decision? Why did you decide to make a polygon class? What cardinal properties does a polygon represent, and what operations does it perform?

Polygons in computer graphics are implicit structures; they exist because of the presence of vertices (which is why you'll find that neither Glide nor OpenGL nor Direct X Graphics nor any other self-respecting graphics API has a polygon structure, but every one has [multiple] vertex structure[s]).

Polygons can easily be represented as mere indices referring to specific vertices in a repository (see index buffers in DXG).

Anyway, to solve your problem:

// N-sided polygon declaration
struct Polygon
{
vector< Vertex > vertices;
};
 
OR
 
struct Polygon
{
Vertex * vertices;
};


I prefer the former as it removes the responsibility for memory management.



Although it is recomended that you use the second method due to speed. I can't verify this, but that is what is says in the nehe tut. STL is fast, but not fast enough, and when you are working with such a low level class, that will probably have 1000s of instances, you will want to get the best performance out of it, especially in a 3D app where framerate is everything. Besides, just take care of memory management by using a class.


[edited by - Tylon on July 1, 2002 8:16:13 PM]

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
Well, assuming you are using seperate datasets for your rendering geometry and collision data (I sincerely hope you are), you can use polygons if you like while using triangles for your render data.

The MAJOR downfall of using polygons however is that it is very very easy for your artists to generate polygons that have points not in the same plane. For example, the jitter/smooth tools in lightwave completely destroy any concept of points of a polygon being in the same plane and this will play havok with your collision detection.

The first, most important step in collision detection is ensuring your dataset is reliable. This will save you hours of debugging.

As an example, here''s the polygon class I used in one of my older games:

class CollidePolygon
{
public:
// Default constructor
CLASS_EXPORT cCollidePolygon(void);

// Copy constructor
CLASS_EXPORT cCollidePolygon(const cCollidePolygon &other);

// Destructor
CLASS_EXPORT ~cCollidePolygon(void);

// Given the polygon vertices, compute the rest of the polygon properties
CLASS_EXPORT void ComputeProperties(cCollideMesh *mesh_ptr);

// Test to see if the polygon is co-planar. The closer to zero the result, the more co-planar the polygon is.
CLASS_EXPORT float CoPlanarVerticesTest(const cCollideMesh *mesh_ptr) const;

CLASS_EXPORT cCollidePolygon& operator = (const cCollidePolygon &other);

friend CLASS_EXPORT cFileStream& operator << (cFileStream &stream, const cCollidePolygon &poly);
friend CLASS_EXPORT cFileStream& operator >> (cFileStream &stream, cCollidePolygon &poly);

// Number of points in the polygon
int m_NbPoints;

// List of point indices within the parent collide mesh
int m_Points[4];

// Outward pointing normal
cVector m_Normal;

// Distance to origin
float m_D;

// Two axes used to maximally project the polygon onto a plane
int m_PlaneAxis[2];

// Bounding sphere position
float m_SphereX, m_SphereY, m_SphereZ;

// Bounding sphere radius
float m_SphereRadius;

// Surface index
int m_Surface;

// Average colour of this polygon due to lighting
unsigned char m_Colour[3];
};

This stored a maximum of 4 points per polygon and the converter split any non-co-planar polygons into triangles before outputting to the final file format.

A bad idea would be to allocate an array of vertices PER POLYGON. This will kill you in a number of ways:

* Allocation header forces data out of cache-lines
* Out-of-order allocation causes lots of cache misses
* The mere act of allocation will increase fragmentation

The solution (if you''re having polygons) is to allocate per vertex in your converter and then memory map the data for final output. Upon loading pass your data through a link stage to restore the pointers and you effectively have the same data structure as allocating per vertex, minus the above downsides.

Obviously you can''t modify the data structure... although if you''re not sure how to represent polygons at this stage you should first make a game with this strategy before considering anything further.

Lately I''m using nothing but triangles because it makes your life so much simpler.

Share this post


Link to post
Share on other sites

  • Advertisement