In the recent discussion about OpenSpace/Void sims, one argument heard often is that people abuse these kind of sims with so-called "temprezzers". There are several extra attributes a prim can have:
- Physical: the prim gets affected by gravity and impacts with other prims
- Phantom: the prim can be permeated by other prims abd avatars
- Temporary: the prim will get deleted without trace after a short while
The main intended use for temporary prims is to have an object rez props that are only needed for a short time. Many of you have seen palmtrees where every now and then a coconut falls out. The coconut is usually a temporary (and physical) prim, so it vanishes by itself after a short time without littering the parcel and without the need to manually clear it up. Another use for temporary prims are projectiles from weapons like arrows or bullets - again not caring about the parcels prim allotment and not needing to clean up are the main reasons.
However due do the tight prim economy, a second use for temporary prims was found, the so called "temprezzers". A temprezzer consists of a 1-prim base of a regular prim, and then rezzes a complex object (a tree, a yacuzi, a boat - you name it) as a temporary object. As soon as this object gets cleaned up by the simulaor, the temprezzer rezzes a new instance of it. With a temprezzer it is easy to rez way more objects than the parcel prim allotment would otherwise allow.
Now where do these extram prims come from? A full sim has a prim limit of 15000 prims, an OpenSpace/Void sim has a prim limit of 3750 prims. My understanding so far was that a temprezzer "loans" (other people say "steals") free prims from the sim's prim allotment. So if the sim has 14000 of the 15000 prims used, a temprezzer could use a maximum of 1000 prims until it meets the hard limit of the sim's prim allotment.SL artist and blogger Raul Crimson has a different opinion. He claims that there is an unlimited amount of temporary prims (very much like there is an unlimited amount of prims avatars can have attached to themselves regardless how full the sim is), and that this is one of the problems encountered with OpenSpace abuse.
Time for a test, it seems. Together with Ivanova we logged into the Beta Grid and found an empty sandbox with 15000 prims available. The next question was how to rez 15000 prims. Ivanova experimented a bit with self replicating prims, and we were discussing how a "kill switch" could be implemented since 150000 channel listeners would probably lag a sim down to a halt. Recursive rezzing however proved to be quite mind boggling, and while she still had her head in the script, I started to rez and duplicate cubes. It turned out that by always doubling rezzed cubes, fairly quickly I was able to have piles of 2048 prims so the prim allotment could be used quickly.
Finally we had 14999 prims rezzed and therefore only 1 prim available. The last remaining prim we turned temporary, and then there were two options:
- We would not be able to duplicate a second temporary prim (the 15001 on the sim), thus proving me right and Raul wrong.
- We would be able to rez more than 15000 prims using temporary prims, thus proving Raul right.
However what was strange is that I could not shift-drag two temporary prims in order to go to 15003 prims. I could make many many surplus prims by shift-dragging a single temporary prim, but I was not able to create bulks of temporary prims. Further investigation would be needed how this affects temprezzers. But fact is: you can have more than 15000 prims on a full sim.
It is interesting to note that the 15000 prims produced quite some lag. Especially mass editing huge piles of prims slowed down operation significantly, not only getting the prims into edit mode, but especially moving and duplicating them. After Ivanova has left, I took on the task to clean up the sandbox (I did not want to have 15000 prims returned to my Lost+Found). So I thought it would be a neat idea to turn them physical (and temporary).
The effect was kind of neat, the piles collapsing in slow motion like in a Matrix movie, with cubes even get propelled away in slo-mo, however the lag was pretty severe. Still, it was fun.
I was pretty surprised that you can in fact exceed a sim's prim allotment with temporary prims. While I considered temprezzers up to now - dependng on their use - as unfair to the sim neighbours as it "steals" their prims, I can see now that they might even pose a real problem by exceeding simulator limits multiple times. However, further investigation is needed. Still the experiment was a lot of fun.
10 comments:
I've always resisted temporary rezzers as I always thought that they must require processor power, and thus probably create lag.
Rather than use temporary rezzers, in some spaces I've used Loki Ball of Fluid Creations Room Switcher. It rezzes permanent prims (they must have copy permissions) in a set configuration relative to the 'switch'. When there is no one around for X period of time (you specify), it clears away the prims, leaving the prim count available for other uses. At a touch of the button, you can have your prims back in exactly the same order... and what's more you can have up to 9 different 'room' (or space) configurations stored in the one switch. I think it's a better solution than temporary rezzers - and it's very handy for those who have limited prims.
PS: Looks like you guys had a lot of fun and I love the pics :)
Prim limit is not a "hard limit" -- there's no 15000 element table with an entry for each prim slot. Doing it that way would be horribly unwieldy with objects constantly appearing and disappearing and would create cute fragmentation problems. Which means that prim limit is a number things are checked against at certain times when prims are created.
And at certain times they, apparently, are not checked. :)
P.S. I do wonder is there a limit on the number of prims in a sim counting prims worn on an avatar. Each avatar can wear up to 7650 prims (up to 255 in a linked object, one object per attachment point, 30 attachment points) -- and that can go up very, very fast...
The 15,000 prim limit is an arbitrary number Linden Lab went with based on some assumptions made long ago relative to the number of colliders the Havok physics engine could handle, the amount of bandwidth associated with the textures in use based on this choice and the maximum avatars combined into the mix. It's a maximum only in terms of guess work as the years have shown. The sad fact is Havok and newer CPUs today could handle much more while the limited client-side texture cache has held everything back as bandwidth consumption continues to be a major bottleneck.
Temp-rezzing was really the province of weaponry, only the creative (and underhanded) residents found ways to abuse things. More than 15,000 prims is less the issue than the regions clean-up issues and associated scripts.
I go with Clubside, the biggest problem is not the prim count but the textures (also sculpts) and so the bandwith use. This is what creates the most client lag too. Look in optimized games where objects explode in thousand parts without lag and havok engine. But SL can't be optimized that way because of the fact that SL citizens create the objects and scenery.
The prim limit is a bit outdated and one horrible script put a region in more trouble than thousands of prims. Esp. the body attachments of avatars have sometimes more prims than the whole land buildings and hey you can walk nicely with it.
The misuse of openspace sims is a misuse in processor power and bandwidth of the asset servers. But when I put many huge textures on a regular sim it is the same that happens to the asset server.
They all talk about virtualization but LL is sleeping and do not limit the single OS sims cpu and bandwidth or the complete abuse story is a lie.
My speculation behind it is, that they have increased the management time by factor 4 on that openspace sims. More sims to update, more to restart, more to watch for the same money.
Otherwise why can 50$ more per month increase stability and performance? A simple change to class 5 can't do the job.
Thanks for sharing this experiment, Peter, i will link it in my post.
This overuse is something that some OS residents are practicing, giving big problems to the simulators, specially due the use of scripts more than prims itself.
The whole time I was slightly worried that someone from LL would show up and admonish us.
But it all turned out fine in the end.
Me and my friends once testing on temp rez . Resulting: The number you can rez is SQM*25 + ((prim max) - (already rezzed prim))*2. And this number is same on Normal region and OpenSpace.
I'm not sure how many temp prims whole region can hold, but maybe they have another limits for it.
Coming in late here but just became aware of this great post. What would have been interesting is to see the effect of having all these prims being rezzed by a "temp rezzer", as I understand the main contention with temp rez is the use of them being rezzed, cleaned-up, and re-rezzed continually by such a script, (as hinted at by Clubside).
All very interesting, thank you :)
Post a Comment