Inertia's picture

Tutorials Wishlist

This is a gathering topic for recommendations/requests/contributions of OpenTK Tutorials that should be added. Please keep this sane (noone will port Quake III's source code for a tutorial) and be verbose what the tutorial should achieve, i.e. with that knowledge the reader should end up with after reading the source code.

There's no limit how small or big the tutorial should be, but some things need to be part of a larger tutorial (e.g. load a texture and draw a textured quad - makes little sense separated)

Also note that the tutorials on this list will not necessarily be finished tomorrow, it's more a list of feedback from users to get an idea what is missing and which areas require improvements. Posts like "I second [name]'s suggestion" are very welcome too, as this helps to set priorities! Thank you :)

Free your mind ...

Edit: this topic isn't much for discussion of the suggestion's details, so don't be confused if you get no reply. All suggestions will be read and considered.

Don't be afraid to add wishes that might sound trivial or stupid, the tutorials are supposed to help beginners get a good start with OpenTK and without you voicing the problems there cannot be done anything about this.


Comment viewing options

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

Interesting suggestions, hadn't considered these before. :)

As Mincus said, there's a line we need to draw somewhere between the "necessary" and the "nice, but beyond our scope" tutorials. For example, for OpenGL topics you can refer to the Red Book (available online), the OpenGL SDK, online tutorials etc. Our tutorials only need to show how to transfer this knowledge to OpenTK ("necessary" category) - everything else should fall on the "beyond our scope" category. This doesn't mean that we won't add such material to the manual, if someone takes the time to write it, but rather that we wouldn't spend much time on this ourselves. :)

In this light, getting the amount of physical memory does fall outside the scope of OpenTK. Fortunately, this is a topic covered on MSDN page and by onlie tutorials. (These links point to System.Diagnostics.PerformanceCounters, which should be supported on Mono.)

Audio input on the other hand (microphone/line in) is "necessary" material, in part because OpenTK will provide support through a "CaptureDevice" class and in part because the existing documentation is not clear enough (judging from the OpenAL mailing list).

Mincus's picture

Going a bit off topic now with this, but had a look at the performance counter stuff.
2 things: Neither the Microsoft.VisualBasic.Devices.ComputerInfo or the PerformanceCounter seem to be implemented in Mono (at least not in 1.2.4, will check in 1.2.6 later).
To get the system RAM with the PerformanceCounter under Vista you require administrator access, which obviously isn't something you want to force on users. The VisualBasic object doesn't require this.

I also note the PerformanceCounter only gives the currently available, not the total RAM (VisualBasic gives both) and seems to use an additional 4-5MB of memory under Vista. :o/

Anyway, I've dropped the code here if anyone wants a look.

the Fiddler's picture

Thanks for investigating. Checking the source in Mono, confirms that these aren't implemented (ComputerInfo and PerformanceCounters).

It looks as if there is not way to get this info in a cross-platform manner...

Inertia's picture

System.Environment.WorkingSet returns the total available RAM allocated for the process of your app, while System.GC.GetTotalMemory() returns the amount of allocated memory known to the GC inside the app. Don't quote me on this though, never ran into any memory problems so far and kinda trusted in Fiddlers 'marketing promise' that the limitation is 1GB RAM or more (~4GB in 32-Bit OS, a number larger than I can count for 64-Bit) ;)

I totally agree with that question being out of the scope of OpenTK's manual (or "book"), but ofcourse they can be asked in the forums.

[audio capture]
The OpenAL 1.1 SDK contains a sample how to capture audio data and save it into a .wav file, however it did not use Alut functions, but a custom .wav writer for this. I didn't port that library and the example, but you can take a look at the SDK, the file is /samples/capture/source/capture.cpp
I'll cite some pieces from the sample:

// Open the default Capture device to record a 22050Hz 16bit Mono Stream using an internal buffer
// of BUFFERSIZE Samples (== BUFFERSIZE * 2 bytes)
pCaptureDevice = alcCaptureOpenDevice(szDefaultCaptureDevice, 22050, AL_FORMAT_MONO16, BUFFERSIZE);
// Start audio capture
// give it time to record something from the mic
// Stop capture
// Find out how many samples have been captured
alcGetIntegerv(pCaptureDevice, ALC_CAPTURE_SAMPLES, 1, &iSamplesAvailable);
// Consume Samples
alcCaptureSamples(pCaptureDevice, Buffer, BUFFERSIZE / sWaveHeader.wfex.nBlockAlign);
// Close the Capture Device

Needless to say, this won't compile and does 0 errorchecks, but should give an idea what commands are involved. The functions are all available in OpenTK and it should be possible to AL.Bufferdata what you recorded to play it back. (The above commands are not resembling the program from the SDK.)

Edit: Mincus request has been done as a dynamic VBO example showing a possible implementation, will be in 0.9.1. (Google shows 50k+ particle system tutorial related pages)

LikeTK's picture

I wonder if this is a difficult topic as I have a hard time looking for examples done in c# to help me to jump-start trying how to use it.

the Fiddler's picture

Err, which topic?

For sound capture, check the Parrot sample in the OpenTK examples.

LikeTK's picture

Sorry for being unclear. I am trying to learn volume texture loader and I found the only reference in the OpenTK examples:

under the Examples/Utilities folder, there is a LoaderDDS.cs
Line 453
case TextureTarget.Texture3D:

I am hoping for someone to share a tutorial.

13.2 3D Texture Volume Rendering

Example of a 3D texture dds format found

Inertia's picture

IIRC s3tc does not allow compressed 3D textures and our .dds loader exclusively supports compressed textures (for the simple reason that uncompressed textures are better served with easily-editable formats like .bmp .png etc.). However the loader has parts of the logic to handle uncompressed textures present already (it interprets all flags from the .dds header) so this functionality could be added. To handle 3D textures, search the file for "depth" and "volume" keywords. In essence a 3D texture is just an array of 2D ones, depth determines the number of slices. The final code will look much like processing cube maps.
(Disclaimer: The loader was written 2-3 years ago, so this information may not be perfectly accurate anymore.)

I cannot help you with tutorials, (insert name of your favorite search engine here) can. All I used to write the loader was MSDN .dds specification and Nvidia's OpenGL SDK for the bit-pushing when flipping a DXT5 block upside down.

What tool are you using to gather the data? and what tool to write them (or convert to) in .dds format?