the Fiddler's picture

The Open Toolkit demo, stage 1: brainstorming

Project:The Open Toolkit demo

With 1.0 beta-1 out of the door, it is time to open the discussion on the OpenTK demo.

Why do we even need a demo?
In my opinion, a demo is useful for three main reasons:

  1. to attract attention and sell the features of the library
  2. to provide a concrete application as a reference for users and as a test case for the library itself
  3. to act as an experimental testbed, where new features must prove themselves before becoming part of the core library

There are other reasons for creating a demo application, but the bottom line is that this will be beneficial for both users and developers of OpenTK.

What will the demo contain?
This is ultimately up to the community to decide. A few rough ideas to get us started:

  • it should be possible to implement in a reasonable time frame
  • light on artwork, to avoid large downloads (can it fit in 10MB?)
  • (related to the above) procedural generation for graphics?
  • scalable to older hardware (to the extent possible)
  • it should be something interesting, i.e. something more than "yet-another-parallax-demo"

What could fit inside those constraints?

One idea: split-screen, 2-player deathmatch. Each player controls an aircraft and tries to shoot down his opponent. Can take advantage of simple physics and procedural terrain generation. Relatively simple to implement.

Other ideas?

Can I help with the demo?
Glad you asked! The first step is to decide what the demo will be (brainstorm!) The second step is to define with a very rough design document (which features it will include and which features it will not include). The final step is to implement this.

This topic is about the first step, so share your ideas!

Where can I get the source code?
Once the code becomes more mature, proper packages will be made available. Until then:

  1. Install an IDE (Visual Studio 2008 Express Edition, MonoDevelop 2.0 & 2.2 and SharpDevelop 3.0 are all fine. Higher versions will work, too.)
  2. Install git (Windows, Mac OS X, or "sudo apt-get install git-core" for Ubuntu).
  3. Run git clone git:// from a terminal, or from the git gui (on Windows, right click a folder and select "Git GUI here").
  4. Open Demo.sln and hack at will!
  5. git commit -a . to commit your changes to your local branch (or click the "commit" button in Visual Studio).

It will immediately become obvious that the code is currently pre-alpha quality. It contains an incomplete but usable graphics abstraction layer, as well as a working fractal terrain generator (if you know how to perform correct normal mapping on terrain, please drop a hint!)


Comment viewing options

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


Version:<none>» 1.x-dev

Sounds like a great idea. And like to help out where ever possible.

I have not had a look at the source so far yet, but will do that when I'm back at home. For now I can help with some brainstorming. These are some first comments/questions that come to mind.

  • Things I really like about the ATI demos is the different modes / overlays. Simple example if this would be an overlay where one can see intemediate renderpasses (like I did in the geometryshader example) or a stereo view mode. Turning on and off lighting, parallax etc.
  • Procedural assets: A simple texture generator isn't all that hard using GLSL and this can save lots of distribution size. Other than simple geometry primitives I'm not familiar with geometry generation. How far do you want to take generation?
  • Should it be interactive?
  • What hardware (class) do we target? What extensions can we use?
  • What about music?
Inertia's picture


Does the demo have to be fully interactive as in a game, or would it be sufficient if it's more like a effect demo that has "scene selection" as the only interactive part, but may run without any user interaction?

VeliV's picture


Good thing would be if the code within the demo would be newbie friendly :P So add lots and lots of comments there!

the Fiddler's picture


Some food for thought here, thanks.

I'd suggest focusing on the concept first, rather than implementation details. In my experience, the technical aspects of a project tend to become much clearer once its goal is crystallized.

Interactivity: this is a very good question. What are your thoughts on this? Imagine you are a new user clicking on red "demo" button at the frontpage: would you expect a game world (in the widest sense) you can explore yourself or would you prefer a demonstration you can sit back and enjoy?

Music: this is a rather difficult issue. My suggestion is to follow an iterative approach as in: no music/sound -> only sound effects -> sound effects and music.

This be significantly easier if we could decompress OGG files. I don't want to derail this thread with too many technical details, but the ultimate solution is a port of stb_vorbis to C# (check OpenTK.Audio project in the demo repository).

Of course there's the matter of actually composing the music. I volunteer myself for this (with help from everyone interested).

Code comments: at the very least, we should follow standard commenting practices and make the intent of the code clear. Should we take this one step higher and turn the demo into a tutorial or should we leave that to Examples.exe?

Procedural assets: simple geometrical shapes have a surprising amount of uses and simple fractal terrain can look pretty good with relatively little effort. I've never tried to generate textures procedurally - what kind of uses can they cover?

Overlays: they are very useful for any non-trivial 3d project. It's a keeper, I think (we can think about the exact implementation after the brainstorming session).

Hardware: no need to get too technical right now. This can be rephrased as: do we wish to support netbooks?

pokemoen's picture


Regarding procedural textures I like the following concept:

See these textures as a set of operations that are executed in order. Imagine drawing a texture using your favorite imaging software, you wouldn't store the pixels but rather all actions preformed to come to this image. This looks much like the undo history list in photoshop for example. This list is basicly your set of operations and the data needed at each step.

Drawing primatives like lines, quads, circles and text are examples of render operations. Each of these operations will use data like linewitdh, position, size and color. Then there are filter operations that look like your regular blend/post effects: blur, framebuffer blend modes, emboss etc. You could even have operations that have already rendered textures as data, so you could do "layer" operations like multiply, color burn, screen etc.

You'd basicly render all these operations in order to a FBO and then you have your texture.

Apart from the size of the compiled code to render these textures, the storage size of the data for these textures could each be a couple hundred bytes to a few kilobytes at most, uncompressed.

An other approach could be to implement texture generation in a shader that is active while rendering, as opposed to pre-calculating in FBO's. An example of this can be found in the OpenGL Shading Language book (orange book), a hatching shader I think it was.

flopoloco's picture


Let's have a look...

Demos for Eye
Are very important because I think they will be used for promotion mostly, whoever makes a reference on OpenTK in his website will grab a screenshot.
- It's very important to pay special attention to light (lighting can make your scene look totally better)

Example of a boring tunnel that looks great due to lighting!

- I am not a shader specialist, but HDR[1][2] and simple spherical harmonics[2] could give us amazing effects.

Deferred Rendering[image] (PaulsProjects rock, good information)

Blender game engine has some cool GLSL demos and quality free models

- Temple with shadows and parallax mapping (very mysterious)

Perhaps it needs some work on real time shadows

Parallax Occlusion Shader is way better than simple parallax mapping

Demos for Features
Developers of OpenTK I guess are possibly proud for OpenTK, but they are specific reasons. There's a chance to show the world what is going on and OpenTK rocks!
- This font rendering feature is cool, it could simulate the Matrix code easily.
- Probably a benchmark of OpenGL calls in milliseconds.

[] Demos just for fun
-- Procedural experiments (I like the starwars-type canyon) but simply for a fly-through. OK, perhaps with some twist can turn into an old-school shooter (shoot until you loose) where level is generated in realtime and enemy swarms are unpredictable and random.

-- A very simple multiplayer shoot em up (you open the program, you connect to an IP, you respawn, you shoot, you die, you respawn...)... The real challenge is to make it look nice (I bet all the source from the eye candy section will come handy).

P.S. I hope these will help, technically there are some interesting stuff to show. But for any specific reason nice models can be used also (the Blender community is very open generally as a philosophy so we can expect some amazing stuff if we notify them)

if you guys analyze this information and prioritize some tasks but number, make a new thread with details so volunteers can join.

Inertia's picture


[Game vs. Demo]
One big problem with games is, that they usually fall into 1-2 genres. People may like the genres (or the combination of them) or not. Even if they like the genre, there is a wide gap between Simulation<---------->Action. The game needs to be placed somewhere inbetween those extremes and it is guaranteed that you'll get alot of both: "it should be more realistic" and "it is too realistic".
Another problem with games is the desired difficulty and challenge by the player. Even for the same player this may vary alot, depending on moods. This makes it very random how well the game is received.
The idea with the flight simulation is achievable and sane, but it is very hard to hit the sweet spot where a game becomes real fun and pleases the greatest number of players.

An "effect show" makes these problems irrelevant, the only interactive part would be a scene selection which should be so easy to navigate that you can train your cat to use it. The game would in essence only contain one scene the player views at all times (cockpit), while a demo will contain dozens of different scenes. Even if the viewer dislikes some of the scenes, there are other scenes to compensate.

What I had in mind was something similar to this demo, it does not contain scene selection but the music and flow of the presentation are rather good:

Mind this is from 1995 and therefore not quite state of the art, but it gives a direction where we could be heading. Small plates will occasionally scroll into the scene and name the effect that is currently shown. This could be pushed even further by using some form of scrolltext to describe in more detail what's special about the shown effect.

I'll stop at this point and spare you pages of rant about this topic. At least until it is decided what we're going to do. :P

[Demo Style]
Looking back at the difficulty to get a logo for the web page, I would not be too optimistic about customized art for the demo. There's quite a few free-3D-models websites out there, but the models vary wildly in style, technical quality (may have TexCoords. may not. may contain serious errors that need to be fixed) and varying resolutions/detail. I'm not saying to avoid those free models, just warning not to go crazy about them because they usually come with a catch.

I'd like to suggest to use "programmer art" (functions, fractals, stock photos) as much as possible. In game development there's like 10 artists for every 1 programmer, and we simply do not have this at our disposal so any AAA-alike game idea can be dropped without reading it.

[Demo Size]
Something around 10-20MB (.zip'ed) is very acceptable looking at today's network bandwidth. 3D Models and also .dds textures compress rather good, this should be our smallest concern.

Supporting Intel means no GLSL, or doing a second codepath. I'd prefer a single codepath and a "Sorry, next time buy a real computer." messagebox.
The later DirectX 9 cards are already very powerful, but DirectX 10 are so cheap these days that you get a coupon for one in a box of cereal. I'd like to suggest to target the slowest DX10 cards we can find, the demo must run at least at 1024x768x32bpp 60fps at all times on them. Depending on how much we can do procedurally, it may be an option to do a "high res" version of the demo that has sufficient geometric detail to satisfy whatever resolutions come next after HDTV.

Another possibility could be recreating a CG rendered sequence from a movie or TV show in realtime, like flopoloco hinted with the star wars canyon flight. Some good candidate would be the intro sequence from the Star Trek: Voyager TV series (would be very easy to obtain 3D models for this), or something from a Pixar or Dreamworks movie. Pretty much any Sci-Fi TV series or movie is a potential candidate (where it's not all about human actors).

Idk whether this is too geeky, just wanted to mention it because this may be impressive aswell and may be known to the viewer, so there's something they can compare it to. The usual "effect show" demos can be alien to viewers unfamiliar with the background.

E.g. this is recorded from a 4kb executable:

Edit: Here's the Voyager intro:

Edit2: Bleh, this was already done in the Star Trek: Voyager Elite Force game:

Inertia's picture


So far we got 3 different directions:

a) small game (interactive)
b) effect slideshow
c) offline CG remake in realtime

Why do we even need a demo?
1. to attract attention and sell the features of the library
Option c) might be the one that serves this goal best. "Did you see? you can do that with OpenTK!"

2. to provide a concrete application as a reference for users and as a test case for the library itself
Option a) serves this goal best. A game demo will touch most relevant topics.

3. to act as an experimental testbed, where new features must prove themselves before becoming part of the core library
Option b) serves this best. Since the effect show is just a collection of unconnected scenes, it would be easy to add more scenes.

flopoloco's picture


OK, let's see an other idea. What mood is best suited for demos?

1. Make a simple action game for communication purposes.
Benefits for developers: All features we want to show are combined into a single application. Games are good for stress-testing a system (and OpenGL programmers or gamers have strong PCs). Also keep in mind that time is on our side, by late 2010 OpenTK will be very mature and stable, 8-core CPUs will start making their appearance...
Impact: Good enough to shake the waters ;)

2. Make a gallery demo
Benefits for developers: Just like Ogre3D or Irrlicht, it's not something special but very handy for tutoring (how do I load a model? how do I load a shader?) and precise demonstration of simple stuff.

I would vote for a simple action and fun multiplayer game using UDP sockets (First Person Shooter or maybe Airplane wars just like Fiddler says). Simulation and realism, will not be in need because it will be a practical example, just pure old school gameplay.

Better 5 in hand than waiting for 10 (in a manner of speech)... Either someone makes a fractal or fluids or deferred rendering won't hurt no one, there are tons of samples needed to be ported to OpenTK. (By example CS-SDL actually ported crucial OpenGL samples of Nehe, Mesa, RedBook e.t.c.)

iliak's picture



What I had in mind was something similar to this demo, it does not contain scene selection but the music and flow of the presentation are rather good:

I really *love* the little text explaining the current effect, it's a nice feature !