Ciaran Laval

Chosen Few wrote: The ONLY way to ensure good performance is to make sure the poly counts in the models you buy are never any higher than they need to be. If a model is very poly-heavy, just don't buy it Look for an alternative that is better made (or better yet, learn to make it yourself, and you'll never ever have this problem again). How can a consumer find this information though? How can a consumer gain the knowledge to know what to look for when shopping for products?

Ah thanks, yes understand where you're coming from with that reference.

Drongle McMahon wrote: "Apparently Havok loves cubes" Yes, but the problem is that it only recognizes them when you link them as prims to make the physics shape. If you make a physics mesh that is a perfect cube (or cylinder or sphere), whether analyzed or not, it doesn't recognize it and doesn't make the saving engine resource and physics weight that it could. So only the linked prim method can get you those efficiencies. Now this is another confusing area, probably worthy of further discussion at some point. Do you mean it needs to include the system prim cube shape for this efficiency saving? I ask because the wiki states that convex hull is more expensive, yet when you change a mesh or prim to physics shape prim, the land impact score is likely to rise.

Kwakkelde Kwak wrote: Anyway, the simple fact you are thinking about all these things makes me believe you'll do a more responsible job than the average builder here in SL. I've been playing with Mesh for ages, it's dithering and excuse making now on my part although I really do want to avoid getting into bad habits and it's good to be able to decide, that face really doesn't need to be included and that being my decision.

Another thing to watch out for is to check whether you can rez anything inside the building.

Kwakkelde Kwak wrote: A simple prim box in SL has 108 triangular faces (on the highest LoD), since it has 3x3 squares on all 6 sides. A box shouldn't have more than 6 squares (12 faces), one on each side. This is unless you want to divide one side into multiple textures, but then a prim won't work either. 108 faces might not sound like a lot, but it's almost 10 times more than needed. If you use a lot of boxes on a sim, let's say 5000, you can understand all the useless faces taking up rendertime, causing viewer side lag. The 12 : 108 faces (11%) could even be lower if you remove faces inside walls, on the bottom of objects, anywhere you do not see them. In all cases I encountered, the mesh object was superior in all weights over prims, often by a factor 10 or more. The reason I was using Mesh was to try and avoid having faces that wouldn't show, so inside edges aren't required when another prim will be against them, but in terms of checking resources, it doesn't seem to make much difference when I make comparisons.

Kwakkelde Kwak wrote: I would even advice to use mesh for pretty much all simple physics shapes. I'm not 100% sure how the physics engine calculates a prim's shape, but I can't imagine a prim box is easier on the engine than one or two planes . A ground floor can be two triangles. Depending on its thickness, other floors can be either two or four triangles. Just make sure you don't analyze on upload, the resulting convex hull won't be usable for rezzing objects on, at least as far as I've experienced. Apparently Havok loves cubes: http://wiki.secondlife.com/wiki/Mesh_and_LOD#Havok_Physics_tips_and_oversimplifications

It can take over 5 business days, there have been a few reports of this during the course of this year.

There was a problem for some of us yesterday, but around this time yesterday it seemed to be working again, are you still having trouble?

Thanks for the Wiki quote, 0.4 physics weight isn't too heavy, I may just build for myself and then worry about building for others, I keep holding myself up by finding little issues that put me off but I really just need to get on with it and then take it from there, Obviously I don't want to cause chaos by being wasteful with resources!

That's where I was, but later in the day it was working fine.

This works for me now.

https://jira.secondlife.com/browse/BUG-2018 However you may not have permissions to see it.

Five hours ago I first experienced this problem. Glad to hear main grid is working fine, I was just going to check that. The message appears on the beta grid as soon as I select the mesh model, although initially I didn't realise it was there because the error message popup was behind the main mesh upload window. I've created a Jira about it, although someone else may have already created one.

Thanks for the reply, good points to ponder here, especially with regard to issues such as editing linked objects. Thinking that others might want to mod Mesh items puts a different slant on a lot of areas regarding Mesh building, whereas building for yourself allows more versatility as you'll know the limitations as you built it yourself with those limitations in place. Plenty to ponder, thanks a lot.

Thanks for the reply. Simple shapes are good for getting your head around how mesh works so it's nice to work with them but I do tend to agree that if a basic prim will suffice, then it's probably the better tool, especially now that Drongle has pointed out the perils of editing linked parts.

I had that error this morning on the beta grid, I haven't tried on the main grid, are you on the beta grid or the main grid?

If I rez a standard cube inworld, the physics and download cost is 0.1 and the server cost 0.5. If I upload a mesh cube and use that cube as the physics shape, the download cost is 0.1, physics 0.4, server 0.5. Now if I link a standard cube to the mesh cube and make it invisible, then set the mesh cube to physics shape none, I can get the physics cost back down to 0.1 but obviously the server cost now increases to 1.0. First thing this suggests is that it's probably better to use inworld prims for simple shapes, but if I really want to use mesh, is the server cost or the physics cost the better one to optimise?

The bouncers let you back in I see. The image is fine, it's a spring thing.

I think the problem was implementing the script limits in a helpful way and whether the overheads from that implementation would cause more problems than it solved. The one big argument was the dynamic nature of scripts and how they may need to temporarily grow but would then drop back down quite quickly in terms of usage.

I'd suggest you take a look at avatar.blend / avatar-workbench, which the creator of avastar kindly provide information and links to:: http://blog.machinimatrix.org/avatar-workbench/

Before snagging any images, it may be worth reading the Second Life Brand Center guidelines on use of Linden Lab trademarks, you're probably safer using the InSL logo: https://secondlife.com/corporate/brand/trademark/index.php

I'm not sure why they'd provide the textures if you're not supposd to use them but you should respect the wishes of the creator, even when they're odd! Are you sure they aren't saying you can't sell the items full perms?

I usually experience this when my graphics are ramped up or I've set the window size for the snapshot too high. Now if you're turning your graphics preferences down, I'm a bit stumped but have you tried using a different viewer?

They seem to have fixed it.