#include "stdafx.h"
#ifdef _WINDOWS
#include <windows.h>
#endif
#include <math.h>
#include "polygon.h"
CPolygon::CPolygon()
{
}
CPolygon::~CPolygon()
{
delete m_PolyData;
}
void CPolygon::Draw()
{
FACE* ptrFace = m_PolyData->m_faces;
INDEX* ptrIndex = NULL;
int nIndexCount = 0 ;
int nfacesCount = m_PolyData->m_nFacesCount;
while(nfacesCount -- )
{
ptrIndex = m_PolyData->m_faces[nfacesCount].pIndex;
nIndexCount = m_PolyData->m_faces[nfacesCount].nCount;
int pIdxNorm =m_PolyData->m_faces[nfacesCount].nFaceNormal;
glBegin(GL_POLYGON);
glNormal3fv(m_PolyData->m_FaceNormals[pIdxNorm].val);
while(nIndexCount--)
{
int pIdx =m_PolyData->m_faces[nfacesCount].pIndex[nIndexCount].nVertex;
glVertex3fv(m_PolyData->m_vertexs[pIdx].val);
}
glEnd();
//glPopMatrix();
}
}
[c++ opengl] poligon class
Hy.
I have created a poligon class this:
but is very very slow comparated with draw the poly in the code.
Can you give me a hint for a faseter render?
Thanks.
Rather than using GL_POLYGON, do you think you can use GL_TRIANGLES or GL_QUADS? And see if you can use a for loop rather than 2 whiles. And lastly, shouldn't #ifdef _WINDOWS be #ifdef WIN32, but if _WINDOWS works, then use it.
Real efficiency is yielded in if you render all primitives "at once". That requires homogenized geometry. Therefore triangulate the polygons so that all faces are 3 sided, so that you need not distinct say 5-gons from 6-gons and so on. Next, go away from the immediate mode (those glBegin/glEnd stuff) but build arrays of vertex attributes and push them as VBOs to the API. As an optimization step later on, you can optimize the vertex buffers by sorting vertex indices w.r.t. the post-T-&-L cache.
I personally also have dropped pointers to topological elements where possible already in the meshes. Using indices instead have several advantages: They consume less memory (e.g. 4 bytes instead of 8 bytes on 64-bit maschines), and, perhaps more important, they allow loading (and saving) the elements in blocks without any pointer adaption.
I personally also have dropped pointers to topological elements where possible already in the meshes. Using indices instead have several advantages: They consume less memory (e.g. 4 bytes instead of 8 bytes on 64-bit maschines), and, perhaps more important, they allow loading (and saving) the elements in blocks without any pointer adaption.
thanks haegarr.
Then if i use triangle I can draw more than one poly at once?
Because a line of the triangle is shared?
and im not understand this:
what are the VBOs and the attributes?
do you have a link or a book thath explain this?
Thanks.
Then if i use triangle I can draw more than one poly at once?
Because a line of the triangle is shared?
and im not understand this:
Quote:but build arrays of vertex attributes and push them as VBOs to the API
what are the VBOs and the attributes?
do you have a link or a book thath explain this?
Thanks.
Quote:what are the VBOs and the attributes?
do you have a link or a book that explain this?
If you use glBegin/glEnd, you'll have to pass the vertex coordinates and attributes like colors to the GPU each frame. This is really inefficient. VBO's allow you to pass those once and use them every frame. Here's a pdf-file about VBO's: http://developer.nvidia.com/object/using_VBOs.html
Here's a NeHe lesson about VBO's: http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=45
But the quad strip works equals to triangle strip?
Where is better triangle strip and where is better quad strip?
i search in google but i can't find a lot.
Do you have some link on this argument?
Thanks
[Edited by - giugio on August 14, 2008 12:50:26 PM]
Where is better triangle strip and where is better quad strip?
i search in google but i can't find a lot.
Do you have some link on this argument?
Thanks
[Edited by - giugio on August 14, 2008 12:50:26 PM]
Sorry if i post again for the 3rd time,but i'm fascinated by the argument.
I read about the VBO and i have two questions about
1)if i add a new mesh to the scene ,the vertex in the GPU changes,how sincronize with the graphics card VBO's?How about the add/remove vertexes process ?
2)is the strips process of quad/triangle strips convenient(and the two think work fine boot) with VBO's or the game not worth the candle?
Thanks.
I read about the VBO and i have two questions about
1)if i add a new mesh to the scene ,the vertex in the GPU changes,how sincronize with the graphics card VBO's?How about the add/remove vertexes process ?
2)is the strips process of quad/triangle strips convenient(and the two think work fine boot) with VBO's or the game not worth the candle?
Thanks.
GPUs render triangles, so drivers need to split quads into 2 triangles. Best speed is hence achieved if the faces are already ready-to-use, i.e. triangles. There are many discussion whether strips are more efficient than post-T&L cache optimized lists. AFAIK the lists are winning, but I have no personal experience (i.e. time measurements) with this topic yet.
VBOs are very versatile in the sense of usage: There are 9 usage modes, look at those DYNAMIC_... vs STATIC_... vs. STREAM_... and .._DRAW vs. ..._COPY vs ..._READ parameters when invoking glBufferData. Functions exist to map vertex data from/to GPU/CPU accessible memory (heap, VRAM, ...).
In summary VBO is a complex beast. But you have to remember that VBOs are made for fast rendering, and not for editing purposes. The more "dynamic" your mesh is, the more is it likely to be rendered less speedy. But nevertheless does it work. I personally programming an engine with integrated editing purposes. I deal with up to 5 kinds of mesh representation: A topologically full featured EditMesh that comes in 2 flavors (expanded and memory friendly), a TriMesh similar to VBOs but with multiple indices, an application accessible master copy of VBO content, and the VBOs itself. Normally only the master copy (in the case of animated meshes) and the VBOs itself are available, and the other meshes appear during editing or perhaps at load-time only.
Coming to the point of updating vertices, it often happens that large portions of vertices are updated at once, e.g. skeleton animated characters. If done on the CPU, the master copy will be computed accordingly and then pushed to the GPU. For such purposes GL_STREAM_DRAW or perhaps GL_DYNAMIC_DRAW are intended. Other ways exist as well.
However, I neither claim that the way I go is the best, nor do I invite you to do the same. The solutions I implement have some constraints that are normally not part of a game, so you may find simpler solutions for your purposes. I must admit that programming such features definitely costs its time. However, I hope that my posts give you some stimulations.
VBOs are very versatile in the sense of usage: There are 9 usage modes, look at those DYNAMIC_... vs STATIC_... vs. STREAM_... and .._DRAW vs. ..._COPY vs ..._READ parameters when invoking glBufferData. Functions exist to map vertex data from/to GPU/CPU accessible memory (heap, VRAM, ...).
In summary VBO is a complex beast. But you have to remember that VBOs are made for fast rendering, and not for editing purposes. The more "dynamic" your mesh is, the more is it likely to be rendered less speedy. But nevertheless does it work. I personally programming an engine with integrated editing purposes. I deal with up to 5 kinds of mesh representation: A topologically full featured EditMesh that comes in 2 flavors (expanded and memory friendly), a TriMesh similar to VBOs but with multiple indices, an application accessible master copy of VBO content, and the VBOs itself. Normally only the master copy (in the case of animated meshes) and the VBOs itself are available, and the other meshes appear during editing or perhaps at load-time only.
Coming to the point of updating vertices, it often happens that large portions of vertices are updated at once, e.g. skeleton animated characters. If done on the CPU, the master copy will be computed accordingly and then pushed to the GPU. For such purposes GL_STREAM_DRAW or perhaps GL_DYNAMIC_DRAW are intended. Other ways exist as well.
However, I neither claim that the way I go is the best, nor do I invite you to do the same. The solutions I implement have some constraints that are normally not part of a game, so you may find simpler solutions for your purposes. I must admit that programming such features definitely costs its time. However, I hope that my posts give you some stimulations.
I'm not understand the response to this question:
if the responce is true , can you post me some documentation?at least on the theory
sorry for my english.
[Edited by - giugio on August 15, 2008 6:07:20 AM]
Quote:Original post by giugio
2)is the strips process of triangle strips convenient(and the two think work fine boot) with VBO's or the game not worth the candle?
Thanks.
if the responce is true , can you post me some documentation?at least on the theory
sorry for my english.
[Edited by - giugio on August 15, 2008 6:07:20 AM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement