Submission to Open GL ES

[Davespice]

Hi all;

I was just wondering if there was a way to submit your vertices and polys to OGL if they’re held in something other than an array of type GLfloat?

So normally you would do something like this;

Code: Select all

typedef struct {
	GLfloat x;
	GLfloat y;
	GLfloat z;
} Vertex3D;

And then create an array of these however long you need,

Code: Select all

Vertex3D[] vertices = new Vertex3D[6];

Populate it with your point data and then submit this to ogl like so;

Code: Select all

glEnableClientState(GL_VERTEX_ARRAY);
glVertexPointer(3, GL_FLOAT, 0, vertices);

In this way of submission the vertices array appears in memory as an array of 36 GLfloats, which is why you can get away with doing it this way. But what would happen if I made Vertex3D into a class instead of a typedef, so that I could reuse that class for vectors and would therefore have methods like normalise on the class itself. Is there a way to submit to ogl with the data held this way, so that the vertex/vector class has x y and z properties on it?

Please can we avoid the obligatory “why do you want to do that” questions.

[jmacey]

as long as the class data is flat / packed in the right way you can use it, I use it a lot in my code,

For example

Code: Select all

class  Vec3
{

public:
	#pragma pack(push,1)
	
		union
		{
			struct
			{
				GLfloat m_x;
				GLfloat m_y;
				GLfloat m_z;
	
			};
		#pragma pack(pop)
  GLfloat m_openGL[3];
  };
  
};
// as std::vectors are contiguous and only data packed this
// will look like an array
std::vector <Vec3> vertices;

// push back data
Vec3 v(1,2,1);
vertices.push_back(v);
// do something

glVertexPointer(3, GL_FLOAT, 0, &vertices[0].m_x);

Should work, have a look at some of my ngl:: examples as I do this a lot.

Jon

[OtherCrashOverride]

But what would happen if I made Vertex3D into a class instead of a typedef

The only care that needs to be taken when doing that is to ensure the class/struct remains 'plain old data' (POD). Using virtual methods or inheritance will cause a vtable to be appended and interfere with the memory layout. The pedantic will also point out that care should be taken to ensure the memory allocated for the class/struct is properly aligned for its contents. The '#pragma pack(push,1)' line tells the compiler to use your memory layout instead of padding types for memory alignment.