r3dux.org

Physics simulations are always interesting, and this one is probably the best liquid sim I’ve ever seen, all running live on a top-end NVidia GPU:

You can read the paper about how it all works here, if you’d like. I don’t think NVidia are gonna hand out the source code, but they’re likely to incorporate it somewhere in the next PhysX release.

I’ve been reading about Vim and Emacs, how they differ, and which is best. As far as I can make out the major difference is that Emacs uses Control-key-combinations (Ctrl+F, Esc+W etc.) to activate functions, while Vim uses modes and single key sequences, that is, you don’t generally have to hold one key and then press another – except when entering the colon symbol, which itself is used to change modes…

I think I’ll give them both a try and see which one I get on with the best – although I read that’s probably going to be Emacs because Ctrl+[some-key] combinations are the norm, while changing modes takes more getting used to, but is eventually faster (eventually, when you finally wrap your head around it and think in Russian!). We’ll see =D

Sometimes I end up needing to do this, so I re-implement the functionality… And it segfaults or behaves strangely. This time I’ll write it down somewhere I know where I can find it!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69

#include <iostream>
#include <string>
#include <vector>
 
using namespace std;
 
int main()
{
	// Create an empty vector of type string for our shopping list
	vector<string> shoppingList;
 
	// Add a few items to it
	shoppingList.push_back("Milk");
	shoppingList.push_back("Bread");
	shoppingList.push_back("Eggs");
 
	// Create an empty vector of type string for our purchases
	vector<string> purchases;
 
	// Create a string to hold the user's answer
	string answer;
 
	// Transfer items bought from the shopping list to the purchases list (includes removal from the shoppingList vector)
	vector<string>::iterator i = shoppingList.begin();
	while (i != shoppingList.end() )
	{
		cout << "Item: " << *i << endl;
		cout << "Purchase item? (y/n)" << endl;
 
		cin >> answer;
 
		// If we said yes...
		if (answer == "y")
		{
			// ...add the item to the purchases vector and...
			purchases.push_back(*i);
 
			// ...remove the item from the shoppingList vector. Erase returns an
			// iterator which points at the next element in the vector, so we need to
			// skip incrementing the iterator in this case or we might go out of bounds!
			i = shoppingList.erase(i);
		}
		else // Otherwise just move on to the next item!
		{
			i++;
		}
	}
 
	cout << endl;
 
	// Display both lists
	cout << "----- Shopping List ----" << endl;
	for (i = shoppingList.begin(); i != shoppingList.end(); i++)
	{
		cout << *i << endl;
	}
 
	cout << endl;
 
	cout << "----- Purchases ----" << endl;
	for (i = purchases.begin(); i != purchases.end(); i++)
	{
		cout << *i << endl;
	}
 
	cout << endl;
 
	return 0;
}

TLTB

I was recently asked about some particle systems I’d put together, so in response, this isn’t really a “look what I’ve coded” post – instead, it’s more of a “this is an easy way to set up a particle system framework” post.

To demonstrate the setup of a particle system using OpenGL, I’ve put together some simple starter code which displays a 2D particle fountain. I was going to just dump this code as a zipped project into a reply, but then (as my wife pointed out) it would be pretty much buried in the comments, so if other people starting OpenGL coding wanted to learn the basics of particle systems my code wouldn’t be as visible. As such, I’ve made this into a separate post – and all our example code does is this:

It’s a dirt-simple effect, but what it does isn’t so important right now – it’s deliberately simple. How it does what it does is what we’ll talk about.

Looking at particle systems from a high level – you generally have to choose between two different approaches to the system as a whole:

1. You have a fixed number of particles (i.e. you have a fixed size array of however many particles) and you reset each particle to “recycle” it, or
2. You have a dynamic number of particles (i.e. you have a dynamically resizable array) and you destroy each particle and create a new one as required.

I’ve gone with the latter approach for this code using a vector of particles (nothing to do with Vec2/Vec3 math – just the name of resizable array kinda construct). Admittedly, there’s more overhead in the creation and destruction of particles, but on the upside you don’t get that initial rush of particles you get when using fixed size arrays and as soon as you start the program BLAM! All your particles going at once.

To demonstrate what I mean, in the video below I’ve modified the code to instantiate ALL particles up to the particle limit at once, and then as soon as a particle goes off the bottom of the screen it gets destroyed and a new particle is created. The effect of which is that you get a single big burst of particles, and then as they all get destroyed and recreated at different times they turn into a smooth flow within a couple of seconds:

If you’re using a fixed size particle array, you’ll need to implement some mechanism to delay the instantiation or “launch” of the particles – for example, you might give each particle a random framesUntilLaunch value and decrease it by 1 each frame until it gets to 0 and you can let the particle do its thing. I wrote such a delay system for some fireworks code I did a while back if you’d like to see a concrete example.

Anyways, back at this code, our main is using three main classes to encapsulate data and provide methods to manipulate it:

• Colour4f.hpp – A class to store a colour as red/green/blue/alpha floating point values and manipulate ‘em (including interpolation of colours),
• Vec2.hpp – A templatised class to store two values as a vector (Not a resizable array this time! An actually “euclidian vector” – i.e. two values which represent a direction and magnitude). It also includes lots of overloaded operators so you can add two vectors together (“up” + “right” gives you “up-right” etc.), multiply a vector by a scalar (i.e. moving “up-right” multiplied by 10 means you’re now moving up-right ten times as fast). By templatised, I mean that you can create a Vec2 of ints, or floats, or doubles, or shorts, or whatever numeric type makes sense for your application – take a look at the source below if you want examples, and finally
• Particle2D.hpp – A particle class which uses the above Colour4f and Vec2 classes to provide powerful movement and colour modification options in a small & easy to use package.

You can download the complete source code as a Code::Blocks project here, if you’d like: PointSprite_Particle_Fountain_2D.zip.

Note: As my OS of choice is GNU/Linux (LMDE, to be specific), the source files provided will have Linux line-endings – so you’ll need to open them with a good text editor like Notepad++ if you’re in in Windows, otherwise each file will look like a single massive block of noise!

Or, if you’d prefer to just browse the source code so you can copy and paste sections, you’ll find it all laid out below.

I love particle systems – you can do some visually stunning things with really simple code, or you can do amazing things if you take it further. Either way, I hope you have a lot of fun with them (there’s lots more particle stuff on this site if you’re looking for inspiration – try Actionscript tag for a start!) – and if you make anything cool or pretty using and you think I’ve helped – please do show me or let me know – I’ve love to see or hear about what you’ve done! =D

Also – if you make this – show me how, okay?

Cheers!

Read the rest of this entry »

I thought the particles would look nicer being coloured as an interpolation of the colours of the waypoints they’re travelling between…

And you know what? I’m thinking I was right!