Bye and Hello, Again!

It’s been a long time!

I’ve finally decided to self host my WordPress blog, along with setting up my own domain at benh.me.

I will be at http://blog.benh.me from now on. See you there!

P.S. all the existing posts and comments have been migrated over as well.

Advertisements

DBConnect

Hello all, it’s been a while.

Today I am releasing DBConnect, another simple useful utility alongside with UUIDer. It has been quite a handy tool for myself at work so I’d like to share it. I wished there was something like that when I did my database unit in uni last year!

DBConnect is a simple GUI application that allows users to quickly connect and create(SQLite) different types of databases and run queries on them.

You can check it out and download a copy for Windows over at Infinity Box Studios. MacOS builds are not provided at the moment, but you can easily install Qt and build it yourself.

Source and binary is also available on GitHub. The application was developed using Qt5.3.1, and is required to build the application. Everything’s released under the BSD 3-Clause license at the moment.

UUIDer: An UUID generator for Windows & Mac

I’ve released a simple UUID generator app before Christmas. It’s a simple GUI application written in Qt which runs on Windows and newer versions of MacOS. I know there are a gillion of these generators on the internet but most of them do not provide option for choosing the UUID version, name space and data seed. People like me also prefer a standalone application.

The builds are all portable, so there’s no installation involved. Source is available over at GitHub (just Google “UUIDer”).
I have plans for implementing a save feature for saving already generated keys and adding notes for them, but this is low priority at the moment unless there’s a huge demand for it.

Any issues you can drop a comment below or send a Twitter/Email message to Infinity Box Studios.

Link to download page: click here

Link to GitHub repository: click here

Learning OpenGL. Log 4

This post is part of a series of logs of my journey in learning OpenGL (or as some say, modern OpenGL. OpenGL 3.1+).

—————————————————————————————————————————————–

Since the last log. I’ve done a lot of code exercises, basically involving implementing the render system in my engine. The main two focus were moving away from the homogenous/normalized device coordinate system and using VAOs(vertex array objects) properly.

Projection, projections

I spent  quite a bit of time over the last couple days learning and implementing perspective and orthogonal projects (and wrapping them into a simple camera class). It’s been quite a few years since I’ve done calculus back in high school. Where I’ve learnt the basics of matrix maths. I know how matrix multiplication works and I do have some basic ideas on what the maths are doing when I looked at the necessary steps to create a perspective project matrix, but I didn’t really understand the higher level concepts and theories in the transformations. Mostly because my brain was in denial and did not want to learn them, plus I just couldn’t care less at the time. So I did what any lazy person would and went the premixed cake flour route. I read a bunch of tutorials online and books and stitch together bits and pieces of codes that will work for now. Leaving the mess to my future self to worry later. At the end of the day. The minimal you need to know when comes to learning new stuff is knowing what things do, but not how they do it. At least that’s how I look at it.

Vertex Buffer Objects

I only just picked up what vertex buffer objects really do yesterday. Reading any tutorial or guide on modern OpenGL. One of the first things you do when you want to draw something (e.g. a triangle). You have to setup a vertex buffer object by calling glGenVertexArray(), and bind it by calling glBindVertexArray(). They then move on to do other stuff only to never return to the generated vertex array object (aka: VAO).

After spending much time on Google-ing, reading and cursing. I’ve finally came to the understanding that the VAO is conceptually just an object that records all the configure and setup calls such as glBindBuffer(), glEnableVertexAttriArray()m gkVertexAttribPointer() when it is binded. So instead of calling those functions everytime I made a draw call. I can just create and bind a VAO  and make those calls during object setup, and then bind the VAO each time I want to draw the object and unbind right after. When drawing multiple objects (e.g. multiple triangle shapes), each object should have their own vertex buffer object and just bind it when it needs to be drawn. Very cool stuff.

One thing to take note here: The usual order to setup things up is the following:

  • create and bind a VAO
  • create and bind a vertex buffer object (VBO)
  • buffer data.
  • call your gl*Pointer functions to enable and set attributes. (This automatically associates the attributes with the VBO. Don’t call glDisableAttribPointer() here.
  • you can unbind your VBO now. (as far as I can tell it doesn’t effect anything).
  • unbind VAO
  • call glDisableVertexAttribPointer(). (seems to be optional. I am not sure if I am suppose to).

Next

The next thing I will learn and work on is textures and simple lights.

Learning OpenGL. Log 3

This post is part of a series of logs of my journey in learning OpenGL (or as some say, modern OpenGL).

—————————————————————————————————————————————–

I’ve started an other log, dedicated for the engine project, so I won’t talk about it any more here unless it’s very cool or related.

Today I worked with the glm library a bit more and wrote a TransformationMatrix class.

class TransformationMatrix
{
private:
	static const glm::mat4 sk_IdentityMatrix;		
	
	glm::mat4	m_ScaleMatrix;
	glm::mat4	m_RotationMatrix;
	glm::mat4	m_TranslationMatrix;
	glm::mat4	m_FinalMatrix;

	bool		m_Evaluated;

public:
	TransformationMatrix(void);
	
	TransformationMatrix & SetScale(const float p_ScaleX, const float p_ScaleY, const float p_ScaleZ);
	/*! Rotate angles in degrees. */
	TransformationMatrix & SetRotation(const float p_AngleX, const float p_AngleY, const float p_AngleZ);
	/*! */
	TransformationMatrix & SetTranslation(const float p_PosX, const float p_PosY, const float p_PosZ);
	/*! Return the raw pointer to the matrix. Evaluates final transformation matrix if it hasn't already. */
	const GLfloat * const GetRawPtr(void);
	/*! */
	const glm::mat4 & GetGLMMatrix(void);
	/*! Evaluate the final transformation matrix if it's not done already. */
	TransformationMatrix & Evaluate(void);
	
}; // MatrixPipeline class

A very simple class. The name is a bit deceiving. The entire class is actually compose of 4 glm::mat4 objects. 3 for the basic transformations, and the final one being the product of the other 3. The comments are a bit incomplete but you can probably tell what the member functions do already. There are 3 setter methods, for scaling, translation and rotation. There are also two getter methods for getting the final transformation matrix.

What interesting here is that, at the moment the final transformation matrix is only evaluated when it needs to be re-evaluated. Calling any of the setter methods will not trigger the evaluation, but they will m_Evaluated to false. When the getter methods are called. They will re-evaluate the final transformation matrix only if it’s been previous modified.

There are no methods such as TranslateFromCurrentPos or RotateFromCurrentAngle at the moment because I believed those should be implemented in a entity class which will compose one or multiple TransformationMatrix in the render component. This will allow me to implement higher level movement stuff on top while keeping the matrix class lightweight and encapsulated.

Here’s the cpp part of the class:

const glm::mat4 TransformationMatrix::sk_IdentityMatrix(1);

TransformationMatrix::TransformationMatrix(void)
	: m_ScaleMatrix(sk_IdentityMatrix)
	, m_RotationMatrix(sk_IdentityMatrix)
	, m_TranslationMatrix(sk_IdentityMatrix)
	, m_Evaluated(false)
{
	glm::value_ptr(m_FinalMatrix);

}

TransformationMatrix & TransformationMatrix::SetScale(const float p_ScaleX, const float p_ScaleY, const float p_ScaleZ)
{
	m_ScaleMatrix = glm::scale(p_ScaleX, p_ScaleY, p_ScaleZ); m_Evaluated = false; return *this;
}

TransformationMatrix & TransformationMatrix::SetRotation(const float p_AngleX, const float p_AngleY, const float p_AngleZ)
{
	m_Evaluated = false;
	m_RotationMatrix = glm::rotate(sk_IdentityMatrix, p_AngleX, glm::vec3(1, 0, 0));
	m_RotationMatrix = glm::rotate(m_RotationMatrix, p_AngleY, glm::vec3(0, 1, 0));
	m_RotationMatrix = glm::rotate(m_RotationMatrix, p_AngleZ, glm::vec3(0, 0, 1));
	return *this;
}

TransformationMatrix & TransformationMatrix::SetTranslation(const float p_PosX, const float p_PosY, const float p_PosZ)
{
	m_TranslationMatrix = glm::translate(p_PosX, p_PosY, p_PosZ); m_Evaluated = false; return *this;
}


const GLfloat * const TransformationMatrix::GetRawPtr(void)
{
	this->Evaluate();
	return glm::value_ptr(m_FinalMatrix);
}

const glm::mat4 & TransformationMatrix::GetGLMMatrix(void)
{
	this->Evaluate();
	return m_FinalMatrix;
}

TransformationMatrix & TransformationMatrix::Evaluate(void)
{
	if (!m_Evaluated)
	{
		m_FinalMatrix = m_TranslationMatrix * m_RotationMatrix * m_ScaleMatrix;
		m_Evaluated = true;
	}
	return *this;
}

Of course. The class is incomplete. I will overload some operators for matrix multiplication and what not. At the moment I have to call “GetGLMMatrix()” to pass the matrix to my ShaderProgram class. I will need to add support for this new class into my shader code.

I will begin work on a camera class next, once I’m up to date with this week’s lab work.