 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim Nikias v2.0 wrote:
> Hm, well, I've had the animation loop for some
> time and just inspect their movement. I think
> there's too much sideways movement.
Yeah.
> Additionally, you might want to have the boids
> have a viewing frustrum which other boids to
> steer up with.
Yeah, I haven't gotten to that part yet. :)
> For example on the first goal seeking, some boids
> just run by the goal because they steer up with
> boids behind them.
Which ones? Let's call the initial columns from left to right A, B, C
etc. and the initial columns from top to bottom 1, 2, 3 etc. Can you
single out the boids you refer to? Cause I'd be interested in studying
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.
An interesting random factor. I'll sure try it out later... :)
> 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?
You could say that, though I envisioned it before the movies were made,
so that's not where I got the idea from. Besides, my simulation is
point-based - while the developers of Massive carefully explains how
their system is much more advanced than primitive point-based systems.
Oh well, there's a limit for my ambitions. ;)
> I had that in mind as well, thus the modular
> approach for my Particle-System, I can easily
> reuse the movement code for boids.
Hmm. If you're going to code a complete battle simulation in pure
POV-Ray script, then I wish you good luck. If, besides that, you also
have plans to release the code and make it userfriendly and
well-documented, then I wish you good patience as well!
I've decided to code my simulation in Java, and to make it specialized
and not care about userfriendliness or documentation or about making it
generic. I have decided it because it means that I'll have all the fun
of coding the simulation, and (almost) none of the hard work... ;)
> It seems like we're often having same thoughts,
> but that you're always one step further in
> actually implementing the stuff. :-)
It has happened a few times, yes... ;) But it sounds like you have plans
to continue doing great contributions to the POV-Ray community, while I
have sort of given up on that. One can do two things - create great
work, or create the tools that enable others to do great work. I have
concentrated more on the latter for a while, and now I'll concentrate
more on the first for a while (or attempt it at least)...
> But my boids will have to wait a little longer.
> Need to finish the particle-system and then cook
> up a nice keyframing system...
I'm looking forward to seeing more of your stuff! :)
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Felbrigg wrote:
> 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?
Hmm. I prefer implementing rules that make sense. I don't see how it
makes sense for boids to follow directly the rule you describe. However,
I still think it happens in reality, because a boid will not move
forward if there are boids right in front of it that stands still. So
what I'd like to do is implement a different rule than the one you
describe, but which have a side-effect equivalent to the effect you
describe. I wouldn't have thought of this if it weren't for your input,
so thanks!
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Hmm. I prefer implementing rules that make sense. I don't see how it
> makes sense for boids to follow directly the rule you describe. However,
> I still think it happens in reality, because a boid will not move
> forward if there are boids right in front of it that stands still. So
> what I'd like to do is implement a different rule than the one you
> describe, but which have a side-effect equivalent to the effect you
> describe. I wouldn't have thought of this if it weren't for your input,
> so thanks!
The "flow" comes about because the unit nearest its target moves out of the
way often making room for those further away. So if you had a stream of
boids amongst other "clutter" the one at the front moves first, making room
for the second and so on. Without this rule those following the first would
have to divert. Of course, that chaotic effect may actually be what your
after. When I was playing with this, I was trying to get soldiers to march
in column, hence my rule. Hope that clarifies what I'm saying.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Oops! I 've just reread your reply and my further explanation was repeating
what you said. Guess I should read the detail and not just the headlines.
Sorry!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Which ones? Let's call the initial columns from left to right A, B, C
> etc. and the initial columns from top to bottom 1, 2, 3 etc. Can you
> single out the boids you refer to? Cause I'd be interested in studying
> them. :)
It'd be the last column, one before the last row. That guy just heads on out
of the field of view. If you look at the other boids though, they point
towards a corner of the dark gray patch once they get settled. So why is
that first guy running off? Frightened by the masses behind him? ;-)
> You could say that, though I envisioned it before the movies were made,
> so that's not where I got the idea from. Besides, my simulation is
> point-based - while the developers of Massive carefully explains how
> their system is much more advanced than primitive point-based systems.
> Oh well, there's a limit for my ambitions. ;)
"Much more advanced" is a relativ term, you know. I've read lots about
Massive, watched all kinds of footage, and for me, it boils down to this: a
Massive-AI will "seek" it's opponent, instead of just picking the nearest
one. Seeking the "proper" opponent is achieved by using various methods:
checking for surrounding sounds, field of vision, probably signals other AI
make... That aside, a system with more complicated rules has to be more
advanced than a primitive point-based-system, right? :-)
So, you could, for example, create a viewing field for the boid, perhaps
using a rectangular area with intervals. Sort the boids that would map onto
the intervals, and just use the one closest to the boid, the others can't be
seen behind this one. Then check from the remaining boids which one is
closest and an enemy. And there you go, one first simple rule for doing a
more AI-Approach to selecting an enemy. Add some other stuff (like, when the
boid has a higher "coward" level, it will tend to pick enemies close to
groups of friends, or just head to his friends and help beat the guys they
are already fighting with) and voila: POV-Massive is born! :-) Well, at
least I plan on doing something like that, first a running boid script, and
then add some rules for direction judgement and better interaction.
> Hmm. If you're going to code a complete battle simulation in pure
> POV-Ray script, then I wish you good luck. If, besides that, you also
> have plans to release the code and make it userfriendly and
> well-documented, then I wish you good patience as well!
I've got patience! :-) Seriously, I've had quiet a few courses now concerned
with programming. I know that POV-SDL has it's limits in terms of
calculation power, but it's easy and intuitive (which I suspect to be the
reason why you implemented some of the vector-functions like vcross() in
Java, still some kind of POViness in the code, eh?). Additionally, with all
the data I use out of the scene these days, it's just a requirement when
doing stuff for POV.
> I'm looking forward to seeing more of your stuff! :)
And the same applies to you! I'm always anxious to see what you've come up
with, and if you're getting ahead of me again...
;-)
--
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Felbrigg wrote:
> Oops! I 've just reread your reply and my further
> explanation was repeating what you said. Guess I
> should read the detail and not just the headlines.
> Sorry!
Hehe, no problem. :)
Thanks for the feedback.
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
|
|
| |
| |
|
|
|
|
| |
|
|
