Jump to content

New mesh streaming costs.


Drongle McMahon
 Share

You are about to reply to a thread that has been inactive for 4745 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Note: April 12th 2010 - the function calculating the streaming cost was changed to use the same LOD switch distances as the LOD does. This changes the graphs here by scaling 1/4 on the horizontal axis and by changing the radius at the inflection points to 4.33, 8.66 and 34.66. The general shpes of the graphs remain the same. One example is given in a later post.

Another important difference is that the cost now reaches a flat plateau at radius >=34.66  m, that is less than the maximum prim size. For a cube, that is about 40x40x40m. Bbefore, this was at a limit greater than the maximum size.

Further changes are likely before release.

---------------------------------------------------------------------------------

The new "parabolic" streaming cost code has been put in the latest development viewers. I doesn't yet show up on the upload or edit floaters, but you can see it using Develop|Show Info|Show Render Info. Selected streaming cost is near the bottom. The algorithm is described in the wiki.

From thence, I quote the following caveat: "This is a preliminary design of an unimplemented cost algorithm. EVERYTHING is subject to change, and certainly will change, during the course of implementation."

Thinking we might usefully discuss this here, I start off with a couple of graphs. The first shows the general form of the relationship of the realtive* streaming cost (y) to the "radius" (half bounding box diagonal, x) of the mesh. Essentially it consists of three parabolic segments. The discontinuities at their edges are the sizes at which successive LOD meshes never get seen. 

parabcosts1.png

The dashed vertical lines show where these always are on the x axis (radius), and the horizontal ones have the equations that can be derived from the algorithm for the vertical, cost, axis. A gray dotted line shows the radius of a 64x64x64 cube mesh. Sizes larger than this must be megaprims. For radius > 144.4m, the cost stays constant (as only the high LOD is ever displayed).

The second graph(s) show some of the effects of different LOD mesh data triangle/nertex reduction strategies. The numbers in sqare brackets are the relative* sizes for [high, medium, low, lowest] meshes. The high LOD meshes are all the same.

somepcosts.png

On the top left, the same high LOD mesh has either a two-fold (red) or four-fold (blue, default) step at each successive LOD.

On the top right is the effect of leaving out the last one or two lowest LOD steps. Note that above one of the threshold sizes, the omission no longer makes a difference. This is because you never see the mesh from far enough away to take advantage of the lower LODs.

Bottom left is the darastic effect of missing LOD steps at the high LOD end. This should be enough to ensure that people take the effort to include at least some proper LOD meshes, although there are some circumstances, with small very simple meshes, where this might be useful.

Finally on the bottom right, you can see the effect of concentrating the LOD reduction in the first step. At many sizes, there is a huge advantage in reducing the LOD data size rapidly. This could be very useful, for example, where idoor furniture will never bee visible from large distances.

*PS please note that thee units of size and cost are realtive. The absolute numbers don't correspond to anything in a known way.

  • Like 2
Link to comment
Share on other sites

Arton, The actual numbers here don't mean anything. That's why I said the data sizes were "relative". I have no way of knowing how many triangles/vertices end up as what size of data. There is also a variable scaling factot for the whole thing. The numbers here are for kilobytes of compressed data and a scaling factor of 1. That will not even be a simple multiple of vertices or triangles.

Link to comment
Share on other sites

Fragmentation vs. LOD

While checking out the new streaming costs, I noticed the following consequence that may have useful applications (or may be regarded as a problem!) For a model with four-fold LOD reductions, the streaming cost is not far from proportional to size (see attached figure). In addition, the height of the graph is proportional to the data size of the mesh. So if we make a horizontally ribbed column needing edge loops at a set interval, then the cost will be roughly proportional to the square of the height. That means two stacked small columns will be half the cost of a single column twice the height!

Is that true? I made a set of columns, 16, 32 and 64 meters tall, with rings of vertices every meter. Made LOD meshes for them with about 4-fold steps by halving vertical and circumferential vertex numbers. The costs were 2.7 prims for the 16m column, 9.0 for the 32m column and 24.3 for the 64m column. Stacking four or two of the smaller columns to make the 64m total that cost 10.8, 18 and 24.3 for the three alternatives. So yes, you can reduce the prim cost of a large mesh by breaking it down into smaller meshes.

If course there is a trade-off. The smaller radii of the smaller meshes mean they switch LOD at lower distances. (That is why they are cheaper). Nevertheless, there may be circumstances, walls and fences come to mind, where this could be a good trade-off. Conversely, if you want to postpone LOD switches to the greatest distances, you should avoid making your buildings from multiple smaller components.
mclin.png

Link to comment
Share on other sites

It is a common practice and much shared tip in SL to mess with the LOD settings. Go to debug and type in rendervolume and a number comes up that is 2.0. If you set that higher, to 4.0 or even 8.0, then you get lesser LOD switching. Many people do this to avoid LOD switching of sculpty clothing parts.

I am not recommending this, and I am sure that it would slow down your FPS. I am just wondering if people will tend to mess with this setting in large numbers when mesh comes out to avoid LOD switching on buildings and such that were not made with your suggestion in mind Drongle.

There are many different levels of skill and knowledge among content creators, and when mesh hits the main grid, there will be a large number of new people jump into the game to be sure. Not all of them will produce equally good mesh, especially at first.

Link to comment
Share on other sites

Yes indeed. The other thing that relates to the principle used for the algorithm is the view distance. If that is smaller, then the meshes will be less likely to need downloading and will consume less of that user's (and the server's) resource. However, we obviously can't have a different cost for eacxh observer. So there is no choice other than using a default set parameters, for renderVolumeLODFactor and (effectively) view distance. I think it's qite likely that poor LOD meshes will cause people to use a higher factor, as have sculpties. Mostly that affects only their own client, which would be their own concern, but it must also somehat increase the amount of download data requested from the servers. I've no idea whether that is a significant source of server-side lag.

Link to comment
Share on other sites

 


Can someone kindly explain the point of trying to switch to mesh?  It seems like it is just tipping the boat over for no good reason to me and causing far more problems than any possible benefit that I could see.

 

* Meshes are more efficient than prims.  Prims always have the hidden parts of the geometry even if you cannot see them.

* Meshes are more effiecient than sculpts.  Sculpts are based on a fixed texture map size, which mean you usually have excess vertexes you don't need.

* UV mapping lets you optimize texture usage.  A single mapped texture can do the work of multiple textures on prims.

* The "Mesh" project is about more than just importing 3D models.  It's adding shadows, and directional lighting, and larger base prims, and preparing the way for additional maps beyond the single color map we use for textures now.

The combination of the above will let SL look better with less lag, and let you do more with your prim allowance.  Oh, and then there's the little bit about better looking avatars:

http://lh3.googleusercontent.com/_N3W3ksl-Xiw/TX1MNwf60OI/AAAAAAAACbM/Wznmhu6pwo8/s800/Posed%20With%20projector.JPG

I made that avatar, and I'm mediocre at best as an artist.  A really good one will be able to do much better.

Link to comment
Share on other sites

I think it is not a question of switching. The introduction of mesh is supposed to be an addition to the existing content creation methods, not a replacement for them. The existing methods will preferred to meshes for many applications, not least because of the prim cost of meshes against parcel limits, which is what is discussed here.

It is certainly remarkable what skilled builders have been able to produce with the existing construction tools. However,  meshes bring greater flexibility that can often make new things possible or do the same things with more efficient use of server and viewer resources. Detailed control of texturing and of LOD (level of detail) transitions seem most important to me. To others, it is the ability to make meshes follow the movements of the avatar skeleton. And so on...

On the other hand, there are risks. Mesh does transfer much of the work of construction to external software, much of which requires knowledge and skills not yet available or easily acquired for everyone. Greater flexibility also involves greater scope for mistakes. Accessibility to external tools means accessibility to content not designed for or optimized for the environment.

The eventual balance between the potential benefits against these risks and the measures to control them is crucial to the outcome and extent of mesh introduction. Constraint by prim costing, based on real resource consumption, is one of the important parameters that will determine this balance.

Link to comment
Share on other sites

 


Drongle McMahon wrote:

Arton, The actual numbers here don't mean anything. That's why I said the data sizes were "
relative
". I have no way of knowing how many triangles/vertices end up as what size of data. There is also a variable scaling factot for the whole thing. The numbers here are for kilobytes of compressed data and a scaling factor of 1. That will not even be a simple multiple of vertices or triangles.

 

I'm not talking about your graphs, they are pretty fine. I just seeing my meshes show almost twice the amount of 'Cost' as what they did before. The numbers in the edit floater was our only indication of 'parcel prim count'. Freshly rezzed meshes will show the new higher cost in the floater, in latest Mesh Viewers, untill you shift drag copy them.... For me, the numbers there are the same as what is shown in 'Show Render Info'. So I have to assume that this is the current prim count for mesh. If the cost number in the edit floater never was an indication of parcel prim count, we never had an indication at all about parcel prim count.

I know it's all subject to change. I only added my 2 cents, that sculpts will be still effective, if this streaming cost (not your graphs) will be the final parcel prim count for mesh.

Link to comment
Share on other sites

 


Drongle McMahon wrote:

On the other hand, there are risks. Mesh does transfer much of the work of construction to external software, much of which requires knowledge and skills not yet available or easily acquired for everyone.

I see it as parallel to the situation with textures.  Anyone can use a texture already created by someone else. More advanced builders learn Photoshop or Gimp and make their own custom textures.  Similarly, anyone will be able to use meshes created by someone else.  And then if they have the desire, they can learn to make their own custom ones.  I expect very quickly after mesh is introduced for there to be "builder kits" with a variety of meshes pre-made and ready for texturing.

 

Link to comment
Share on other sites

Arton...

You are right. I think the increase will tip the balance a bit back towards sculpties for some applications. Sadly, one of these may be lanscape-sized things, where meshes could make a big contibution. In other applications, I think meshes will still have the edge, especially where LOD distortion spoils sculpties badly, as in many window frames and chairs,

Daniel...

"I expect very quickly after mesh is introduced for there to be "builder kits" with a variety of meshes pre-made and ready for texturing."

I could not agree more. As said nabove, better LOD control should see simple, prim-cheap, meshes for things like window frames and furniture replacing sculpties everywhere, and to everyone's benefit. No doubt the builder's kits are all ready to go. It is possible to make the UV maps so they are easy to texture. The problem will be timing. As long as most people are not using mesh-capable viewers, people will delay the change.

Link to comment
Share on other sites

Well, I checked some models yesterday, and all my prim costs are up. This is not good, and I think that the equation needs to be adjusted. The penalty for size is also way off, IMHO.

Because of this long wait, I've had to make sculpty representations of the mesh that I've already made. With the current costs, my customers are not going to want the mesh versions. The prim cost is going to be almost twice that of a sculpty prim, despite the mesh version being greatly more efficient than the sculpty version in so many ways.

If you ask me, mesh should get an added bonus in prim cost because the textures applied to mesh, are far more efficient and is not taken into account. The current common practices of texturing objects in SL is extremely inefficient compared to texturing a mesh, and we get no added bonus for this in prim cost.

Link to comment
Share on other sites

  this all reminds me of the old days back in sl beta, there was a time we payed a fee for every prim we rezed,it just shows the first systems  they  the lindens come up with  arnt allways the  best but over time they work out things,,back  when we had the pay for prims fee , some person created the flyng fish that produces offsprings,  it would fly up to you  was like a pet people would take a copy then rez it it would lfy around you then take off  soon it would  multiply  on your land and you sit there and watch your  bank account drain in short order :),

what ever  the system they come up with for mesh, wont stop people maken what they want and or people buying  anythign they like,  yes they can  slow the process and people will work at  maken things low prim, this will come over time.

this is my option but i feel the mesh beta  grid has basicly at its end of its usefullness , most have worked out there work flow systems , have a idea of how to do things, and not many really  building things there cuse it seems like a waste of time, i think  people want to  test thing out in the main grid in real conditions,and let the lindens fine tune things from there.

Link to comment
Share on other sites

I investigated several more parameters.

First, the new implementation's limitation by reference to a maximum area is exactly equivalent to setting the view distance to 256/sqrt(pi) instead of 256. Changes to the view distance simply scales the graph along the radius (x) axis. So that is the effect of using this area-based limitation instead of the simpler one it overrides.

Second, changing renderVolumeLODFactor multiplies the LOD switch distances by that factor and again just scales the graph along the x axis. If you double both renderVolumeLODFactor and the view distance, you end up with exactly the same graph.

Third, if you use the switch distances d/r=<0.24,0.06,0.03> (from possibly irrelevant place in source) instead of d/r=<1,0.24,0.6> (from algorithm) the graph is only slightly different in shape, although it is again scaled along the x axis.

So the general shape is a good reflection of the actual resource consumption under all circumstances. The important variables are vertical and horizontal scaling which determine the maximum cost and the rate of increase with radius. These are the only two things where adjustments might be considered.

The graphs show the same set of LOD meshes; top left = present algorithm, top right = with view distance 512; bottom left = with renderVolumeLODFactor = 4, bottom right, using alternate switch distances. Note the different horizontal scales at top and bottom.

extras.png

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 4745 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...