Jump to content

Land Weight vs Mesh File Size?


Syle Devin
 Share

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

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

Recommended Posts

So I have another question on mesh uploading. It seems that land weight is also figured out based on file size and not just how many triangles are in a mesh. Splitting up a mesh into multiple files seems to lower the weight but I do not understand why and would like to. While I may be wrong, right now, I understand the process to be like a puzzle. Even if I split up a mesh into multiple files it would all still fit together to end up with the same land weight.

Am I correct to assume that or does mesh file size affect the land weight? This is not counting for levels of detail and only considering file size against land weight of a mesh.

Link to comment
Share on other sites

You can't predict the land impact by the filesize. There are too many things that can be exported into the dae file which aren't used by the uploader but ingored completely.

Splitting up your mesh into various smaller sections, will result in these changes:

1 A lower download weight

2 A shorter range for LoD switches

3 A higher server weight

The smaller an object is, the faster it will change to a lower LoD model. Because this means less stress on the graphics cards of everyone with the object in view, LL rewards you for it by a lower landimpact. Splitting up your mesh has a small disadvantage though, especially noticable in very simple meshes. The minimum serverweight per object is 0.5. If you have a very small mesh with a download weight and physics weight lower than that, the server weight will determine the landimpact.

An example...

I made a very simple chair with some chains, which all needed a dedicated object. The display and physics weight would have resulted in a landimpact of 3 or 4, but since I was forced to use a good number of very basic objects, the server weight made the landimpact 14.

All I mean to say is you can play around with these things and see if you can get an optimum for your specific object.

Link to comment
Share on other sites

The SIZE of a mesh affects the distances at which the alternative level of detail (LOD) meshes kick in. A small mesh's LODs change over a shorter distance; whereas a very large mesh has a much longer viewing distance before its LOD changes occur.

These LOD distances directly affect the Land Impact - mainly because a large mesh object is visible at its maximum LOD for much longer, hence it requires a higher amount of data streaming from the SL server.

This can be tackled via different approaches to your mesh construction. Personally, for my own meshes where their LOD switches WON'T be visible (such as buildings with totally enclosed interior spaces not directly visible from outside areas), I severely ramp down the detail in LODs 2-3-4 to simple triangles (one triangle per material face). These extremely low LODs in cases like this can make a VAST reduction in subsequent Land Impact costs. Obviously, for exterior surfaces and for interiors which will be visible from outside, you need to use different methods... however, the amount of triangle detail in the lower LODs will directly affect the overall Land Impact costs.

For generic objects such as furniture, a good approach is to consider the environments they will be most likely used in - for example, a mesh chair would probably be used indoors. As such, it can be helpful to design your LOD meshes to accomodate for this... in this case, the chair wouldn't often need a huge viewing distance, so you could consider how severely you would reduce the LOD3 and LOD4 meshes to help reduce their Land Impact. Of course, it's a matter of weighing up how important these LOD changes are, especially if it's for your own usage where you KNOW what its limitations are, or if you intend to sell it as a merchant, where your customers might use it for totally undesigned circumstances.

Keep in mind that for very large single mesh shapes, such as a 64x64x64m maximum possible size, the LOD1 mesh will most likely be visible over all viewing distances, hence it will have a very high Land Impact cost due to this. The best approach I think (for very large mesh objects) is to break them up into smaller segments to reduce the distances their LODs change, and then optimise their subsequent LOD meshes - this should reduce the overall Land Impact cost when compared to the massive single mesh object. As always, it's a balancing act between detail quality in the lower LODs and overall Land Impact cost. However, I would assume that if you manage a good compromise, your resultant mesh building should be at the very least equal to an equivalent prim build, if not significantly lower overall.

I hope this helps :matte-motes-smile:

EDIT: Kwakkelde beat me to the punch LOL :matte-motes-wink:

  • Like 2
Link to comment
Share on other sites

Kwakkelde and Maeve have already explained everything very effectively, but given the importance of the issue, I will still offer my own version too....

More often than not, the land impact is set to the download weight because that is higher than the physics weight or the server weight. The download weight is designed to represent the average amount of data that has to be downloaded to viewers that can see the object. It is also closely related to the number of triangles that have to be rendered on average by those viewers, and it is through that relationship that the scaling from data amount to land impact is set.

The level-of-detail system (LOD) reduces the rendering burden on the viewer by displaying less detailed (lower LOD) versions of the object at longer distances from the camera. When the camera is further away from meshes, the viewer only requests the lower LOD data that it needs. The distances at which the viewer displays the different LODs is directly dependent on the radius of the sphere exactly enclosing the object. So tiny objects are very rarely seen at anything but the lowest LOD, while huge objects are always seen at the highest LOD. Even when they are scaled versions of the same mesh, the tiny object usually requires dowload only of the small amount of data for the lowest LOD, while the huge object always requires dowload of the much larger high LOD data. Thus the larger an object is, the more data has to be downloaded by the viewers that get to see it, and the higher it's download weight becomes.

When you split a large mesh into smaller pieces, the total amount of data specifying each LOD remains very nearly the same, but the LOD of the smaller pieces switch at smaller distances. So, on average, less of the viewers that can see the object need to download the high LOD data. The average download data is reduced and therefore the download weight, and usually the land impact, is reduced. The first trade-off for this is that people looking at the object will see the lower detail versions from closer distances, reducing the perceived quality of the object. Secondly, if you go too far, you hit points at which the physics weights or the server weights become limiting instead of the download weights.

For other prims, the different LOD meshes are fixed, but for meshes, they are specified or generated at upload time. Making the lower LOD meshes appropriate for the destined scale of the object, while optimising for land impact, is one of the most powerful, as well as the most time consuming, aspects of making mesh objects.

Note: There are all sorts of implicit assumptions that underlie the exact way the download weight is calculated. These include the distribution of objects and cameras and the graphics setting used by the average viewer. The result is a dependence of download weight on the square of the object radius within each of a series of size ranges. This results in much more sharply increasing weight as the radius increases, that often surprise the user on first encounter. This is also responsible for the effectiveness of dividing up large models to reduce land impact.

Link to comment
Share on other sites

Since it does not seem file size does much to land impact, only mesh size, I uploaded my mesh to test view distance and I became annoyed deeply, only because I do not understand. I have heard that objects in a mesh are not viewed as different objects. The problem I have is that in my .dae scene the different objects in that scene are viewed as different objects in the SL viewer. Lets just say that I am working on a fully furnished bowling alley in blender which I wish to upload once it is done. The problem is when I upload it in SL each object has its own view distance. Having it be one upload while being multiple meshes seems to not work well in SL especially when trying to control LoDs for land weight. Will I have to upload each object in my building as a seperate mesh just so that each object can have it's own LoD options set? For ease I would hope I could upload it all as one, I know the limits of 8 textures and such, but it seems just for better control I should upload each object seperately. This is aside from cutting up the larger meshes, which might not need to be done, since the only large mesh with a large view distance too is the building itself, walls, floor, and cieling. No matter it being one upload, or what I set the LoDs to, the smaller meshes in the scene still have small view distances. If I was to upload each object seperately and create seperate LoD levels for each than would that be better? Could I essentially still create my LoDs using my whole scene even if it has seperate objects in it?

I am not new to SL or to blender but the issue of detail levels and view distances has crippled my brain. On top of that I have been having trouble with patience and would like answers now so I am sorry if I am asking questions that only I can answer with some testing on my own time. I don't want to ask to much of anyone here.

Once I have this whole build process figured out for myself and working I would love to compile what I have learned so others may not have to spend time asking questions that I have. Thank you to those who have answered any questions since I have been askign quiet a few. I think I am finally, slowly, understanding what I will need to do. I hesitate only because it seems like it will be a very long process of uploading once I even have the mesh done in blender.

Link to comment
Share on other sites


Syle Devin wrote:

I have heard that objects in a mesh are not viewed as different objects. The problem I have is that in my .dae scene the different objects in that scene are viewed as different objects in the SL viewer.

Correct. A scene is not a model, it's a collection of models. If you want several objects in Blender as a single object in SL, you need to do the opposite of what we said earlier. You need to link the objects in Blender. I don't know what button to click to do that, but I assume you do. One object in Blender is one object in SL. Ofcourse this means that besides LoD switch distance,  LI will go up aswell.

 


Will I have to upload each object in my building as a seperate mesh just so that each object can have it's own LoD options set? For ease I would hope I could upload it all as one, I know the limits of 8 textures and such, but it seems just for better control I should upload each object seperately.


 

I think Drongle figured out how to make LoD scenes. I never tried it myself, neither did I read the post(s) on it very carefully. What I got out of it was the order of objects needs to be the same in each LoD scene, which makes sense, that way they will correspond in the dae file and SL can match them in the upload.

 


If I was to upload each object seperately and create seperate LoD levels for each than would that be better? Could I essentially still create my LoDs using my whole scene even if it has seperate objects in it?

Seperately will work, I don't know what will take longer though. Uploading all objects seperately or matching the objects in the diferent LoD scenes as described above. One thing I need to add is the LoD scenes from Blender won't show at the same time in SL, distance and size will always determine the LoD. With this in mind, it might be best to upload as seperate objects, especially when sizes vary from very small to very big. Either way you'll need to find the optimum for each single object.

 


I am not new to SL or to blender but the issue of detail levels and view distances has crippled my brain. On top of that I have been having trouble with patience and would like answers now so I am sorry if I am asking questions that only I can answer with some testing on my own time. I don't want to ask to much of anyone here.

Once I have this whole build process figured out for myself and working I would love to compile what I have learned so others may not have to spend time asking questions that I have. Thank you to those who have answered any questions since I have been askign quiet a few. I think I am finally, slowly, understanding what I will need to do. I hesitate only because it seems like it will be a very long process of uploading once I even have the mesh done in blender.

Asking these questions is what the forums are for, don't be shy. The more you ask, the more you'll probably understand and the better your own findings will be when you post your "answers".

 

Drongle made some graphs for LoD switch comparing size and switch distance I think. You might want to take a look at that for creating your models. They won't offer you the final answers, but could guide you in the right direction for each model.

Link to comment
Share on other sites

Please feel free to ask as many questions as you need to, Syle - that's what this forum is all about... combined learning and sharing of our mesh knowledge. Your questions are no doubt ones that other readers of this forum have as well, so I would bet that many will benefit from questions you pose and answers you receive. So please, keep asking questions and others here will be all too happy to answer.

:matte-motes-smile:

Much of what you mention in regards to learning Land Impact costs and the effects of LODs is something that tends to come with trial and error - once you have a bit of experience from testing, you tend to get an instinct for how it works / where LODs are likely to swap, etc.
For me, when I was in my early mesh testing phase (during the beta period) and wanted to figure out when LODs were likely to swap at what size, I created a relatively simple mesh object, with each lower LOD mesh designed so as to be easy to spot when they changed (ie: distinct shapes for LODs 2-3-4). I then rezzed this mesh, created a set of prims as markers at regular intervals, and then scaled this mesh up and down, camming in an out for each iteration, so I could get a good idea of when the LODs would swap. It wasn't a technically perfect scientific experiment by any means, BUT it helped me get a bit of an instinct early on as to how LODs behave at different sizes etc. So mayhaps this idea could be of help to you as well - purely as a method of helping you develop an instinct for LOD swapping in regards to size/distances.

For objects like your cash register, you could possibly try having the main mesh for LODs 1 AND 2, and then create lower detail meshes for LODs 3 and 4. It might help with maintaining a better level of detail control, without having a huge impact in Land Impact overall (it will still be higher, but not majorly so - the biggest factor for smaller objects are the lowest LOD meshes' complexity (if I remember correctly!)). Your other idea of combining multiple smaller objects into the one mesh is a possible alternative, BUT I would think it would result in a significantly higher Land Impact cost - due to the LOD changes being made at a much longer distance than would be the case for these objects individually, and your LOD1 mesh would be relatively high in detail as well. I guess the best bet is to try it out, and see if the Land Impact cost is acceptable to your target or not.

It's mostly a matter of deciding what level of Land Impact cost is acceptable to you for each mesh element, balanced with the level of quality you want to attain. Lowest Land Impact isn't necessarily the ONLY goal to consider - rather, it's an element to consider in your overall design. The fact that you WANT to achieve a good Land Impact cost AND have a good looking result shows that you are someone who definitely cares about your project's SL performance - and that is a GOOD THING! So you can definitely be proud of what you are aiming to achieve.

:matte-motes-smile:

Link to comment
Share on other sites

Two things matter for LI (assuming download weight is the highest). They are mesh complexity (numbrer of vertices and triangles etc) and object size. The Collada file size is not a reliable indicator of the first and unrelated to the second. Which LOD mesh is the important one for LI also depends on object size. Here is the thread Kwak mentioned with graphs and maths. That is just for interest. There is no need to underestand it in detail.

Uploading multiple separate objects in one Collada file can be very useful because it maintains the relative positions of all the objects, avoiding the need to assemble them accurately inworld. It can also make significant savings in upload fees. However, there are a couple of problems that you may be running into.

If you use LOD meshes generated by the uploader, the mesh simplification is applied to the whole assembly, not separately to each object. That can result in quite inappropriate LOD msehes with severely messed up small objects. Using the generated LODs on single objects is already quite bad, but with multiple objects this makes it even worse. So with multiple objects, it is even more highly recommended to make your own lower LOD meshes. This gives you complete control over what reductions are made to which of the component parts at each LOD step. The generated LODS are useful for prototyping and testing the effects of different levels of vertex reduction on LI, but they are not the best solution for final models other than largely  rounded things like rocks.

However, supplying the lower LOD files brings up the second problem. The uploader has to decide which object in the lower LOD multi-object scenes corresponds to which object in the high LOD scene. At the moment it seems to do this by using the order that certain sections appear in the Collada file... first at low LOD corresponds to first at high LOD etc... That order is determined by the Collada exporter, and it is not always obvious how to control it with particular exporters. With Blender 2.49b, at laest, it is the alphabetical order of the Blender object names. So as long as the corresponding objects are named so that they have the same alphabetical order, the different LOD files will work as intended. If you keep the LOD models in the same Blender file*, this can be achieved by using a suffix for the LODs of the same object (xxxx_hi, xxxx_me, xxxx_lo, etc). I am not sure of the situation with the integrated exporter in the later Blender versions, but now that Gaia and Domino are involved, I am sure it will be sorted out in a useful way.

The multi-object upload results in a linkset object if it's small enough, otherwise a coalesced object. Either can be rezzed with all the components in their original relative locations. In either case, the objects still switch LODs independently. Although you describe this as a problem, it can actually be an advantage if the LOD meshes are designed to take advantage of it. Thus you can have small objects with high detail switch at closer distances because their detail becomes invisible earlier. As long as the lower LOD is made to retain the larger shape, this should not lead to unpleasant effects. If you use the generated LODs, however, it probably will. If you want bto suppress LOD switching on a particular component at one level, you simply leave it unchaged in the two LOD models.

*using export selected toggle to export them separately.

 

  • Like 1
Link to comment
Share on other sites

Can't believe I didn't think of that. I know that leaving the model the same for a different level gives it a longer view, distances or an unchanged one, but I did put it together with the whole scene.Also Drongle I was thinking if I had seperate LoDs for each object in the scene how would it know which object it is for but you answered that out for me and I didn't even ask. :P Thank you.

I mainly didn't realise that I could have an unchanged mesh for a specific object so that it will have a longer view distance. I think now all my questioned are answered for a while. That is until I get to working on the physics mesh and then I will need to do what to do so that each physics mesh is linked to the appropriate object. Would that work the same was as LoDs would? Alphabetical order?

I check out your build Maeve. It looks great, shows me what can be done with LoDs. I thought it would be annoying for it to change but from an avatar distance nothing changed drastically so it wasn't an issue. Not until I zoomed out did anything really change. That looked good, hopefully I can figure it out but your build gives me ideas of how I can do it. One question if you don't mind. I saw the building below the one you linked me to and you had a block on the ground with a shadow underneath. Did you do that with texture only or was it baked to show the shadow? I am just curious since I didn't really see any othr shadows.

 

Also, drongle, is there a good way of going about naming object in blender? I mean a way that is faster than clicking on each object and changing the name, a list of sorts even? I've never been one to name my objects in blender, I have never needed to before, so I haven't learned much of a good way to name them.

Link to comment
Share on other sites

I'm glad that my work-in-progress has given you some build ideas, Syle - Ask me any questions in regards to it, if you need clarification of my techniques.

One question if you don't mind. I saw the building below the one you linked me to and you had a block on the ground with a shadow underneath. Did you do that with texture only or was it baked to show the shadow? I am just curious since I didn't really see any othr shadows.

Ah, are you referring to these tiles sitting on the floor? (Pictured below, the one on the left of my AV)?

Floor tutorial 5.png

If so, that shadow is simply a textured two-triangle plane underneath the tile (part of the SAME mesh object - there are (I think from memory) SEVEN of those tiles scattered around the floorspace - all of which have this shadow plane effect, and ALL of them are part of the SAME MESH OBJECT. (Note: the underlying FLOOR ITSELF is a totally separate mesh). If I remember correctly, this mesh object (7 tiles with shadows) had a Land Impact of 4 - the highest cost was due to the physics, due to me wanting AVs to be able to step onto them etc, instead of walking through them... if the mesh didn't have physics, it would have been about 2 Land Impact (due mostly to the size, since the tiles were scattered across a relatively wide area - the large size was intentional, due to me wanting the tiles to maintain their original LOD over a large floorspace area). With the benefit of hindsight, I could probably have reduced the physics cost a lot more by using a properly optimised hull (I was lazy at the time, and just used the LOD1 mesh for the physics in the uploader).
The shadow texture itself is a simple Photoshop job - a black square with a lot of gaussian blur applied to simulate Ambient Occlusion shadow, with associated alpha channel for transparency. This texture was repeated for each tile shadow in the mesh. I guess this is a good example of how mesh can be very useful for replacing the old style shadow prims for very little cost.
IMPORTANT: The shadow planes I isolated to their own, specific material - this is CRITICAL due to the shadow textures containing an alpha channel. If you applied this effect as part of a single, all-encompassing UV texture, the ENTIRE MESH would have alpha glitching. So for any textures in a mesh that require an alpha channel for transparency effects, I strongly suggest isolating them to their own, SEPARATE UV textures and associated mesh material (within the same mesh object).
Note that this particular build (the one below the project I linked you to) is an abandoned construction now - It was an early learning experiment, from which I have now developed more efficient mesh ideas that I am exploring in the build immediately above it.

A little off topic, but since you have seen the floorspace there - I posted THIS explaining my method for texturing the large floor areas without having obvious repetition; something you might be able to get further ideas from, if it helps.

:matte-motes-smile:

Link to comment
Share on other sites


Syle Devin wrote:

is there a good way of going about naming object in blender? I mean a way that is faster than clicking on each object and changing the name, a list of sorts even? I've never been one to name my objects in blender, I have never needed to before, so I haven't learned much of a good way to name them.


Can't answer your wuestion directly, but I can tell you it's an absolute must to name all your items in a 3D scene. There are tons of reasons for it, especially when the scene is big, but the thing you just encoutered is another good reason. In general you can say it's needed to be able to identify the objects, whether it's by you, a modifier of the 3D application or an exporter.

Link to comment
Share on other sites

"is there a good way of going about naming object in blender?"

Well, they get named automatically if you don't name them, Cube, Cube.001, and so on. Those names are not very helpful when you come back a year later to modify something. They don't work for making different LODs in one file, because the number suffix depends on the order of making them, which is unlikely to be the order you need them exported in. So as Kwak says, it is very good discipline to always make sensible names for everything. Like you, I am too lazy and often forget, only to regret it later.

Worst of all, in Blender 2.49b, the high LOD object name becomes the name of the object in SL (usually with "-Goemetry" tacked on). So my inventory is full of things like "Cylinder-007-Geometry", often a dozen with the same name, and I have no idea what they are. Don't be like me. Invest in naming everything properly and you won't regret it.

Unfortunately, there is no alternative to typing them that I know of. Maybe someone will write a clever script that automatically gives them an informative name based on the file name or something, but until then we will have to suffer.

 

Link to comment
Share on other sites

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

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

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
 Share

×
×
  • Create New...