ArtRage 5 Product PageArtRage Lite Product PageArtRage for iPad Product PageArtRage for Android Product PageArtRage  Android Oil Painter Free Product PageArtRage  Free Demos Page

Page 1 of 3 123 LastLast
Results 1 to 10 of 21

Thread: Particles and life

  1. #1
    LOL, that hammock pic of Tycho is the cutest 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?

    Code:
    dave.stopSpanishInquisition()


    ....


    .....*calls a taxi*

  2. #2
    Join Date
    Mar 2006
    Location
    Ambient Design
    Gallery
    View images
    Posts
    3,842
    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)
    AndyRage's mantra for graphics engine code:
    "Sure - how hard can it be?"

  3. #3
    Wow, thanks for the highly informative response there Andy

    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

  4. #4
    Join Date
    Mar 2006
    Location
    Ambient Design
    Gallery
    View images
    Posts
    3,842
    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.
    AndyRage's mantra for graphics engine code:
    "Sure - how hard can it be?"

  5. #5
    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

  6. #6
    Join Date
    Mar 2006
    Location
    Ambient Design
    Gallery
    View images
    Posts
    3,842
    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.
    AndyRage's mantra for graphics engine code:
    "Sure - how hard can it be?"

  7. #7
    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

  8. #8
    Join Date
    Mar 2006
    Location
    Ambient Design
    Gallery
    View images
    Posts
    3,842
    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.
    AndyRage's mantra for graphics engine code:
    "Sure - how hard can it be?"

  9. #9
    Quote Originally Posted by AndyRage
    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.

  10. #10
    Join Date
    Mar 2006
    Location
    Ambient Design
    Gallery
    View images
    Posts
    3,842
    Quote Originally Posted by komodoDave
    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.
    AndyRage's mantra for graphics engine code:
    "Sure - how hard can it be?"

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •