Expert Opinions Sought: Which is less resource-hoggy?

[PheebyKatz]

I'm working on a project where something only activates if an avatar is in the area of effect, we'll say for example a 24x24 square meter area.

I already use a repeating sensor (timed reasonably, but still on repeat) to determine if there are still avatars present once things have rezzed, and if nobody's around, everything that was rezzed is deleted, and the scene resets and waits for avatars to come along again.

My question concerns setting the "trap" so to speak, in the first place. My earlier model uses a repeating sensor to tell if an avatar has entered the scene, and if so, then everything rezzes, moves into place, and things proceed. But... it's a sensor that would need to be on allllll the time, always searching to see if an avatar is present, and the area may not really see daily traffic. I would feel bad if I left a radio on in a room and nobody was around, so yeah, leaving a sensor running 24/7 feels icky.

I played last night with using llVolumeDetect() to do the initial sensing instead, like, by making the rezzer object contain the whole scene, and simply making it phantom and transparent. So as it goes now, it can sense when someone (literally) enters the scene (which is now enveloped in an invisible, phantom cube), then does its rezzing business, and then sets up the repeating sensor to make sure avatars are still present. This is nice, because I can have a much less frequent sensor beacon (once every few minutes instead of once a second) as it only has to know if people are still using the scene, and if they aren't, it just cleans up and shuts off.

My question is: will this really make a difference as far as sim resources go? Does using llVolumeDetect() to detect if avatars are present use less overhead than having a sensor going off once a second, or so? It's a single script running, either way, and the script itself will always be running. Is the phantom cube trigger going to be checking itself all the time, to see if it's got someone in it, and how would its resource use compare to just having a sensor on repeat?

I really would like to know if anyone knows, because I want this project to be as lightweight and polite to the server as possible.

Edited January 15 by PheebyKatz

[elleevelyn]

a thing is that collision_end event is not always reliable. The server can throttle collisions when it comes under stress, when so collisions events don't always fire

a way to mitigate collision throttling is to use collision_start to start the sensor using only the no_sensor event. As the tidyup/derez will be done when no_sensor event fires (no agent is present) then the sensor period can be set to some minutes. 3, 5, 10, etc

a way for this kind of script is to use 2 script states: Active, NonActive. Active when avatars present, NonActive when they aren't

Active state has a no_sensor event. NonActive state has a collision_start event.   The two states have one or other event, they don't have both

Edited January 15 by elleevelyn
typ

[Qie Niangao]

Instead of a sensor, could track the agents identified by collision_start, just a lazy slow timer checking whether their OBJECT_POS is within the detection volume.

The advantage of using collision_start isn't only low cost (the physics engine is stupidly fast at this kind of simple geometry) but instantaneous detection without needing to specify any speed of sensor nor timer (for stepping through llGetAgentList to avoid the sensor).

Thing is, though, resource use isn't always intuitive. It may be a nice effect for things to blink on when avatars arrive, but it's not saving resources. The resource use only really matters when there are agents in the vicinity to experience lag, and the big resource expenditures depend on agents being around for their viewers to get object updates and stuff to render. It really does nobody any favors to add a huge flood of scripted object rezzing (and embedded script start-up) to go with all the object updates upon arrival of agents (and their attached scripts)—unless it's all for effect.

[PheebyKatz]

It just detects the first collision, starts its sensor (which is timed at 3 minutes now), rezzes its thingies, and tells itself not to do anything else until nobody is around and it's done its cleanup and reset. I figured doing it that way it wouldn't have to track anyone in particular, and another person entering the scene wouldn't trigger a new spawning instance.

Thanks for the advice, guys. More is welcome, of course, but this helps a lot.

[elleevelyn]

comparative frameworks for this kind of app

// one state
integer active;

default
{
   collison_start(...)
   {
       if (active)
          return;

       ... shrink and hide collision prim
       ... rez props
       ... start sensor
       active = TRUE;
   }

   no_sensor()
   {
       ... remove sensor
       ... derez props
       ... restore collision prim
       active = FALSE;
   }
}


// two states

default  // state inactive
{
   collision_start(...)
   {
      state active;
   }
}

state active
{
   state_entry()
   {
       ... shrink and hide collision prim
       ... rez props
       ... start sensor
   }

   no_sensor()
   {
      state default;
   }

   state_exit()
   {
      ... derez props
      ... restore collision prim
      ... note: sensor is local to state so is auto-removed when the state exits  
   }
}

// three states where state default is used to do a onetime setup like read params from notecard, etc
default
{
   state_entry()
   {
      .. do onetime setup ...

      state inactive;
   }
}

state inactive
{
    ... same as two state above ...
}

state active
{
    ... same as two state above, with no_sensor state inactive in place of no_sensor state default
}

 

 

   

 

Edited January 15 by elleevelyn
extra info re no_sensor in three state

[PheebyKatz]

Yeah, it's a simple script, I was just wondering if...

...anyone knew and could tell me if...

...using llVolumeDetect() is lighter on resources than using a constantly-running llSensorRepeat(), in said simple script.

This is my question. I would love to know the answer.

Edited January 16 by PheebyKatz

[Frionil Fang]

18 minutes ago, PheebyKatz said:

This is my question. I would love to know the answer.

I made a very crude test:

• A prim that runs a sensor repeat on avatars, once per second, in a 20 meter radius (with 1 avatar = myself in said radius).
• Another prim with volume detect enabled and only a collision_start event, using keyframed motion so that it bumps into me once per second.
• Both prims do nothing with the info but just keep a float text counter so that I can see they are correctly detecting me.
• Sensor repeat has no no_sensor event, volume detect doesn't have a collision_end event.

After running them for a couple minutes, I checked what the script time info says:

• 0.0015ms for the sensor repeat.
• 0.0011ms for the volume detect.

Next I moved outside the range of both of them and let them run another couple minutes, checked the script time again: 

• 0.0003ms for the sensor repeat (rounded down).
• 0.0003ms for the volume detect (rounded up).

Conclusion: with a single avatar in range, the difference is negligible but in advantage of the volumedetect approach. If I had to guess, more avatars would still sway the advantage for volume detect, but 0.0015 ms for the single avatar case is very, very little, and 0.0003 ms for no avatars is basically nothing. 

[Quistess Alpha]

22 minutes ago, PheebyKatz said:

[Is] using llVolumeDetect() is lighter on resources than using a constantly-running llSensorRepeat()

Yes. Polling for a result is (marginally) more resource intensive, than an event trigger. llSensorRepeat is annoying kinds in the back of the car asking if we're there yet, llVolumeDetect is the parents just knowing when you get there and saying so. The physics simulator is always running in any case and probably already knows if something collided with your object whether the script asks to be informed about it or not.

Now, in the very improbable edge-case in which lots and lots of non-avatars are colliding with your object all the time, and you only care about avatars, maybe llSensorRepeat() could hypothetically be better than constantly asking if the thing is an avatar and finding out that it isn't.

[Wulfie Reanimator]

1 hour ago, Frionil Fang said:

After running them for a couple minutes, I checked what the script time info says:

• 0.0015ms for the sensor repeat.
• 0.0011ms for the volume detect.

Next I moved outside the range of both of them and let them run another couple minutes, checked the script time again: 

• 0.0003ms for the sensor repeat (rounded down).
• 0.0003ms for the volume detect (rounded up).

Script time is an average over the past 30 minutes.

Edited January 16 by Wulfie Reanimator

[elleevelyn]

3 hours ago, PheebyKatz said:

Yeah, it's a simple script, I was just wondering if...

...anyone knew and could tell me if...

...using llVolumeDetect() is lighter on resources than using a constantly-running llSensorRepeat(), in said simple script.

This is my question. I would love to know the answer.

when we look at the two/three state frameworks then we can see that the collision_start event only fires one time, when the space is empty and 1st agent appears. Should other agents appear while the script is in active state then there is no collision_start in the two/three state frameworks

therefore the answer to the question is yes, a onetime collision_start uses less resources than a repeating sensor  to detect the 1st agent

however if we use the one state framework then collision_start event will fire for all agents arriving after the 1st should we not shrink/move the collider prim to where it can't be collided with

 

ps add. for sure is interesting to compare the impact of repeating collision vs sensor repeat, but is not germane to this particular use case

 

Edited January 16 by elleevelyn
simplifly response

[PheebyKatz]

You guys rock. Thanks so much.

[Frionil Fang]

1 hour ago, Wulfie Reanimator said:

Script time is an average over the past 30 minutes.

For some reason I thought it was ~5 minutes, but since the objects were created before the test started the numbers shouldn't be *too* wrong in this case. Thanks, good to know for future.

[PheebyKatz]

I have a theory that Wulfie is Rolig's secret alt-er ego, but don't say anything. It's a secret theory.

And yes, that was a compliment.

Edited January 16 by PheebyKatz

[Qie Niangao]

2 hours ago, elleevelyn said:

however if we use the one state framework then collision_start event will fire for all agents arriving after the 1st should we not shrink/move the collider prim to where it can't be collided with

Now I wonder which costs more, toggling llVolumeDetect() or a script state change to toggle the collision_start handler. Either way it must be deep in the noise.

[elleevelyn]

1 hour ago, Qie Niangao said:

Now I wonder which costs more, toggling llVolumeDetect() or a script state change to toggle the collision_start handler. Either way it must be deep in the noise.

yes. Toggling one property would be less resource than changing two - size and position

also setting the collider prim to 100% transparent and CLICK_ACTION_IGNORE is a onetime lifetime happening

i have not been a fan of doing this myself but is certainly doable. I am more down the move/resize path as I prefer a object to not be in the same space when it doesn't serve a purpose for the space in the moment

[PheebyKatz]

3 hours ago, elleevelyn said:

I am more down the move/resize path as I prefer a object to not be in the same space when it doesn't serve a purpose for the space in the moment

It does make good sense, moving it out of the way. Even just from a builder's standpoint, I wouldn't want to be camming around the build and trying to move something and end up having the rezzer/sensor/detector in the way. That gets annoying.

And shrinking it is the best way to get it out of the way, because it's the simplest; the detector is positioned at the exact center of the area it will be used in, and would be hiding "underground" and out of the way, if I shrink it when it's done its rezzy thing.

Edited January 17 by PheebyKatz

[elleevelyn]

i also add on here that Qie suggestion to toggle llVolumeDetect in the one state case is also a good thing to do as well as resize/move the prim

even when we hide the collider prim inside another prim then move an avatar faster than 1/45 seconds then the avatar can go thru the outer prim even when is not phantom triggering the collision prim. Who avatar does that ? Anyone who does this kind of thing just because they can

[Profaitchikenz Haiku]

12 hours ago, Wulfie Reanimator said:

Script time is an average over the past 30 minutes.

^^^I can't stress how important this is.^^^

When you're trying to compare different script methods, you either have to wait until this period has elapsed before taking script time for the new method, or, you can try taking the difference between consecutive script time readings and tracking that change.

Bear in mind that because of that 30 minute averaging period, there will always be a skew one way or the other, unless there is no significant change.

Also, bear in mind that waiting 30 minutes before performing the next set of readings might mean there has been a change to the region and more or less activity going on would also have some bearing on the readings.

Ultimately,. to compare method A with method B you are best writing timestamps at the start and end of the test and using the difference between them to assess the methods.

Edited January 17 by Profaitchikenz Haiku