PDA

View Full Version : Particles and life



komodoDave
09-25-2006, 03:38 PM
LOL, that hammock pic of Tycho is the cutest :D Cool name for a cat btw. Does it originate from any real-world reference?

Congratulations to you four for creating this wonderful software. Kudos to Andy for the painting system; having done no image analysis algorithms yet, I wouldn't know where to begin with coding what you've produced. In this, the final year of my Computer Science course, I have to choose a project deemed sufficiently challenging to gain some margin of 15% of the year's marks going towards my degree. I have decided to produce some kind of (maybe medical) image analysis software, though I haven't yet decided on the specifics.

As a result of needing to gain insight into some generic algorithms used for analysing images, your painting system intrigues me greatly. Obviously I won't pry, because no doubt your system is a tightly-kept secret, but it is something I'll have to try and figure out over the next few months :P

Out of interest, what is ArtRage coded in? C/C++ ? I myself work mainly in Java, and am progressing nicely in Ruby, which I utterly love. Python galls me because of its forced whitespace and constant 'self' references, and also the fact that it's not completely object-oriented and consequentially has the unnecessary distinction between methods and functions.

I've also coded in Haskell (probably my favourite language), OCAML (can't stand it... like an OO rip-off of Haskell with poor syntax) and Oberon. I've yet to broach C/C++ - for the moment Java suffices.

Do each of you have your own language preferences? What IDE do you use for your language of choice? Any of you a VIM fan like myself? Any of you use linux?


dave.stopSpanishInquisition()

:D

....


.....*calls a taxi*

AndyRage
09-25-2006, 07:52 PM
KomodoDave, ArtRage is coded entirely in C++ (there are some very minor exceptions where we've been forced into using Objective C on the Mac, and generic C for some image API stuff)
We use Microsoft Development Studio 2005 on the PC, and Apple's XCode on the Mac.
We have our own UI and application toolkit (Goblin) that abstracts all of the platform-specific code, so the actual ArtRage application which sits on top of Goblin compiles unchanged on both the Mac and the PC.
Whever possible we avoid COM, multi-threading, .Net, or operating system dependence. As a result ArtRage is fast, small, monolithic and very easy to maintain.
If you're handy with Spy, you'll note there is only one window in ArtRage - the main window. Every UI element is managed by Goblin, which gives us enormous flexibility in doing our own UI object interactions.

The technology behind ArtRage is really all based around the oil tool - the most complex. The canvas stores physical properties of paint - in addition to colour there is volume, wetness and the like. Similarly the paint on the head of the tool has its properties. During the stroke the paint on the brush head reacts with the paint on the canvas just like in real life.
However we also avoid mathematics as much as possible, so a lot of what you see is the result of tricks and cheats that give the look you'd expect but not at the expense of the mathematics. (That's why I'll never ever be able to publish a Siggraph paper about my graphics code. It's all nasty cheaty code that offends intellectuals and cant be expressed in tidy formulae)

komodoDave
09-26-2006, 08:37 AM
Wow, thanks for the highly informative response there Andy :D

I just went and checked out your 'What's Goblin?' page after you mentioned it there - very cool, nice work. Have many people leased it from you, out of interest?

Surely it can only benefit you to introduce multi-threading? I mean, nearly every consumer pc out there being sold atm is dual core from what I see, and those like myself who build their own rigs are bound to go for 64 bit dual core (heck, I only paid 125 GBP for an Athlon64 X2 4200+, core clock 2.2Ghz, and can overclock it to a stable 2.7Ghz on each core using a Thermalright heatsink, making it 100Mhz faster and over 400 pounds cheaper than their 4800+). It's not like diskspace is at a premium, and the speed boost will surely offset any penalty incurred by loading an extra library or two? I understand that expanding your tool feature set is probably more important to you at the moment than adding things like multithreading, though.

Spy... wow.. haven't seen that lil' app in ages... handy isn't it :)

I had a huge 'aaaah!' moment when reading your outline of how the painting system works, lol. I also like the fact that you use 'tricks and cheats'. I'm currently developing a Jave Enterprise based applet for a money-making project a friend and I are working on - he's doing the PHP backend and looking into the business side of things, and I'm creating the entire site [information pages, messaging system, 'core' application] to be contained within my applet. The core application within it, which I can't reveal much about atm (very hush-hush :P) is essentially a fancy particle simulator. Currently I'm using raw calculations with simple trigonometry to predict particle positions, just for testing purposes, but once the rest of the applet is written I'm intending to switch to use a 'Treecode' algorithm presented by Piet & Hut.

Why do I mention this? Well, because for all their elaborate mathematical genius in producing this algorithm, they ultimately strive for the same goal you do when creating your 'tricks and cheats' - that is the optimal balance between speed and accuracy. When predicting particle positions using their system, the results are not spot-on by any means.. however, the speed increase produced by the algorithm [my trig method is O(n^2), their algorithm gives O(nlogn) complexity] is superb (since I intend to display 1000+ 'particles' ultimately), so the loss of detail is acceptable. I assume your tricks and cheats accomplish much the same thing :)

Pah, Siggraph papers? Overrated ;) No, they're great really; immensely useful in fact. It's just that I can't understand much of them at the moment... not that I ever really try :P I've only perused one or two, and they weren't my area of expertise (whatever that might be!).

Do you use Doxygen? Javadoc has sufficed for me thus far, but since you can use Doxygen for C/++, which I will eventually muster up the courage to learn, it would probably be beneficial for me to start using it soon...

Dave

AndyRage
09-26-2006, 10:53 AM
There are often 'gotchas' with multi-threading. Debugging can be a pain, threads can lock each other out, resources have to be managed carefully. We've used multi-threading in other applications where it makes sense, but haven't found the need to yet in ArtRage.
We haven't leased Goblin to anyone actually. We decided not to - we should probably change the web page about it!

With particle systems, be aware that generally (depending on what physics you're doing) particles have a discrete range of influence. If you divide your scene into a grid with a granularity of twice the distance of influence, and give each particle a grid reference, you only need to compare to other particles in your grid reference. And it's likely your grid block can only have a finite number of particles, so that reduces your interactions by many orders of magnitude. (Each grid block has an array referencing back to the particles. When a particle moves, you remove it from its old grid block and add it to your new.)
I dont know what the treecode algorithm is. Perhaps you can combine the two.

komodoDave
09-26-2006, 11:35 AM
Thanks very much for the particle system suggestion - from what I've read, the treecode algorithm is simply a more advanced grid system; it works on the principle that neigboring bodies have similar interaction lists. Basically you maintain an interaction list and then use each cell reference in the grid to winnow the possible interactions for each particle.. I haven't looked into the maths behind it much yet, but what I have seen looks a bit tricky.

Your grid suggestion is appealingly simple, yet there's something I don't get about it: how does it avoid particles from neighbouring cells converging on/near an edge and violently flinging apart once one particle has entered the other's cell? I suppose that's probably the accuracy sacrifice, isn't it... I think I'll have to have a threshold number of particles before which I use trig and after which I use your grid method or the treecode algorithm, because such extreme repulsions will be noticeably out of place when there are fewer than 50 particles on screen (the particles will cover most of the browser window).

Dave

AndyRage
09-26-2006, 07:29 PM
Ah, that's easy. You either a) test neighbouring grid cells, or b) have the grid cells overlap such that one particle can occupy up to four grid cells.

komodoDave
09-26-2006, 08:13 PM
Hehe, but of course. Thing is though, if you test neighboring cells then you only need the square cell dimension to be the influence distance, don't you? Because if you're testing neighboring cells then you need only ensure the worse case scenario (i.e. where a node is as close to its cell edge as possible) still takes into account all influenced/ing nodes. Although if you do the overlap method then your 'twice the influence distance' still stands.

I didn't think of your overlapping method, but did think of the neighbour-testing, so I couldn't understand why your cell dimension was twice the influence distance. :wink: I realise that the two methods are equivalent when put into practise.

I wish I knew you in real life; you seem like the sort of person I'd love to regularly chat to and bounce coding ideas off :P

AndyRage
09-26-2006, 09:21 PM
Exactly. If you make the dimension of the cell greater than or equal to the maximum influence of your particle, you only need to test the 8 surrounding neighbours.
Of course, if you're doing weak-field interactions of infinite distance, you need to get a bit cleverer. What you can then do is sum the influences in a cell, and for your far-distant particles they only need to test against the cell sum, rather than each particle in the cell. That comes in handy if you want to simulate every particle in the universe. ;)

Here's a cunning observation from when I was geeking-out on 2D real-time fluid simulations... If the *only* particle interactions you're modelling are a) gravity, and b) elastic collision you'll discover something interesting. Create two types of particle: Particle A Coloured blue, with radius 'n' (radius refering to distance of interaction - it's 'shell'), and Particle B coloured green, with a different radius.
Make a few thousand of each particle in random (but not overlapping!) positions inside a constrained space. Run your simulation for a while. You will probably discover that without any other influencing factors, the particles separate into two regions. The ones with the smaller radius sink to the bottom, the ones with the larger radius float to the top.
I mean, in retrospect, it seems kindof intuitive, but to see a complex reaction (the separation of two dissimilar liquids) occur with such a very simple rule-set really excited me at the time. I felt I was on the verge of discovering some cosmic fundamental law.
Then I got bored with particle simulations and moved on to something else. ;)
If when you render your particles in 2D with a gaussian falloff larger than their 'shell' and threshold the sum of the interacting gaussians (eg, meta-ball style (which you can just do by dumping a 2D greyscale bitmap of a soft airbrush-type dab onto the particle location, sum with whatever is there, and do a 'final pass' to cull everything below 50%, tweak everything above)) you get a really lovely continuous liquid surface.
Throw in a third force of weak attraction at the radius of the gaussian, and you get surface-tension on your liquid.
Then you add in some refractive rendering based on particle density, put some obstacles and pysical object interactions with puzzly goodness and goals, package it as an exciting game, make several million dollars, and give me a great wodge of cash for the help.

komodoDave
09-26-2006, 09:54 PM
Of course, if you're doing weak-field interactions of infinite distance, you need to get a bit cleverer. What you can then do is sum the influences in a cell, and for your far-distant particles they only need to test against the cell sum, rather than each particle in the cell. That comes in handy if you want to simulate every particle in the universe. ;)

Well the CRAY supercomputers can only simulate STARS in a limited-size universe, so no matter how hard I try to overclock my cpu... lol. It's clever, what you suggest; having (sadly) not done much physics I've never really encountered particle/stellar simulations, so such cunning tactics have not had chance to surface in my mind.


Here's a cunning observation from when I was geeking-out on 2D real-time fluid simulations... If the *only* particle interactions you're modelling are a) gravity, and b) elastic collision you'll discover something interesting. Create two types of particle: Particle A Coloured blue, with radius 'n' (radius refering to distance of interaction - it's 'shell'), and Particle B coloured green, with a different radius.
Make a few thousand of each particle in random (but not overlapping!) positions inside a constrained space. Run your simulation for a while. You will probably discover that without any other influencing factors, the particles separate into two regions. The ones with the smaller radius sink to the bottom, the ones with the larger radius float to the top.
I mean, in retrospect, it seems kindof intuitive, but to see a complex reaction (the separation of two dissimilar liquids) occur with such a very simple rule-set really excited me at the time. I felt I was on the verge of discovering some cosmic fundamental law.
Then I got bored with particle simulations and moved on to something else. ;)

lol @ 'geeking out', awesome phrase! Haha, I can totally relate to the feeling you describe; it is a kind of obvious result that you describe, to be fair, but as you say the fact that adding just a couple of the countless physical laws to the equation can generate such realistic results is quite amazing.


If when you render your particles in 2D with a gaussian falloff larger than their 'shell' and threshold the sum of the interacting gaussians (eg, meta-ball style (which you can just do by dumping a 2D greyscale bitmap of a soft airbrush-type dab onto the particle location, sum with whatever is there, and do a 'final pass' to cull everything below 50%, tweak everything above)) you get a really lovely continuous liquid surface.
Throw in a third force of weak attraction at the radius of the gaussian, and you get surface-tension on your liquid.
Then you add in some refractive rendering based on particle density, put some obstacles and pysical object interactions with puzzly goodness and goals, package it as an exciting game, make several million dollars, and give me a great wodge of cash for the help.

LOL! Top stuff. Actually, it's weird and handy that you should mention that, because I'm intending to add metablobbing as a display option, and also use it to visually link particles that share certain characteristics. What course did you do, and where? Your maths is better than mine - is it because of research you've done in your free time? I do have a year left to go, I suppose... 'Gaussian falloff' means nothing to me (nor google, sadly :P), though I can visualise what you mean by it. The only Gaussian reference I've come across is 'Gaussian elimination' back in the first week of my first year, doing a Linear Algebra course (matrix manipulations). Great stuff :P

Where did you read about the way to get liquid surface effects? That's such a simple route to such a seemingly complex target. You really know your stuff. How old are you?

Haha, that last paragraph made me chuckle! I promise you Andy that if I make several million dollars (or pounds, I'm not picky :P) I will be more than happy to send you something for your time ;)

I wish I did more physics in my course, frankly; a lot of the stuff to understand the 'theory' of programming languages is very dull. I can see it somewhat proving its use every time I read a rigorous language specification, but nonetheless I'd much rather do something that's a bit more 'hands-on' and with a more apparent use.

AndyRage
09-26-2006, 10:44 PM
LOL! Top stuff. Actually, it's weird and handy that you should mention that, because I'm intending to add metablobbing as a display option, and also use it to visually link particles that share certain characteristics. What course did you do, and where? Your maths is better than mine - is it because of research you've done in your free time? I do have a year left to go, I suppose... 'Gaussian falloff' means nothing to me (nor google, sadly :P), though I can visualise what you mean by it. The only Gaussian reference I've come across is 'Gaussian elimination' back in the first week of my first year, doing a Linear Algebra course (matrix manipulations). Great stuff :P

Where did you read about the way to get liquid surface effects? That's such a simple route to such a seemingly complex target. You really know your stuff. How old are you?


I'm an old and wrinkly 40 years old. I have no formal training in anything really - I left school at 17. And I'm not especially good at math either - I find cheating ways of doing most things, or as a last desperate resort search on the web for how someone else does it. In programming and graphics I'm entirely self-taught.

By Gaussian falloff I really mean any smooth 'S' curve function in intensity from the centre of a circle (white) outwards (black). Using an 'S' curve rather than linear falloff means that the regions interact along curved thresholds rather than linear. You could use a Cosine falloff just as effectively as Gaussian.
As your particles approach, the 50% threshold in falloff describes a curved 'metaball' outline, rather than two circles joining in a cusp as they would if you used linear falloff.
But as I say you can cheat by pre-rendering a 2D bitmap (or just one quadrant of it, if you want to save memory and CPU cache) of the single particle falloff, and doing a very simple 'add' of the greyscale to a map, then do a final pass to cull/tweak around the 50% threshold.

If you get into a lot of programming here's something important to remember... Put in *lots* of comments, and use sensible variable names. Decide on programming conventions, and stick with them. Because you're writing code for some poor sap 12 months down the line who has to maintain and improve it. And more often than not the poor sap is *you*. So do your future self a favour, save tears and bloodshed, and put lots and lots of comments and clarifications in even your prototyping code.
Would you believe that Goblin and ArtRage have a comment on *every single line of code*. Complex bits of code also have a line or two of commets before them saying what they do. And every function has a header block of comments saying what it does in general. And every .cpp has a header block of comments saying what the class does, who wrote it, and when.

So here's sortof what you end up with:
//=======
// CRenderer.cpp: Class to manage rendering of particles in glorious 3D with refraction and reflection.
// Copyright Ambient Design, July 2006, AMB
//=======

//=====
// CRenderer: Class constructor.
//=====
CRenderer::CRenderer() // This is the class constructor
{
m_fRender3D = true; // When this flag is true, rendering is in 3D, otherwise it's in 2D
}

//=====
// Render: This function renders the particle map
//=====
BOOL CRenderer::Render(CImage * imDest) // Main rendering function
{
// First we need to check the validity of the destination map to avoid crashes
if (!imDest || !imDest->IsValid()) return FALSE; // If the destination map isn't valid, drop out

int32 nWidth = imDest->Width(); // The width of the output
...
return TRUE; // Everything worked, and all is well with the world
}

...and so on. Generally the comments on the ends of the line are nicely aligned with each other, so the result is visually pleasing, easy to read, and you can literally read down the page to see what's going on without even needing to see the code. Your future self will really thank you for it!

(edit:) Grrr... the formatting and indenting got screwed up. But you get the idea. Readability is the key. It takes so little time to add comments while what you're doing is fresh in your mind, compared to how much time you waste trying to understand what the heck you were thinking, 12 months down the line.

komodoDave
09-26-2006, 11:08 PM
I appreciate that sage advice ;) I have written a fair bit of code thus far, but since my course forces us to dabble in languages here, there and everywhere without giving us time to immerse ourselves in any particular one, I'm aiming to write the applet I've mentioned simply to become adept at wielding Java so I have at least one strong base from which to grow. I've written shaky, hodge-podge classes to do a lot of what I want in my applet, but am starting afresh now, having had to postpone development from about 4 months ago until now.

I completely agree with you on the variable naming system, but thank you for the reminder. I tend to get carried away in exhilaration when writing code (I know.. sad isn't it :P) if I suddenly think of a particularly efficient way to do something, and once I've written it down I usually am eager to move on to the next challenge rather than write comments for what I've just done... this time however I've forced myself to use JavaDoc properly, and to use the annotation features made available in JDK 1.5 to complement the JavaDoc details.

It's even more wise of you to comment every line of code - that's something I've certainly never done, and probably wouldn't have had you not said anything. Your reasoning is flawless though; even a few days after I'd written some code in a moment of enlightenment, I struggled to recall which variable referred to which object, despite having fairly revealing names for them. I shall follow your counsel and be extra thorough in commenting the code that I write.

40, eh? I wouldn't worry about it - South Korea (or North Korea? Can't remember... whichever one _isn't_ the 'I'm closed more tightly than a homophobe's sphincter' region) has developed some kind of protein/enzyme that completely reverses the ageing process, they report - it can literally turn your grandparents into young people again, eradicating wrinkles etc through cell rejuvenation in the process. Anyway, apparently mass production will begin in 10 years time, so you've only got to last til then and you're set :P lol. I may sound mocking, but I don't mean to be.

[On a morbid/philosophical side note, because it's late and I'm bored/evading sleep: I have a very detached and logical view of life, and frankly don't see death as anything to fear. To be honest, I often feel that life is such a bittersweet thing - there are ecstasies to be sure, but such extreme lows too... I often feel that 'flatlining' by feeling nothing, as (I'm predicting :P) is the case in death, might be better. Also, the possibilities are that a) there is consciousness after death, or b) there isn't. If a) is true, then that's great (actually.. eternal consciousness would be a bit of a bummer imo). If b) is true, then you won't be aware that a) isn't, so no problem! Score.]

I'd just like to thank you for all the info you've shared with me in these few posts - I really appreciate it. It's so rewarding to communicate with like-minded individuals across the globe, regardless of age/sex/race. Isn't the internet great :P Seriously though, thank you Andy. *emails Andy a cold beer*

AndyRage
09-26-2006, 11:47 PM
I split the topic out because it diverged somewhat...

Thanks for the discussion. I wont take you up on the existentialist topic though.
When you get your particle system running, I'd love to see it!

komodoDave
09-27-2006, 10:44 AM
I split the topic out because it diverged somewhat...

Thanks for the discussion. I wont take you up on the existentialist topic though.
When you get your particle system running, I'd love to see it!

Hehe, wise decision.

Darn... you're not going to tell me there are no philosophiles on your team, are you? lol. It was late, I was tired.. what can I say.

I'll show you as soon as the prototype's up and running :)

drzeller
09-27-2006, 12:44 PM
Dang... do those of us who read through this have to pay you two for attending your symposium on particle interaction?!

D.

komodoDave
09-27-2006, 02:27 PM
Yes.

Cough up. *presents open palm*

maror
09-27-2006, 02:46 PM
:lol:

after doing some simple coding examples (dream of makeing a one 3d game :P) i give up coding....
it is simply hillarious what some people can do with a simple text...

my only tipi can give is to check out this fluid pong game => i though it's a good example of a nice particle effect game wich runs great:http://www.plasmapong.com/

greez

komodoDave
09-27-2006, 04:57 PM
Haha, cool game. Sadly the source isn't available though, so I can't see its inner workings, although I'm sure the author would be helpful :)

In case any of you are interested in physics-based games, here's my favourite site that keeps you up to date on the latest indie releases:

http://www.fun-motion.com/

My personal favourite atm is Armadillo Run - if you haven't played this gem, go and download a copy _right now_ from www.armadillorun.com

Dave

AndyRage
09-27-2006, 07:32 PM
Y'know if I look at these things I wont get *any* work done today....

komodoDave
09-27-2006, 08:17 PM
lol!

Do any of your job titles include poking the other members of the team with something sharp if they stop working? Because if the only slavedriver is you, I suspect your system is severely flawed :twisted:

AndyRage
09-27-2006, 09:56 PM
Project killer... Project killer...
Armadillo... constructions... physics.

And Shiny things! Shiny things! Plasma Pong is shiny!


(*twitch*) (*twitch*)

komodoDave
09-27-2006, 11:58 PM
rofl! Armadillo Run is the don... it's so good.