1
$\begingroup$

I want to save performance in a scene which contains a lot of objects with constantly working logic bricks. How to turn it off while the player is not nearby?

$\endgroup$
1
2
$\begingroup$

You can do it with logic bricks:

enter image description here

Explanation: This logic setting will suspend physics (Edit Object brick/Dynamics/Suspend Dynamics) at the beginning of the game (Delay = 0) and restore it (Edit Object brick/Dynamics/Restore Dynamics) when an object with a player property is in a 5 blender units distance.

$\endgroup$
3
  • $\begingroup$ I deleted my example, this is a much cleaner solution. $\endgroup$ – dval Jan 15 '16 at 2:46
  • 1
    $\begingroup$ Also, I believe These are referred to as 'Logic Bricks' in the Logic editor, not Nodes. This might cause confusion with the 'Node Editor' window. [blender.org/manual/game_engine/logic/… $\endgroup$ – dval Jan 15 '16 at 4:32
  • $\begingroup$ @dval you are right I updated the answer. Thanks $\endgroup$ – atevm Jan 15 '16 at 8:19
1
$\begingroup$

Lets talk a bit about when logic bricks run


Sensors

Sensors will always run when they have a connection to an enabled controller. A controller is enabled when it belongs to an active state of the game object.

This means you can dynamically disable sensors by switching the state.

Warning: Disabled sensors do not sense anything. They will start sensing within the next frame after enabling them.


Controllers

Controllers are executed when they get at least one trigger from any connected sensor. Therefore the most inefficient design is to use an Always sensor with [True Level Triggering] enabled. Therefore avoid that unless it is absolutely necessary.


Actuators

Actuators run when they are active. They react on activation and deactivation signals from connected controllers. Activation signals override deactivation signals (OR behavior).

Actuators differ in how long they run.

Single Frame Run

These actuators run exactly one frame and deactivate themselves. They will ignore deactivation signals as they have no effect anyway.

Examples: * Property Actuator, Action Actuator in Property Mode, Random Actuator, Scene Actuator

Autodeactivation

These actuators perform there operation until it completes. Examples: * Action Actuator Play mode

Explicit deactivation

These Actuator run unto they get a deactivation signal Examples: * Action Actuator Loop Stop Mode * Motion Actuator

Sometimes they continue but stop at a later time. Examples: * Action Actuator Loop End Mode (stops when the cycle completed) * Action Actuator Flipper mode (stops after finishing the reverse playback)

Hint:

  • You can measure if an actuator is running or not with the Actuator sensor (be aware at startup no actuator runs).

Conclusion:

It is up to you to choose an efficient design. Anything that does not run ... eats less time.

Turning off logic that is not near the player

First of all you need an efficient way to identify such objects. Then you can

  • Remove the game object
  • Switch states to disable sensors

but you need the other way around too. When the (supposed) object comes near:

  • add the game object
  • Switch states to enable sensors

I hope it helps a bit.

$\endgroup$
2
  • $\begingroup$ Thank to everyone, I have already tried given approaches, and found that the most logically-expansive part of my scene were objects with 'mouse over' sensors. It slows game down when an object with mouse over comes in the camera field of view, no matter how far from the object you are. So I excluded this sensor from my approach and now my big scene works ideally :) $\endgroup$ – user13138 Jan 16 '16 at 5:31
  • 1
    $\begingroup$ Mouse over sensors have an inefficient implementation (at least until Blender 2.76). Each sensor will run it's own object detection operation at each single frame. If you have many "mouse over" it might be more efficient to use a single "mouse over any" and notify the detected objects via Python e.g. by setting/resetting a property. $\endgroup$ – Monster Feb 1 '16 at 6:10
1
$\begingroup$

you could add a 'Near' sensor to the player, it can set a variable or trigger a message actuator. Or add it to the items to check for the player.

You could also use it with an 'And' controller mixed with whatever you primary sensor is. Then both would have to be true to actuate.

$\endgroup$
1
  • $\begingroup$ or even better, check to see if RayCastTo player works, if not, stop logic. But this is the right answer. :) $\endgroup$ – Scalia Jan 15 '16 at 4:05

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.