Sign in to follow this  
giugio

OpenGL [c++ opengl] poligon class

Recommended Posts

giugio    246
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
Tenac    124
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
haegarr    7372
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
giugio    246
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
beun    160
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
giugio    246
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
giugio    246
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
haegarr    7372
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
giugio    246
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
haegarr    7372
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
giugio    246
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
haegarr    7372
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
giugio    246
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  

  • Similar Content

    • By markshaw001
      Hi i am new to this forum  i wanted to ask for help from all of you i want to generate real time terrain using a 32 bit heightmap i am good at c++ and have started learning Opengl as i am very interested in making landscapes in opengl i have looked around the internet for help about this topic but i am not getting the hang of the concepts and what they are doing can some here suggests me some good resources for making terrain engine please for example like tutorials,books etc so that i can understand the whole concept of terrain generation.
       
    • By KarimIO
      Hey guys. I'm trying to get my application to work on my Nvidia GTX 970 desktop. It currently works on my Intel HD 3000 laptop, but on the desktop, every bind textures specifically from framebuffers, I get half a second of lag. This is done 4 times as I have three RGBA textures and one depth 32F buffer. I tried to use debugging software for the first time - RenderDoc only shows SwapBuffers() and no OGL calls, while Nvidia Nsight crashes upon execution, so neither are helpful. Without binding it runs regularly. This does not happen with non-framebuffer binds.
      GLFramebuffer::GLFramebuffer(FramebufferCreateInfo createInfo) { glGenFramebuffers(1, &fbo); glBindFramebuffer(GL_FRAMEBUFFER, fbo); textures = new GLuint[createInfo.numColorTargets]; glGenTextures(createInfo.numColorTargets, textures); GLenum *DrawBuffers = new GLenum[createInfo.numColorTargets]; for (uint32_t i = 0; i < createInfo.numColorTargets; i++) { glBindTexture(GL_TEXTURE_2D, textures[i]); GLint internalFormat; GLenum format; TranslateFormats(createInfo.colorFormats[i], format, internalFormat); // returns GL_RGBA and GL_RGBA glTexImage2D(GL_TEXTURE_2D, 0, internalFormat, createInfo.width, createInfo.height, 0, format, GL_FLOAT, 0); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST); DrawBuffers[i] = GL_COLOR_ATTACHMENT0 + i; glBindTexture(GL_TEXTURE_2D, 0); glFramebufferTexture(GL_FRAMEBUFFER, GL_COLOR_ATTACHMENT0 + i, textures[i], 0); } if (createInfo.depthFormat != FORMAT_DEPTH_NONE) { GLenum depthFormat; switch (createInfo.depthFormat) { case FORMAT_DEPTH_16: depthFormat = GL_DEPTH_COMPONENT16; break; case FORMAT_DEPTH_24: depthFormat = GL_DEPTH_COMPONENT24; break; case FORMAT_DEPTH_32: depthFormat = GL_DEPTH_COMPONENT32; break; case FORMAT_DEPTH_24_STENCIL_8: depthFormat = GL_DEPTH24_STENCIL8; break; case FORMAT_DEPTH_32_STENCIL_8: depthFormat = GL_DEPTH32F_STENCIL8; break; } glGenTextures(1, &depthrenderbuffer); glBindTexture(GL_TEXTURE_2D, depthrenderbuffer); glTexImage2D(GL_TEXTURE_2D, 0, depthFormat, createInfo.width, createInfo.height, 0, GL_DEPTH_COMPONENT, GL_FLOAT, 0); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_NEAREST); glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_NEAREST); glBindTexture(GL_TEXTURE_2D, 0); glFramebufferTexture(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, depthrenderbuffer, 0); } if (createInfo.numColorTargets > 0) glDrawBuffers(createInfo.numColorTargets, DrawBuffers); else glDrawBuffer(GL_NONE); if (glCheckFramebufferStatus(GL_FRAMEBUFFER) != GL_FRAMEBUFFER_COMPLETE) std::cout << "Framebuffer Incomplete\n"; glBindFramebuffer(GL_FRAMEBUFFER, 0); width = createInfo.width; height = createInfo.height; } // ... // FBO Creation FramebufferCreateInfo gbufferCI; gbufferCI.colorFormats = gbufferCFs.data(); gbufferCI.depthFormat = FORMAT_DEPTH_32; gbufferCI.numColorTargets = gbufferCFs.size(); gbufferCI.width = engine.settings.resolutionX; gbufferCI.height = engine.settings.resolutionY; gbufferCI.renderPass = nullptr; gbuffer = graphicsWrapper->CreateFramebuffer(gbufferCI); // Bind glBindFramebuffer(GL_DRAW_FRAMEBUFFER, fbo); // Draw here... // Bind to textures glActiveTexture(GL_TEXTURE0); glBindTexture(GL_TEXTURE_2D, textures[0]); glActiveTexture(GL_TEXTURE1); glBindTexture(GL_TEXTURE_2D, textures[1]); glActiveTexture(GL_TEXTURE2); glBindTexture(GL_TEXTURE_2D, textures[2]); glActiveTexture(GL_TEXTURE3); glBindTexture(GL_TEXTURE_2D, depthrenderbuffer); Here is an extract of my code. I can't think of anything else to include. I've really been butting my head into a wall trying to think of a reason but I can think of none and all my research yields nothing. Thanks in advance!
    • By Adrianensis
      Hi everyone, I've shared my 2D Game Engine source code. It's the result of 4 years working on it (and I still continue improving features ) and I want to share with the community. You can see some videos on youtube and some demo gifs on my twitter account.
      This Engine has been developed as End-of-Degree Project and it is coded in Javascript, WebGL and GLSL. The engine is written from scratch.
      This is not a professional engine but it's for learning purposes, so anyone can review the code an learn basis about graphics, physics or game engine architecture. Source code on this GitHub repository.
      I'm available for a good conversation about Game Engine / Graphics Programming
    • By C0dR
      I would like to introduce the first version of my physically based camera rendering library, written in C++, called PhysiCam.
      Physicam is an open source OpenGL C++ library, which provides physically based camera rendering and parameters. It is based on OpenGL and designed to be used as either static library or dynamic library and can be integrated in existing applications.
       
      The following features are implemented:
      Physically based sensor and focal length calculation Autoexposure Manual exposure Lense distortion Bloom (influenced by ISO, Shutter Speed, Sensor type etc.) Bokeh (influenced by Aperture, Sensor type and focal length) Tonemapping  
      You can find the repository at https://github.com/0x2A/physicam
       
      I would be happy about feedback, suggestions or contributions.

    • By altay
      Hi folks,
      Imagine we have 8 different light sources in our scene and want dynamic shadow map for each of them. The question is how do we generate shadow maps? Do we render the scene for each to get the depth data? If so, how about performance? Do we deal with the performance issues just by applying general methods (e.g. frustum culling)?
      Thanks,
       
  • Popular Now