 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This is not very interesting looking yet, but I'm working on a swarm
simulation. Obviously, this is not a swarm in the air, but rather a
swarm on the ground.
Here's the link:
http://runevision.com/temp/swarm_2_c.mpg (2.18 MB)
Imagine those small arrows being replaced with some form of two-legged
creatures eventually. Now then, please come with suggestions on how I
can improve the behavior. What looks right? What looks wrong? You might
want to take into consideration that each boid is given a certain goal
(quite obvious in this animation) which is will approach, and eventually
there will be something at these goal locations which the swarm will try
to attack (probably with some kind of projectile weapons). I.e. it will
be a battle simulation. (That's my high ambition anyway. It'll probably
take years though.)
But anyway, all comments appreciated!
Thanks in advance,
Rune
3D images and anims, include files, tutorials and more:
rune|vision: http://runevision.com **updated Mar 9**
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune wrote:
> This is not very interesting looking yet, but I'm working on a swarm
> simulation. Obviously, this is not a swarm in the air, but rather a
> swarm on the ground.
Cute, but confusing. Are we looking at 1 swarm or 2? a blue swarm and a
yellow swarm?
The first half of the video is fairly clear on the boids grouping together
around 2 points but in the second half they sorta gather in the middle and
then don't know what to do next. (it looks a bit like erratic behavior)
--
Ger
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ger wrote:
> Cute, but confusing. Are we looking at 1 swarm or 2?
> a blue swarm and a yellow swarm?
It's just one swarm, but the test simulation is rather artificial.
Here's what happens:
First half of the boids are given one goal and the other half another
goal. This is done randomly.
Then later the same happens again - half of the boids are given one goal
and the other half another goal. This is again done randomly, and
without respect to the first dividing of the boids.
Finally all the boids are given the same goal (in the center), and
nothing more happens after that. The long pause after the third goal is
already met is shown in order to demonstrate the chaotic behavior that
the boids follow even though there are no further changes in the
external forces.
Rune
--
3D images and anims, include files, tutorials and more:
rune|vision: http://runevision.com **updated Mar 9**
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> But anyway, all comments appreciated!
Cute! :-)
The animation looks kinda blocky though, no smooth rotation or movement of
those little arrow-thingies. How exactly do you calculate it? Do you use the
"standard" boids System (avoid collisions, seek goal, accompany friends)?
And I'd guess mapping the boids onto the heightfield is more or less the
difficult path?
I really need some more background information before I can start thinking
about what to try. I'm more the algorithmic guy.
:-)
--
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune wrote:
> This is not very interesting looking yet, but I'm working on a swarm
> simulation. Obviously, this is not a swarm in the air, but rather a
> swarm on the ground.
>
> Here's the link:
> http://runevision.com/temp/swarm_2_c.mpg (2.18 MB)
>
> Imagine those small arrows being replaced with some form of two-legged
> creatures eventually. Now then, please come with suggestions on how I
> can improve the behavior. What looks right? What looks wrong? You might
> want to take into consideration that each boid is given a certain goal
> (quite obvious in this animation) which is will approach, and eventually
> there will be something at these goal locations which the swarm will try
> to attack (probably with some kind of projectile weapons). I.e. it will
> be a battle simulation. (That's my high ambition anyway. It'll probably
> take years though.)
>
> But anyway, all comments appreciated!
>
> Thanks in advance,
Great example of emergent behavior!
--
Respectfully,
Dan P
http://<broken link>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I like it... I don't know what their leaders are telling the boids what to
do, but it does look kinda natural... It reminds me of Age of Empires and my
hordes of pikemen/cavalry/archers :)
Fernando
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> The animation looks kinda blocky though, no smooth rotation or movement of
> those little arrow-thingies.
I'll second that. I did some tests with flocking algorithms some time
ago and that was one of the problems I ran into: The movement was never
as smooth as I wanted it to be. This applied to both fast changing
directions and fast changing velocities of the boids. Perhaps one could
add another goal to the boids (apart from collision avoidance, etc.),
which would be to try to keep the movement smooth...
> And I'd guess mapping the boids onto the heightfield is more or less the
> difficult path?
Hm. You could either simply use the height at a certain point (trace),
or use the heightfield in your animation (that would include calculating
the slope to find better (in energetic means) ways, etc.). First seems
trivial, second seems ehm, not so trivial ;)
> I really need some more background information before I can start thinking
> about what to try. I'm more the algorithmic guy.
That's why I love POV, btw: It's nice to visualize all those cool ideas
(fractals, particle systems, etc.)
Florian
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim Nikias v2.0 wrote:
>> But anyway, all comments appreciated!
>
> Cute! :-)
Hehe, it's funny how everybody says that. I never thought of it as cute.
:)
> The animation looks kinda blocky though, no smooth
> rotation or movement of those little arrow-thingies.
It's somewhat smooth, but they *can* change direction rather quickly.
Part of it is due to the mpg-compression though.
> How exactly do you calculate it? Do you use the "standard"
> boids System (avoid collisions, seek goal, accompany friends)?
I skipped "accompany friends" since it's not necessary when they have
the same goal anyway. But I did use "steer up with friends" which is to
move in the same direction of nearby boids. There's a lot of other stuff
in the algorithm too though. Code to avoid collisions more when moving
fast than when moving still, and also have more flocking behavior when
moving fast, and code to make the boids move slower when going uphill
than when going downhill etc.
> And I'd guess mapping the boids onto the heightfield
> is more or less the difficult path?
Well, only because the whole simulation is written in Java, and I had to
write my own height-field handling class with methods that resemble the
trace function and I also wrote my own vector-class with methods
equivalent to vcross(), vdot(), vlength(), v_axis_rotate() etc... Once
all that was done, it was not a big problem confining the boids to the
surface of the heightfield. And no, no trace() inside POV-Ray was
used... :)
> I really need some more background information before I
> can start thinking about what to try. I'm more the
> algorithmic guy.
> :-)
Well, it's not really algorithmic advise I'm after... ;) It's more
observations like "Hey a few of those boids are walking sideways too
much - that looks odd!". (I did intentionally make the boids be able to
move sideways and backwards a little, but I think it's maybe too much at
the moment...)
Rune
--
3D images and anims, include files, tutorials and more:
rune|vision: http://runevision.com **updated Mar 9**
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I cant tell from the animation, but as a rule when I've tried this sort of
thing I have the boid nearest its goal move first, it seems to give a more
"flowing" feel to the stream of boid. Are you implementaing anything like
that?
"Rune" <run### [at] runevision com> wrote in message
news:40689448@news.povray.org...
> This is not very interesting looking yet, but I'm working on a swarm
> simulation. Obviously, this is not a swarm in the air, but rather a
> swarm on the ground.
>
> Here's the link:
> http://runevision.com/temp/swarm_2_c.mpg (2.18 MB)
>
> Imagine those small arrows being replaced with some form of two-legged
> creatures eventually. Now then, please come with suggestions on how I
> can improve the behavior. What looks right? What looks wrong? You might
> want to take into consideration that each boid is given a certain goal
> (quite obvious in this animation) which is will approach, and eventually
> there will be something at these goal locations which the swarm will try
> to attack (probably with some kind of projectile weapons). I.e. it will
> be a battle simulation. (That's my high ambition anyway. It'll probably
> take years though.)
>
> But anyway, all comments appreciated!
>
> Thanks in advance,
>
> Rune
> 3D images and anims, include files, tutorials and more:
> rune|vision: http://runevision.com **updated Mar 9**
> POV-Ray Ring: http://webring.povray.co.uk
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Well, it's not really algorithmic advise I'm after... ;) It's more
> observations like "Hey a few of those boids are walking sideways too
> much - that looks odd!". (I did intentionally make the boids be able to
> move sideways and backwards a little, but I think it's maybe too much at
> the moment...)
Hm, well, I've had the animation loop for some time and just inspect their
movement. I think there's too much sideways movement. Additionally, you
might want to have the boids have a viewing frustrum which other boids to
steer up with. For example on the first goal seeking, some boids just run by
the goal because they steer up with boids behind them.
You also might want to add a factor how egoistic a boid is. Some might just
want to push into the crowd when getting to their goal, thus intentionally
getting closer to a boid than it normally should. With varying distances,
some boids will thus get forced out, whilst "stronger" ones move in on the
prey.
Judging from your description what you want to achieve (two-legged, shooting
boids), I'd say you're going for the home-version of Massive, eh? I had that
in mind as well, thus the modular approach for my Particle-System, I can
easily reuse the movement code for boids. It seems like we're often having
same thoughts, but that you're always one step further in actually
implementing the stuff. :-)
But my boids will have to wait a little longer. Need to finish the
particle-system and then cook up a nice keyframing system...
Regards,
Tim
--
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
