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