MantisBT - opensim
View Issue Details
0008205opensim[REGION] OpenSim Corepublic2017-07-01 13:122017-07-02 16:44
slow putzo 
 
normalminoralways
newopen 
AMD multi coreLinuxFedora 25
master (dev code) 
 
OSgrid 0.9.1.0 (Dev) 4df19ec: 2017-06-16
Grid (1 Region per Sim)
BulletSim
Mono / Linux64
Other
Singularity
0008205: llGetParcelPrimCount does not report Land Impact
In 2011 SL changed what llGetParcelPrimCount reported from prim count to be land impact (li). opensim apparently has not made this change so it is out of sync with the wiki and does not adhere to the "gold-standard" of working exactly the same as in SL.

The wiki states:

Function: integer llGetParcelPrimCount( vector pos, integer category, integer sim_wide );
325 Function ID
0.0 Forced Delay
10.0 Energy
Returns an integer that is the total land impact of objects on the parcel at pos of the given category
• vector pos – position in region coordinates (z component is ignored)
• integer category – a PARCEL_COUNT_* flag
• integer sim_wide – boolean, TRUE[1] searches parcels in the region with the same owner as the targeted parcel, FALSE searches only the targeted parcel

How it works

For each object in the Second Life world, Second Life compares three important performance factors: download weight, physics weight, and server weight. It then chooses the highest of these weights and assigns it to the object as that object's land impact rating.

Here's a very quick overview of the different weights; for more information on each, follow the links below:

Download weight: Calculated by determining how much bandwidth is required to download and view the object. Larger and more visually complex objects have a higher download weight. You can reduce the download weight of complex objects by generating or uploading less complex meshes for differing levels of detail when you upload a model.
Physics weight: Calculated by determining the complexity of the object's physics model. You can reduce the complexity of a mesh's physics model by using the analysis and simplification tools in the Upload Model window, by uploading your own less-detailed physics model, or by choosing a different physics shape type, such as Convex Hull, on the Features tab of the Build Tools window. Vehicles must have a physics weight of 32 or lower, but may have higher download or server weights.
Server weight: Measures the impact an object has on Second Life's server resources. Objects that are composed of many prims and have physics enabled and/or contain scripts tend to have high server weights.
When is an object's land impact calculated using the new algorithm?

Legacy prim objects have a land impact rating equal to the number of prims they contain. However, any object's land impact is calculated using download, server, and physics weights if it meets any of the following conditions:

The object is an uploaded mesh.
The object is linked to an uploaded mesh.
The object, or any part of the object, has a physics shape type other than Prim. You can change this on the Features tab of the Build Tools window.
The object has a normal or specular map applied to it.


simple to test. Use any viewer and get the prim count and the land impact values of any parcel or item. Then use Function llGetParcelPrimCount to get the same information. It will always match the prim count and not the land impact the viewer reports.

My testing so far has resulted in this function reporting the number of prims and not the land impact.

Here is the script I am using to report parcel usage:

//==== G L O B A L V A R I A B L E D E C L A R A T I O N ====
list gPrclID;
integer gTotPrims;
float gX;
float gY;
integer gNUM;
float xlimit;
string results;


Init()
{
    gPrclID = [];
    gTotPrims = 0;
    // Begin scanning at the SW <0.0,0.0,0.0> corner of the sim
    vector regionsize = osGetRegionSize(); // get the max size of the region dimentions
    xlimit = (integer)regionsize.x; // set the region top limit
    gX = 4;
    gY = 4;
}

scan()
{
    while (gY < xlimit)
    {
        //Grab the parcel's ID and name at position <gX, gY, 100.0>
        list parcel = llGetParcelDetails(<gX,gY,100.0>,[PARCEL_DETAILS_ID,PARCEL_DETAILS_NAME]);
        key temp = llList2Key(parcel,0);
        string parcel_name = llList2String(parcel,1);
        if (parcel_name == "") parcel_name = "(no name)";
        if (!~llListFindList(gPrclID,[temp])) //Scan at this location if this parcel was not scanned earlier
        {
            ++gNUM;
            integer Count = llGetParcelPrimCount(<gX,gY,100>,PARCEL_COUNT_TOTAL,FALSE); //Do not include other parcels owned by llGetOwner()
            gTotPrims += Count;
            results = results + parcel_name + " Land Impact = " + (string)Count +"\n";
            gPrclID += [temp]; //Add this parcel to the "previously scanned" list
        }
        // Increment X and Y in successive scans to look at the entire sim in 8m square blocks
        if (gX < xlimit) gX +=8; // increment the x value
        if (gX > xlimit)
        {
            gY += 8; // if at top of column
            gX = 4; // step to bottom of next column
        }
    }
}
 
default
{
    state_entry()
    {
        Init();
        llSetText("Touch to start scan",<1.0,1.0,0.0>,1.0);
    }
 
    on_rez(integer start)
    {
        llSetPos(llGetPos() + <0.0,0.0,0.5>);
    }
 
    touch_start(integer total_number)
    {
        Init();
        llSetText("Scanning ....",<1.0,1.0,0.0>,1.0);
        gNUM = 0;
        results = results + "Scan started on " + llGetRegionName()+"\n";
        scan(); //scan entire region for land impact
        // Reached NE corner
        results = results + "Scan finished. Total region land impact = " + (string)gTotPrims + " in " + (string)llGetListLength(gPrclID) + " parcels (not counting temp rez prims).\n";
        llSay(0,results);
        llSetText("Touch to start scan",<1.0,1.0,0.0>,1.0);
        llResetScript();
    }
}
Why is this important? With the advent of var regions and a somewhat increase of general users who want to use opensim in a social type of network, providers such as myself try to provide reliable home sites to them. Couple that with the proliferation of mesh items and a var region can easily become a useless lag haven for those who want to only stand around but never be able to move.

Placing a prim limit on a user does not help if the tools used in world to report their server impact which relates directly to land impact do not work. SL made this change for this very reason. I have been told by several users that who cars if mesh items are poprly made or high in land impact. It does not cost anything to upload and everything is free here. No tiers.

That is all true, but only if you do not actually run a server that needs to be efficient and you can manage the load it is trying to provide service for.

It would be nice if the functions needed for a script to report actual usage worked right and like the wiki says they do. It would give some support to those of us who want to keep the grid running smoothly and make it a fun experience for all.
No tags attached.
Issue History
2017-07-01 13:12slow putzoNew Issue
2017-07-01 16:08UbitUmarovNote Added: 0032111
2017-07-02 09:25slow putzoNote Added: 0032116
2017-07-02 15:48UbitUmarovNote Added: 0032118
2017-07-02 16:44slow putzoNote Added: 0032121

Notes
(0032111)
UbitUmarov   
2017-07-01 16:08   
Yes we dropped the "gold-standard" of working exactly the same as in SL, at least I did :)
("Energy" you mention there is another case)
Our version of Land Impact math was introduced in Avination and now on master. You can see it on mesh uploads and objects information.
But it is only informative.
It does all sense to use metrics that do account for the complexity of the objects, just the way it was done at SL, specially the accounting model transition, is not very appealing
I did hate having a (ok a ugly) little vehicle within physics limits and see it broken because I got 2 cleaver and decided to change a prim to shape type none.
So something still to consider...
(0032116)
slow putzo   
2017-07-02 09:25   
I think I understand what you are saying. The tools the user uses to make and upload an item have been changed to a land impact presentation. That is wonderful.

However it appears that same algorithm has not been implemented in the
llGetParcelPrimCount function. It looks to me like it only reports the number of prims and is not taking into consideration mesh objects.

All of my testing has resulted in that function reporting the actual number of prims and not the land impact numbers being reported by those tools you mentioned.

My understanding of this is very limited, as I am not a creator, and have no understand of mesh other than I hate it because it does nothing but bring lag to my otherwise well running var regions.

The few creators I have talked to about this all say the same thing. If the item is made properly mesh will have the opposite effect in that it will reduce lag not increase it. They also tell me most of the items brought to OSgrid from other grids are very poorly made and do exactly what I am experiencing.

My point is that as a script writer trying to inform users when their parcel has exceeded a reasonable load limit measured by "prims". A mesh with an equivalent load of 50 prims but is only 1 prim soon grows to hundreds of prims with this inequality yet my script reports to them everything is fine. So why do they have lag.

I see hundreds of errors like these in my region logs:

2017-07-02 08:53:09,399 WARN [PHYSICS]: large mesh data on OdePrim prim11_prim11-mesh/699eb531-2a7d-4bab-a4f4-f4515179a965, mesh 27f63b1e-357c-450f-aff8-985e3ea98ebb at <728.9991, 199.9296, 28.95073>, 20496 vertices, 122832 indexes
2017-07-02 08:53:09,790 WARN [PHYSICS]: asset provider returned null asset for mesh of prim Walk Chair/d4e21011-e311-453a-9fd1-4c9bd3cbd035.
2017-07-02 08:53:24,329 WARN [PHYSICS]: large mesh data on OdePrim prim11_prim11-mesh/37924c17-f134-416b-90c7-fbc5e9753a95, mesh 27f63b1e-357c-450f-aff8-985e3ea98ebb at <718.5547, 201.3849, 28.95073>, 20496 vertices, 122832 indexes
2017-07-02 08:53:57,893 WARN [PHYSICS]: large mesh data on OdePrim prim11_prim11-mesh/a2be74fe-ead4-4f70-bb58-ce2b1bd74a8b, mesh 27f63b1e-357c-450f-aff8-985e3ea98ebb at <730.5037, 199.9799, 28.95073>, 20496 vertices, 122832 indexes

Being ignorant about what these log entries are telling me is this good or bad?

When looking at these regions I see the "land impact" measurement way out of line with the "number of prims" measurement my viewer reports to me.

I run a scanner on all regions which reports prim usage to each parcel holder. The intent is to notifying them when their parcel is causing problems for them and everyone else on the VAR region.

Unfortunately my reports tells them everything is fine when it isn't.

If there is no script function that can report land impact then there is no way to prevent the problem from starting or getting worse.

The wiki says this function does report "land usage" but I don't think it does. My belief is it only reports number of prims. Originally that is what it did, but its purpose was changed a very long time ago.

I can appreciate trying to keep up with a moving target but then lets ban mesh since it came along and caused the wiki to get changed to deal with it.

If I am wrong about how this function is working, how come it only matches prim count everywhere I test it?

If I am right can't it be fixed to match what the wiki says it is suppose to be doing?

The only tool I have to compare prim count and land impact is the viewer and it does not show them to be the same on these laggy regions.

How about an OSSL function that reports them both, side by side?

This mesh is really starting to be a big issue in var regions or even 256x256 regions with all this bad content being brought here or created here.

Since the logs report "large mesh" how about something that prevents the problem from even being allowed. Prevent it from being loaded by flagging it "exceeds limits" or something. We have to do something if in world script tools can't detect it and try to slow it down.
(0032118)
UbitUmarov   
2017-07-02 15:48   
ubOde does show warnings about very large meshs, but will try to handle them.
but this is more a error, that chair maybe broken.
2017-07-02 08:53:09,790 WARN [PHYSICS]: asset provider returned null asset for mesh of prim Walk Chair

And you a right, we should give more information about objects complexity ( LI or not). But it is not easy to add now.
The only "easy" place is on new meshs upload, and that's where it was added.

guess wiki land impact does mean that literally (i.e. number of prims) not the metrics we now call LI
(0032121)
slow putzo   
2017-07-02 16:44   
Another comment about the list of errors. It is the primary area where all the boot up time is being used. My gut tells me these warnings are also indicating that as it does try to handle these monstrosities it is taking a lot more time. It can handle about five of them per minute as I look down the list of many of them. That means that if I have say 25-30 of these things, there goes about 5-6 minutes of reboot time dealing with poorly made mesh items.

For now I an going to see if I can detect the "bad" mesh and write a script to just delete them.

I would rather upset residents about them not being able to rezz bad assest than try to explain what some neighbor of theirs was the cause of all the lag they were having.

Thanks very much for giving me a better understanding of the difficulties there are with dealing with mesh.