Change OpenGL 3 Renderer to Core Profile

[calebabutler]

This is a much smaller pull request compared to my previous one that only switches to the 3.3 core profile without any of the other major changes. I also cleaned up the code a little bit and made the reasons why I was commenting certain things out more obvious.

[numberZero]

Thanks for the PR.
Maybe instead of using a global, split beginDraw into pointer-accepting and offset-accepting versions, so that the former prepares the buffer and calls the latter? Would that integrate well with the existing call sites?

[calebabutler]

Thank you, it required a little bit of reworking the drawHardwareBuffer and drawVectorPrimitiveList functions, but I replaced the global with two functions as I agree that that is a much better way of doing it.

[numberZero]

Now that verticesBase is always a pointer and not an offset, it should likely be const void *

[numberZero]

it required a little bit of reworking the drawHardwareBuffer

I guess EHM_NEVER is going to cause grief anyway. And it’s the default IIUC...

Some time ago, I’ve seen code that simply replaces EHM_NEVER with something else, in all buffers, everywhere, just to make it work with WebGL (which can only render from buffers, just like GL Core). Not the cleanest way but it suggests that treating EHM_NEVER like something else in the whole driver may very well work.

Also, how do you handle index buffers?

[calebabutler]

Thank you for the code correction, and you were absolutely right about changing that type. So, right now my video driver handles index buffers in not such a good way; it assumes GL_ELEMENT_ARRAY_BUFFER is bound before calling drawVertexPrimitiveList when you call the function in one of the modes that ends up calling glDrawElements. I'm sure this can be done much better. I realized I was not handling the EHM_NEVER case right ever, so I changed the code slightly, for vertex buffers it can (kind of) handle it by using the global VBO, and for index buffers it just ignores it. If this is going in the wrong direction let me know.

[numberZero]

Ignoring EHM_NEVER works fine for WebGL:

irrlicht/source/Irrlicht/CWebGL1Driver.cpp

Lines 77 to 95 in cfb73d0

	//! Draws a mesh buffer
	void CWebGL1Driver::drawMeshBuffer(const scene::IMeshBuffer* mb)
	{
	if ( mb )
	{
	// OK - this is bad and I hope I can find a better solution.
	// Basically casting away a const which shouldn't be cast away.
	// Not a nice surprise for users to see their mesh changes I guess :-(
	scene::IMeshBuffer* mbUglyHack = const_cast<scene::IMeshBuffer*>(mb);
	// We can't allow any buffers which are not bound to some VBO.
	if ( mb->getHardwareMappingHint_Vertex() == scene::EHM_NEVER)
	mbUglyHack->setHardwareMappingHint(scene::EHM_STREAM, scene::EBT_VERTEX);
	if ( mb->getHardwareMappingHint_Index() == scene::EHM_NEVER)
	mbUglyHack->setHardwareMappingHint(scene::EHM_STREAM, scene::EBT_INDEX);
	COGLES2Driver::drawMeshBuffer(mb);
	}
	}

So should be fine on GL3 as well, as long as is done properly and systematically and doesn’t cause any leaks (Irrlicht way of caching meshes is prone of that to my knowledge).

[sfan5]

Assuming this is superseded due to #250

[numberZero]

@sfan5 no it isn’t. Only #232 is, with #250 and this one together.

[numberZero]

@calebabutler Any news on this?

And on EHM_NEVER on index buffers: I now think just ignoring one is wrong, it’s better to handle it the same way as vertices, moving to a buffer just before rendering. To reduce potential surprises from the “hw buffer link” and whatever else. I’d not expose any mixed RAM/VBO calls though, keeping all that stuff as an internal detail.