"Boid" Force field does nothing; should be removed #51302

Closed
opened 2017-04-24 05:57:02 +02:00 by Howard Matthews · 26 comments

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.

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.

Changed status to: 'Open'

Changed status to: 'Open'

Added subscriber: @HowardMatthews

Added subscriber: @HowardMatthews
Member

Added subscriber: @Blendify

Added subscriber: @Blendify
Member

Added subscriber: @LucaRood-3

Added subscriber: @LucaRood-3
Member

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

case PFIELD_BOID:
	/* Boid field is handled completely in boids code. */
	return;

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

I looked into this and I found this in the code: ``` case PFIELD_BOID: /* Boid field is handled completely in boids code. */ return; ``` So maybe something is not being passed correctly from `boids.c` @LucaRood-3 you are the physics guy now maybe you can take a deeper look?
Member

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.

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.

Added subscriber: @PeterBoos

Added subscriber: @PeterBoos

Might have some weird boid uses as seen here https://www.youtube.com/watch?v=kyrhDTmPUAc
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.

Might have some weird boid uses as seen here https://www.youtube.com/watch?v=kyrhDTmPUAc 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.
Member

@PeterBoos It is not that, but the feature has no code behind it and literally does nothing.

@PeterBoos It is not that, but the feature has no code behind it and literally does nothing.

In #51302#430826, @PeterBoos wrote:
Might have some weird boid uses as seen here https://www.youtube.com/watch?v=kyrhDTmPUAc

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.

> In #51302#430826, @PeterBoos wrote: > Might have some weird boid uses as seen here https://www.youtube.com/watch?v=kyrhDTmPUAc 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.

Added subscriber: @zeauro

Added subscriber: @zeauro

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.
https://youtu.be/Uvltf_oBd9E?t=1m33s

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.
Boïds_Fields.blend

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. https://youtu.be/Uvltf_oBd9E?t=1m33s 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. [Boïds_Fields.blend](https://archive.blender.org/developer/F576404/Boïds_Fields.blend)
Member

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

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.

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.

In #51302#430849, @zeauro wrote:
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)

Thought: perhaps renaming it to Boid Goal/Avoid field would help. > In #51302#430849, @zeauro wrote: > 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)

or

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

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) or - 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!

Added subscribers: @ZedDB, @Vyach

Added subscribers: @ZedDB, @Vyach

@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

@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
Member
https://blenderartists.org/t/boid-attractor-deflector-example-scene/462643

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

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

Added subscriber: @jenkm

Added subscriber: @jenkm

@Blendify

D5419


/physics/forces/force_fields/introduction.html

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

@Blendify [D5419](https://archive.blender.org/developer/D5419) *** /physics/forces/force_fields/introduction.html > 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
Member

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

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

Changed status from 'Open' to: 'Resolved'

Changed status from 'Open' to: 'Resolved'
Yevgeny Makarov self-assigned this 2019-08-18 15:18:11 +02:00

Added subscriber: @Alecheck

Added subscriber: @Alecheck

Hello people. I was having this mind fuck with boid too. I had a few animated butterflies , which I didnt wanted to be partcles, but I wanted them to act with boid field and follow it. But it didn't work.
So I try the other fields and I kind a recreate the effect with a Harmonic field. I experiment with the parameters and here where I stop.butterlyies.png
butterflies0001-0250.mp4

Hello people. I was having this mind fuck with boid too. I had a few animated butterflies , which I didnt wanted to be partcles, but I wanted them to act with boid field and follow it. But it didn't work. So I try the other fields and I kind a recreate the effect with a Harmonic field. I experiment with the parameters and here where I stop.![butterlyies.png](https://archive.blender.org/developer/F7974137/butterlyies.png) [butterflies0001-0250.mp4](https://archive.blender.org/developer/F7975616/butterflies0001-0250.mp4)
Sign in to join this conversation.
No Milestone
No project
No Assignees
8 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender-manual#51302
No description provided.