More problems with costs

[Drongle McMahon]

Viewer: 232567 Jun  9 2011 16:23:40 (Project Viewer - Mesh Asset Deprecation)
Server: Mesh Experimental 11.06.09.232605

Tests with My stairs from CTS-536, with triangle-based physics mesh and a gallery wall with round-arched windows.

1. The "streaming cost" from the server has gone up substantially (and might go up more).

2. The upload dialog ad Devcelop->Show Info->Render Info "streaming costs" (from the viewer) still suffer from CTS-536; the cost is related to radius^4 instead of radius^2

ETA: *** Not now: Only thr upload the upload dialof has this error now***.

               The Show Render Info number is now corrected to be based on r^2

3. The viewer-derived still disagrees with the cost in the edit vdialog (from the server).

4. The size-related behaviour of the streaming cost from the server seems odd; at scales of 0.4x0.4x0.6, 4x4x6, and 40x40x60, the stairs cost 5.4, 5.4, 6.4.

5. Physics cost for undecomposed physics shapes (at least) are MUCH higher.

6. There is an automatic switch from Prim physics type to  to Convex Hull with the wall at a size that you should still be able to walk through the door, and you can't. This is hidden. It doesn't appear on the edit dialog, which still says Prim, and it reverts if you stretch it out again. It does affect the physics cost. This is a serious compromise of the utility of the triangle-based physics type. Of course, the better decomposed shape is available instead (now that that bug is fixed).

These developments worry me a lot. With costs the way they are heading, I am afraid there will be almost no cases left where it will be sensible to use mesh instead of sculpties or even ordinary prims, except for attachments. That will mean all the potential performance and appearance improvements will be lost. At the same time, attachments are uncoinstrained and will almost certainly be abused with massive poly counts causing terrible client/gpu lag.

Part of the problem with large things like my wall is that as the size increases, you lose the benefit of good low lod meshes, each of which becomes irrelevant above a certain size (if the calculations were working). This is because the low lod meshes become never-used at normal draw distances. The only solution I know for this is to split the mesh up into much smaller ones, all small enough tp profit from the lowest LOD. Unfortunately, this gradually erodes all the basic advantages of using mesh at all. You might as well be using prims because these do not suffer from the size-related cost issue (although the size does affect whether the LODS are used!), which makes the job easier than the multi-mesh and with no upload costs and not physics shape and cost problems. The lowest LOD ,mesh for my wall is 0.2ktri, while the prim wall (below) at lowest LOD is 0.7ktri, but the mesh one is ignored.

I can already make a good facsimile of my wall with 35 prims (could get to 30 with a few tricks).  That compares with the 13.5 prim cost for the current mesh. A 2-fold increase in mesh cost would tip the balance. But this comes with a different problem. The mesh is curently textured with four small tiled tectures. To get the same texture detail on the prim version would take ten or more custom 1024x1024 textures. This is NOT what we need. Of course I could use alpha textures fopr the windows and save a whole load of prims too .... See how the whole point of mesh gets eroded away when these costs get too high.

Next, I will make a sculpty version. This will cost a few prims, have many times the number of triangles, and use three invisible boxes (0.5 prim each) for physics.  The sculpties will be large enough so that you never see the horrible low-LOD versions, but will not suffer any cost penalty for that*. Let's be profligate and use up six prims. No competition. Goodbye mesh.

There is another possible solution to the size/LOD/cost problem; a model-specific renderVolumeLODFactor that coul;d be set at upload time, or prefereably in the edit dialog. This would have the LOD and cost effects of cutting up the mesh while actually leaving it intact. This would allow the retention of all the benefits of making whole large meshes while still allowing the benefit of good low-LOD meshes. The trade off would be degaded visual performance. If it's adjustable in the edit dialog, and/or by script, the end user could set that trade-off. I don't think it would add significant overhead, as the detail level fo each object is calculated at render time already and this is just a simple multiplication.

*And, I can animate it by sculpt map switching!

[Failed Inventor]

I know that I do low polygon modeling for an online games. So I know how ot make a model but even my low poly, and visibly low poly models are so high in cost if you want to retain a decent lod you would need 1000 prims in allotment to fill a 1024 sqm parcel. which is roughly 5x as much as a 1024 allots. 

this with dumbed down physic boxes, etc. and while each object cost 5 - 25 prims it all adds up fast.

[guY Ralior]

I am a bit new here with mesh costs and such but from just a purely logical standpoint "most" people in SL have very few prims available for use on there land or skybox. The size limitation of a prim is daunting but no matter what the size from .01 to 10 meters its still one prim. To have something that a resident simply resizes go up in prim cost so much seems like going completely backwards in the saving of lag due to prim counts. Unless for some reason the prim cost of a sculpty and the prim cost of a mesh have absolutely nothing in common with the current system of prim counts with scultpted and regular prims.

[Dain Shan]

Good morning.

May it be that they changed something yet again?

This morning i reuploaded some of my models in Sandbox 20 again.

I noticed that the Prim Costs and the streaming costs dropped significant to the value of last week again.

So a modell that had a streaming cost of 3.3 yesterday in sandbox 20 now has a streaming cost of 1.8 !!

No changes in the uploaded files, they are the same as yesterday.

 

Interesting .. if i rezz the Mesh from yesterday it still says streaming cost is 3.3

Seams the server version is the same Mesh Experimental 11.06.09.232605

 

 

[Drongle McMahon]

Note: The streaming cost shown by the Develop->Show Info->Render Info display is now consistent with the expected dependence on radius^2. Only the number in the upload floater is still dependent on radius^4.

[Dain Shan]

Thanks

i diddnt noticed that.

That may explain this behavior