Page MenuHome

"Boid" Force field does nothing; should be removed
Closed, ResolvedPublic


Shift-A --> Force Field --> Boid produces a force field of type "Boid"... which has no appropriate interface and does nothing. There are no docs explaining what it might do beyond a copy-and-pasted bit of copy from a textbook explaining the basic Boids principle.

This appears to be a vestigial feature that ought to be removed. (If I'm wrong, enlighten me and I'll write some updated docs myself)

Note that this is completely separate from the Particles --> Physics --> Boid feature, which works as advertised.


Differential Revisions
D5419: Documentation: Update boids force field

Event Timeline

Aaron Carlisle (Blendify) lowered the priority of this task from Needs Triage by Developer to Normal.Apr 26 2017, 6:37 AM

I looked into this and I found this in the code:

	/* Boid field is handled completely in boids code. */

So maybe something is not being passed correctly from boids.c @Luca Rood (LucaRood) you are the physics guy now maybe you can take a deeper look?

I didn't look at boids.c, but since the code in do_physical_effector does nothing, and pdDoEffectors has no special case handling for boid (no calls to boids.c stuff), I can only see this force field being a noop.

Actually, the concept of having a "boid force field" doesn't even make any sense to me, so I wouldn't be able to implement it, as I don't know what it is expected to do.
As the manual itself says, Boids is an artificial life program, which makes great sense for a particle motion implementation, but not at all for a force field.

As this is currently a noop, and so far nobody knows what it should do, I would just remove it. But if anyone else knows about some awesome super useful implementation of this so called "boid force field", please feel free to chime in.

Might have some weird boid uses as seen here
Its not that if you have not used some feature inside blender that you should remove it, instead learn it.
Things might not always have up to date documentation either, but still thats no reason to remove it.

In the video its shown that boid particles can influence other particle fields.
The application/usage is for specialized particle effects.

@Peter Boos (PGTART) It is not that, but the feature has no code behind it and literally does nothing.

Might have some weird boid uses as seen here

This effect only uses (or at least only needs to use) Boid-type particles; there's no evidence of any exotic force-field use. The long streams are plain ole' Newtonian particles, the few wandering entities are Boid particles where the instanced object group contains a couple of force-fields, and it's those instanced force-fields that interact with the long particle streams.

Boïds fields are a 2.4x feature.
It only works with a Goal or Avoid rule for Boïds particles and a strength that must be negative for Goal rule and positive for Avoïd rule.

So boïds particles can follow a moving boïd field.
Or they can change between several Boïds Fields Goals for the one that have the higher absolute value of negative strength.

But clearly as a behaviour rule, result is really different compared to what produces a Force force field.
And use of Boïds fields allows to precise several targets at the cost of only one rule.

Ok, this makes sense. So we actually have a horrible case of misnaming, lacking documentation, and terrible code design.
I can look for a better way to handle this in the code at some point (when I start working on particles), but for now, I think it is a matter of fixing the docs. (And maybe coming up with a better name, as the field does not introduce any kind of "boyd behavior", but rather influences existing boyds particles...)

Crikey, just had a quick play—thanks Ronan!—and this is a hugely valuable feature. As he says, it lets you animate between Goals rather than moving the Goals (which produces a different effect). The lack of docs is the killer—the fact the strength needs to be negative for Goal use means it's even more unlikely folks will just stumble across its functionality.

Very happy to be wrong :) As promised, I'll try and knock up some text for the docs when I have a mo.

Thought: perhaps renaming it to Boid Goal/Avoid field would help.

It only works with a Goal or Avoid rule for Boïds particles and a strength that must be negative for Goal rule and positive for Avoïd rule.

This is a gotcha. The fact that positive Strengths are completely ignored if the field is used for a Goal behaviour (and vice-versa for Avoid) means there's no point in allowing negative values. For consistency, a positive Strength field should work as a Goal or as an Avoid depending on which behaviour the field is attached to.

How tricky would it be (asks the non-coder) to change the Avoid behaviour in the boids code (or wherever this field interaction is dealt with) to use positive fields rather than negative?

(Though ideally I'd like positive and negative field strengths to work for both Goal and Avoid. So +ve Goal attracts while -ve Goal repels, and +ve Avoid repels while -ve Avoid actually attracts. That'd mean a single field + behaviour could attract or repel depending on the strength)

OK: I've finally found some time to write some better documentation for this, but it'd be useful to check if this is correct. It seems:

  • Assigning a Boid Force Field instead of a normal (mesh/empty) object as a Goal or Avoid target rule adds the ability to set additional parameters—strength, noise and falloff, just like the force fields used for non-boid particles—for the target, something not possible with normal objects.
  • Boid Force Fields used as Goal targets are ignored if their strength is positive
  • and similarly, Boid Force Fields used as Avoid targets are ignored if their strength is negative

But there are two usage approaches. When setting up the Goal / Avoid rules in the Boid Brain, either:

  • Choose a Boid Force Field as the Object to use for the rule (ie set it up in the same way as for normal "mesh" targets)


  • Leave the Object for the rule unset, and the Boid Brain will look at all Boid Force Fields in the scene, and then only use the strongest one as the target for the rule.

This seems to be the way it all works, but before I start trying to churn some documentation out, please chip in if I'm missing some subtlety here. Thanks!

@Sebastian Parborg (zeddb)
it seems this is still not solved. And not documented.
I tried to use attractor (goal) with force field and it changes nothing.
I think this is powerful thing, that underestimated as metaballs due to poor documentation and tricky control

Vyacheslav (hitrpr) added a comment.EditedJul 22 2019, 2:21 PM

@Aaron Carlisle (Blendify)
I found this scene before I post here.
It just crashes my 2.79 or 2.80, and append crush it too
It made with 2.49… And it is old creepy thing I do not want to touch.

@Aaron Carlisle (Blendify)



The objects need to share at least one common layer to have an effect.

there are no more layers and this restriction, as I see it

Thank you so much! I will look at these later today.

Yevgeny Makarov (jenkm) closed this task as Resolved.Aug 18 2019, 3:18 PM
Yevgeny Makarov (jenkm) claimed this task.