Jump to content
Tanis Wylder

Animesh and LI sky rocketing

Recommended Posts

1 hour ago, Wulfie Reanimator said:

No. Animesh animations are handled the same as avatars.

Sorry, my mistake. What I meant to say was that animesh movements are handled by the server.

Share this post


Link to post
Share on other sites

The point - of course - is that there is some server load and the added LI cost is not just a "money grab" ...

There is also load on the computer running the client.

Why yes, lets allow every user to treat Animesh objects exactly the same way as they do all other objects - such a wonderful idea! Then users would complain even more about the lag, blaming everything but themselves ....

Fun fact: Basic members can have one Animesh object attached to their avatar at a time. Premium members can have *gasp!* two! Cue the users screaming that "it's so unfair!"

Edited by Solar Legion

Share this post


Link to post
Share on other sites
31 minutes ago, ChinRey said:

Sorry, my mistake. What I meant to say was that animesh movements are handled by the server.

In that case I don't know why you would bring that up as an explanation at all, because the same applies to all objects -- even regular prim cubes -- with animesh bringing no additional overhead over any other type of object..

Share this post


Link to post
Share on other sites
6 hours ago, Love Zhaoying said:

IMHO, they should charge LI for Pathfinding.

They do. Turn on pathfinding in a prim and you're instantly at 15 LI.  Turning on animesh also has a 15 LI penalty, but they don't add.

I'm more or less OK with the animesh charges. The main problem I have with the animesh models I've bought is that they don't have enough triangles at the lower levels of detail. I have a Deadpool model that disappears at Medium LOD.

Arguably, the mesh LI cost (1 LI per 666.666 triangles) should not add to the animesh/pathfinding penalty. They use different resources. Animesh uses viewer time. Pathfinding uses server time. Mesh uses network time and GPU space and time.

I'd argue for something like

    LI = max(animesh_penalty, pathfinding_penalty, triangle_penalty)

so an animesh character gets 10,000 triangles (666.666*15)  before the cost goes up. This would encourage creators to design 10,000 triangle animesh. Then 5000 at medium LOD, 2500 at low LOD, 1250 at lowest LOD. Which is good enough for most NPCs.

You can convert mesh avis to animesh and put standard clothing on them, but they're going to come in around 70-120 LI.

hoodlumhillbackgroundcharspng.thumb.png.bf9b06389c16b19a924f9d4c3c1a54da.png

Mesh, but not animesh. Hoodlum Hill's static background characters, all in one place. A good set for creators to look at closely.

Most of these are around 2000-3000 tris. One is 18,000 tris, and it's not the best looking or most detailed character there. It's the woman in red in back. 1 LI, because the lowest LOD has one triangle. Something should be done to discourage that trick. In comparison, the man in the brown jacket is 5 LI, but only 1966 tris. But it has a reasonable number of triangles at lowest LOD.

Incidentally, all of these characters look badly distorted at lowest LOD. They all look like the junk the viewer's uploader generates. Creators, at least use the decimator in Blender. It's much better than the one in the uploader.

The reduction factor for each LOD needs a look. Animesh is using 2, which is more generous than regular mesh. Regular mesh has a higher value built into the uploader, which encourages too-small low LODs. Somewhere between those values.... Maybe 3?

 

Share this post


Link to post
Share on other sites
12 hours ago, ChinRey said:

Animesh animation is done by the server, so the server has to recalculate the object's position and even its shape several times a second and it also has to send the updated data to the client. It definietely adds both server and bandwidth load. How much, none of us here knows but we can be quite sure Vir Linden does.

The only time an Animesh object's shape is calculated by the server is with the Encroachment return protocol as a provision was added for Animesh to guesstimate if it is visually encroaching into another owner's parcel not just if any of its link's bounding boxes are encroaching.

Share this post


Link to post
Share on other sites
12 hours ago, Wulfie Reanimator said:

In that case I don't know why you would bring that up as an explanation at all

Umm... because that is the explanation? ;)

But you have a point because it may not be the whole explanation. Does the extra LI apply to stationary animesh too?

Share this post


Link to post
Share on other sites
16 minutes ago, ChinRey said:

Umm... because that is the explanation? ;)

But you have a point because it may not be the whole explanation. Does the extra LI apply to stationary animesh too?

Yes.

Share this post


Link to post
Share on other sites
1 hour ago, ChinRey said:

Umm... because that is the explanation? ;)

It's.. not, though. Let's recap:

Quote

I am not abusing the system in any way shape or form - I am asking for a legitimate reason - the server load will not change whether the file [that is the mesh] has animations switched on or off. it all comes down to rendering which is done on the viewer, not the server. The LI increase is unrealistic IMHO..

20 hours ago, ChinRey said:

Animesh movement is done by the server, so the server has to recalculate the object's position several times a second and it also has to send the updated data to the client. It definietely adds both server and bandwidth load. How much, none of us here knows but we can be quite sure Vir Linden does.

What you said is a universal truth about all objects in-world. The server (sim) handles all objects this way -- polling for updates and sending those out to all clients (viewers). Whether or not the object is prim, flexi, sculpt, mesh, animated mesh.. same thing. The number of triangles does not increase the amount of work the sim has to do to maintain it. There are different kinds of "changing position," though. Instant changes like llSetPos, or smooth, physics-based like llSetKeyFramedMotion. These also cause the same amount of work for the sim, regardless of the type of object being moved.

 

1 hour ago, ChinRey said:

But you have a point because it may not be the whole explanation.

Definitely, but I don't know what LL's reasoning is exactly. Things like keeping a list of active animations does have a little overhead, but not 15 LI's worth. The simplest explanation might just be that they chose to lump it together with Pathfinding Characters. (Especially if we consider the fact that Pathfinding + Animesh doesn't result in 30 LI like Animats pointed out.) This doesn't bother me though, because 10'000 triangles should be quite enough for a full-body NPC.

You can try this yourself by rezzing a prim cube, going into the Features tab, and checking the "Animated Mesh" box.
Then you can put this script into it to turn it into a character for pathfinding:
default { state_entry() { llCreateCharacter([]); } }

 

Edited by Wulfie Reanimator

Share this post


Link to post
Share on other sites

I'm still trying to assess whether Animesh is viable for applications wildly different from NPCs, requiring substantially simpler geometry. A couple weeks ago there was a thread in the Scripting forum in which a poster suggested Animesh as a low-resource-demanding way of making a ball appear to be tossed up and down in the avatar's hand. That may or may not have been the very best solution for that particular problem, and having a high Land Impact doesn't particularly matter for an attachment as long as it doesn't reflect true heavy resource usage.

It's not hard to also imagine a freestanding contraption with simple geometry for which Animesh-like shape change would seem to be the best technical solution -- but prohibitively costly in Land Impact compared to other approaches (texture-flipping, say, or old-school translation+rotation of parts). Now, if there really is a justification for that 15 LI barrier to entry, then it's fine for us to stick with the other approaches. But those approaches send an object update for every call to llSetLinkPrimitiveParamsFast(), so that's not all that lightweight, low LI notwithstanding, and that's very different from a one-time download at the start of a looping animation. And of course texture-flipping burdens the viewer with lots of usually-invisible geometry, as I muttered about earlier. So... I'm thinking that 15 LI minimum may mean lost opportunities.

(Personally, I have no interest in manually animating objects rather than calculating their transformation, but no doubt others' mileage will vary.)

Share this post


Link to post
Share on other sites
29 minutes ago, Qie Niangao said:

I'm still trying to assess whether Animesh is viable for applications wildly different from NPCs, requiring substantially simpler geometry.

Take a look at the secret wall passage at "World of Magic" event... pretty unique and interesting case of animesh use.

  • Thanks 1

Share this post


Link to post
Share on other sites
On 2/18/2019 at 7:46 AM, Tanis Wylder said:

It is the viewer that does all the animations etc, and there is no need to charge the creators that for it.

Without commenting now on whether or not we have the specific cost correct (the people that chose that value know much more about it than I do), it is not correct that Land Impact exists only to protect or account for server side resources. Viewers lag too, and objects that produce unnecessary viewer lag have a large negative impact on the experience of Second Life. Land Impact exists not only to limit what you can put out, but to encourage efficient content. Animesh objects are more work for a viewer to process; the increment to LI exists to reflect that cost.

  • Thanks 8

Share this post


Link to post
Share on other sites

The only reason a high LI cost seems so crazy is because LL has been too stupid to put other, much needed restrictions on other things in SL. 

Share this post


Link to post
Share on other sites
6 hours ago, Gadget Portal said:

The only reason a high LI cost seems so crazy is because LL has been too stupid to put other, much needed restrictions on other things in SL. 

To be fair to Oz and his crew, "has been" is a key phrase here. There was a noticeable change in attitude towards computer work load almost from the day he took over and they've been working on it ever since. Yes, they could have done more and I often feel they should have done more. But they inherited a closet crammed full of skeletons, old habits die hard and any improvements in resource management is bound to meet a lot of resistance from users and probably from other parts of LL too.

Edited by ChinRey
  • Like 2

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×