flopoloco's picture

The OpenTK Framework

I would be interested to start working on an application framework called OpenTK Framework that will allow users to create games/simulations/graphics extremely fast and easy. This OpenTK Framework will wrap common functionality in order to provide a layer of abstractness to the user when programming 3D. Because it will be easy to use, thus it will enhance creativity and productivity.

By using the OpenTK Framework each developer can focus in the field he is really interested in:
* A physics developer can simulate his fluid dynamics without paying attention to his graphics code at all!!!
* A network developer can visualize the packets and network traffic with remarkable easiness.
* A game developer can focus on the game play mechanics (making even better and enjoyable games) rather focusing on the WOW factor
(NOTE: OpenTK Framework will be WOW-factor compatible, as long as there are good shaders loaded in it)

A use case scenario follows (outdated - a more Object Oriented API will implemented) :

// How to create a romantic moonlight scene with the exact parts (boat, sea, sky, stars and moon)
 
using System;
using OpenTK;
using OpenTK.Input;
using OpenTKFramework;
 
namespace OpenTKFrameworkGameTest
{
	class Game : GameWindow
	{
		Entity camera, moon, ship, skybox, sea;
		Entity [] star = new Entity[100];
 
		public Game()
		{
			// Create a skybox
			Entity skybox = CreateBox();
			EntityScale(skybox , 100, 100, 100);
			EntityFlip(skybox); // Flip normals
			EntityTexture(skybox, "media/textures/nightsky.jpg");
 
			// Create a camera
			Entity camera = CreateCamera();
			EntityParent(camera, skybox, ParentingRelation.Positional); // skybox will be the child node of camera in positional manners.
			EntityPosition(camera, 500, 10, 200);
			EntityRotate(camera, -40, 0, 0); // sky box is not rotated
			EntityColor(camera, 0, 0, 0); // Set the clearing color of screen
			EntityShader(camera, "media/shaders/bloomfilter.glsl");
			EntityShader(camera, "media/shaders/hdrfilter.glsl"); // Post production filters can be combined
 
			// Create the moon
			Entity moon = CreateSphere();
			EntityPosition(moon, 200, 600, 200);
			EntityScale(moon, 10, 10, 10);
			EntityTexture(moon, "media/textures/moon.jpg");
			EntityShader(moon, ShadingStyle.Flat); // Use some of the already existing basic shaders.
 
			// Create a ship
			ship = LoadModel("media/models/ship/ship.x");
			EntityTexture(ship, "media/models/ship/ship.dds");
 
			// Create stars
			for (int i = 0; i <= 99; i++)
			{
				star[i] = CreateSphere();
				EntityPosition(star[i], Random(-500.0, 500.0), 800.0, Random(-500.0, 500.0));
				byte starColor = Random(0, 255);
				EntityColor(star[i], starColor, starColor, starColor);
			}
 
			// Create sea
			sea = CreatePlane();
			EntityRotation(sea, 90, 0, 0);
			EntityScale(sea, 1000, 0, 1000);
			EntityShader(sea , "media/shaders/realistic_water.glsl");
		}
 
		// Give simple movement to the ship
		public override void OnUpdateFrame(UpdateFrameEventArgs e)
		{
			base.OnUpdateFrame(e);
 
			if (Keyboard[Key.Up])
				EntityTranslate(ship, 0, 0, 1);
			if (Keyboard[Key.Down])
				EntityTranslate(ship, 0, 0, -1);
			if (Keyboard[Key.Left])
				EntityRotate(ship, 0, -1, 0);
			if (Keyboard[Key.Right])
				EntityRotate(ship, 0,  1, 0);
 
			if (Keyboard[Key.Escape])
				Exit();
		}
 
		public static void Main(string[] args)
		{
			Game game = new Game();
			game.Run(30.0);
		}
	}
}

That was 100% C# and 100% OpenToolkit!!! Isn't that great?


Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
objarni's picture
Inertia's picture

I think building a Framework ontop of OpenTK is a good idea (and from my point of view there's no objection labeling it OpenTK Framework). The big advantage you have compared to XNA would be, that you can still use vanilla OpenTK together with the Framework to use experimental extensions, i.e. functionality that is not yet wrapped into OO classes.

My only concern about your proposal is that you are not mentioning Deferred Shading in any way. It is the reason why I'm writing my game from scratch, because all examined existing engines favor classic forward shading over deferred. Separating the drawing of geometry from lighting has a big advantage for C# too, because the step of determining which lights affect which model becomes obsolete for opaque geometry and you save alot of calls switching buffers, shaders, uniforms.

Mincus's picture

I think overall it's a good plan.
However objarni's article raises a good warning: Don't specialise too much.
I'd add that it might be best to make a more lightweight framework rather than a full engine, the reason being that OpenTK already provides a significant portion of the requirements for writing a game in its GameWindow class and too heavy a framework would overshadow the good work done there.

Also the code you've written looks very C-esque, lacking OO. I assume it's just an example but it would make more sense to wrap a lot of the functionality you've shown in the Entity base class using skybox.Scale() and skybox.Texture() instead.

flopoloco's picture

Thanks for the answers, feedback is much appreciated. :)

Inertia's picture

I've been thinking about this, and what I believe is the key to make this work is a Material&Shader IDE. Every content creation tool has it's own concept of a material, which is totally not what OpenGL expects. The IDE would ideally allow create, edit, preview, save and load materials (aka. shader parameters) and the shader itself, which then can be used in the Framework.

Key problems to abstract for this are:

  1. Vertex Attribs supplied by the geometry.
  2. Uniforms i.e. Vectors, Matrices, Samplers, Arrays of those 3, Bindable Uniforms.
  3. Shader Pair. Ideally the abstraction will not care whether the Shader is GLSL, Assembly or Cg - as long as the language is consistent within the pair.

The fluffy-dreamy-pink-clouds solution would be if the IDE also allows geometry manipulation - such as Golem3D - so artists can work in a WYSIWYG environment and view all changes directly.

...or do you guys think this IDE rather belongs into the engine department?

JTalton's picture

I am planning on adding material support to Golem, but I have not had time to flush out what that will exactly be. I would be interested in hearing thoughts on the subject.

Inertia's picture

It might be best to create a new topic for that discussion, will do that after sorting out where to start.

I've simply named Golem3D because it is known here. Such editors usually have gizmos or other tools to place and manipulate lights and geometry, which is something I really miss in Rendermonkey. Especially after extruding, welding or performing boolean operations on meshes, normals are messed up which is where a geometry editor would be very handy.

flopoloco's picture

Hey Mr. Inertia, thanks for bringing up this old post ;-). Unfortunately, I have not made any progress yet (still thinking and planning)... One thing you mentioned and I just I also noticed (in the example), is that most commands went into scene graphing and lesser in application. So an editor would be a wise choice to use here.

For Golem3D, I think that real time shader materials are the best feature in a 3D application. Especially if you are able to "program" your own materials. :P I think also that Golem3D needs a framework like this one (if not already has one), this should be considered wise because you can merge the user interaction (buttons, menus) and scripting parsing parts under one umbrella, I don't know about the benefits of it, but it sure minimizes the costs (in code and risks) for scene management.

For example: when you click the create cube button in your GUI, you indeed call framework's CreateCube() method to do this. Also, same goes for scripts, you can propose all of the Golem3D API to script developers, keeping them high level, not messing with details.

for (int i = 1; i <= 100; i++)
{
CreateCube();
}

objarni's picture

flopocolo - I understand your will to create game engines / frameworks. But instead of thinking/planning for months - try to build small games. Which is more fun? Drawing class diagrams or building Tetris?

Your engine will emerge from the games you build. Trust me.

flopoloco's picture

Your point is right here... I still think I am in university ;-)