Sign in to follow this  
giugio

OpenGL [c++ opengl] poligon class

Recommended Posts

Hy. I have created a poligon class this:
#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();
		
	}
}			
		
		


but is very very slow comparated with draw the poly in the code. Can you give me a hint for a faseter render? Thanks.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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:
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.

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
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]

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
I'm not understand the response to this question:
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]

Share this post


Link to post
Share on other sites
I assume you're asking whether rendering tri-strips with VBOs is fine?!

Yes, you can do so, but must be aware that using strips
(a) enforces the need to _have_ strips, e.g. to implement strip generation algorithms for non-strip models,
(b) may yield in the need of more than one invocations of glDrawElements, namely if more than a single strip is used,
(c) and/or (partly alternatively to (b)) introduce degenerated triangles.

The advantage of strips is their lesser amount of vertex indices which are to be generated and pushed into the VBO. On the other hand, if not using strips but lists (i.e. each triangle is defined by its own 3 vertex indices) you can optimize the order of indices so that the resulting timing outperforms strips. You have to implement an algorithm for that optimization, of course, but on the other hand you would also need to implement an algorithm for building strips.


But, if your question addresses whether building strips is itself a convenient process when dealing with VBOs ... I don't know, because I never implemented such an algorithm. As can be seen from my answers, I personally go the way of lists.


If you mean something else, please re-formulate your question.

Share this post


Link to post
Share on other sites
very thanks haegarr.
Quote:

if not using strips but lists (i.e. each triangle is defined by its own 3 vertex indices)

i'm not understand why strips and lists can't cooperate, why i can't use a lists of strips?
this is your answer that i'm not understand
[qute]
you can optimize the order of indices so that the resulting timing outperforms strips
[/quote]


Is useless?

Share this post


Link to post
Share on other sites
Perhaps we have a misunderstanding of the term "triangle list" here...

Triangle strips and triangle lists can co-exist, of course. But you can push either a strip or a list to the API. If you have more than 1 strip or else both a strip and a list, you need to invoke glDrawElements more than once. The declaration
glDrawElements( GLenum mode, GLsizei count, GLenum type, const GLvoid *indices )
requires a mode as the 1st parameter. It can be (besides others) GL_TRIANGLE_STRIP or else GL_TRIANGLES (for a list). And if it is GL_TRIANGLE_STRIP then the count parameter denotes the length of 1 strip.

To make it clear: A triangle list means that a sequence of indices
{ i0, i1, i2, i0, i3, i4, i5, ... }
is interpreted as
triangle 1: vertices with indices i0, i1, i2
triangle 2: vertices with indices i0, i3, i4
...
so each triplet of vertex indices addresses the vertices of a single triangle.

To understand why this can be better than triangle strips, you must have knowledge of the cache that follows the "transformation & lighting" hardware, or for short "post-T&L cache". As its name suggest, it caches vertices that are already processed. That cache isn't very big; it has thereabout 20 to 30 entries (perhaps bigger ones exist nowadays). Now, if you can apply a sort algorithm that ensures that any vertex of the mesh is not used any more after it is once forced out of the cache, you have an optimal use case. But if you use strips, you have another force that influences your indexing scheme, and perhaps the need to introduce additional vertices (for degeneration) that seizes cache places, and all that may lead to sub-optimality.

I don't say "strips are evil". I say that triangle lists can be better. Whether or not depends on the mesh and its vertex indexing.

Share this post


Link to post
Share on other sites
Thanks.
I'm try to compile an example from the "beginning opengl game programming" , chapther 10 in which use the list,but the frame rating in my pc(from the 2000)is equal or low slower than not use it than with strips.
I repeat,is a 2000 pc, can be?.
by

[Edited by - giugio on August 15, 2008 12:07:50 PM]

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this  

  • Forum Statistics

    • Total Topics
      627749
    • Total Posts
      2978913
  • Similar Content

    • By DelicateTreeFrog
      Hello! As an exercise for delving into modern OpenGL, I'm creating a simple .obj renderer. I want to support things like varying degrees of specularity, geometry opacity, things like that, on a per-material basis. Different materials can also have different textures. Basic .obj necessities. I've done this in old school OpenGL, but modern OpenGL has its own thing going on, and I'd like to conform as closely to the standards as possible so as to keep the program running correctly, and I'm hoping to avoid picking up bad habits this early on.
      Reading around on the OpenGL Wiki, one tip in particular really stands out to me on this page:
      For something like a renderer for .obj files, this sort of thing seems almost ideal, but according to the wiki, it's a bad idea. Interesting to note!
      So, here's what the plan is so far as far as loading goes:
      Set up a type for materials so that materials can be created and destroyed. They will contain things like diffuse color, diffuse texture, geometry opacity, and so on, for each material in the .mtl file. Since .obj files are conveniently split up by material, I can load different groups of vertices/normals/UVs and triangles into different blocks of data for different models. When it comes to the rendering, I get a bit lost. I can either:
      Between drawing triangle groups, call glUseProgram to use a different shader for that particular geometry (so a unique shader just for the material that is shared by this triangle group). or
      Between drawing triangle groups, call glUniform a few times to adjust different parameters within the "master shader", such as specularity, diffuse color, and geometry opacity. In both cases, I still have to call glBindTexture between drawing triangle groups in order to bind the diffuse texture used by the material, so there doesn't seem to be a way around having the CPU do *something* during the rendering process instead of letting the GPU do everything all at once.
      The second option here seems less cluttered, however. There are less shaders to keep up with while one "master shader" handles it all. I don't have to duplicate any code or compile multiple shaders. Arguably, I could always have the shader program for each material be embedded in the material itself, and be auto-generated upon loading the material from the .mtl file. But this still leads to constantly calling glUseProgram, much more than is probably necessary in order to properly render the .obj. There seem to be a number of differing opinions on if it's okay to use hundreds of shaders or if it's best to just use tens of shaders.
      So, ultimately, what is the "right" way to do this? Does using a "master shader" (or a few variants of one) bog down the system compared to using hundreds of shader programs each dedicated to their own corresponding materials? Keeping in mind that the "master shaders" would have to track these additional uniforms and potentially have numerous branches of ifs, it may be possible that the ifs will lead to additional and unnecessary processing. But would that more expensive than constantly calling glUseProgram to switch shaders, or storing the shaders to begin with?
      With all these angles to consider, it's difficult to come to a conclusion. Both possible methods work, and both seem rather convenient for their own reasons, but which is the most performant? Please help this beginner/dummy understand. Thank you!
    • By JJCDeveloper
      I want to make professional java 3d game with server program and database,packet handling for multiplayer and client-server communicating,maps rendering,models,and stuffs Which aspect of java can I learn and where can I learn java Lwjgl OpenGL rendering Like minecraft and world of tanks
    • By AyeRonTarpas
      A friend of mine and I are making a 2D game engine as a learning experience and to hopefully build upon the experience in the long run.

      -What I'm using:
          C++;. Since im learning this language while in college and its one of the popular language to make games with why not.     Visual Studios; Im using a windows so yea.     SDL or GLFW; was thinking about SDL since i do some research on it where it is catching my interest but i hear SDL is a huge package compared to GLFW, so i may do GLFW to start with as learning since i may get overwhelmed with SDL.  
      -Questions
      Knowing what we want in the engine what should our main focus be in terms of learning. File managements, with headers, functions ect. How can i properly manage files with out confusing myself and my friend when sharing code. Alternative to Visual studios: My friend has a mac and cant properly use Vis studios, is there another alternative to it?  
    • By ferreiradaselva
      Both functions are available since 3.0, and I'm currently using `glMapBuffer()`, which works fine.
      But, I was wondering if anyone has experienced advantage in using `glMapBufferRange()`, which allows to specify the range of the mapped buffer. Could this be only a safety measure or does it improve performance?
      Note: I'm not asking about glBufferSubData()/glBufferData. Those two are irrelevant in this case.
    • By xhcao
      Before using void glBindImageTexture(    GLuint unit, GLuint texture, GLint level, GLboolean layered, GLint layer, GLenum access, GLenum format), does need to make sure that texture is completeness. 
  • Popular Now