Jump to content

Uploading mesh: variable Upload and Physics costs with no change in models


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

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

Recommended Posts

Posted


I've been working with a mesh house model, making a matching mesh physics model. Tweaking and changing and trying get a better handle on how things work. My starting model was made by a friend, a dae file from Google sketchup. When I read it into Blender, it seems to have a bit more than half the verts duplicated, and I do not like the details of the mesh made by sketchup at all, but I am working with that model "as is". I needed to add a roof, and gin up a physics mesh, using a set of planes to delineate the floors and walls. I wanted to see what happens if I tweek the physics mesh, to see if I could change the physics cost for upload.

But, if I take exactly the same model mesh and physics mesh, and repeatedly calculate the upload costs, I get a different answer each time. Here is what happened, first using Firestorm, next using the most current SL viewer. I pushed the same buttons in the same sequence each time and made no changes to the dae file for the model mesh or the physics mesh:

FS:
$L DL PH
13 11.150 4.72
13 11.076 4.56
12 12.593 4.72
SL:
13 13.640 4.64
13 12.936 4.72
13 12.636 4.56

I rezzed the model in world, saw there were some normals misplaced on the roof, and realized I had not joined the roof and the house to make a single mesh. I fixed the normals, joined the roof, and tried again (no changes to the physics file)
SL:
12 12.699 2.440
12 12.727 2.440
12 12.540 2.440
FS:
12 15.365 2.440
13 15.092 2.440
12 15.230 2.440

????!

So, my questions are, why are the upload and physics costs variable when there are no changes at all? How can tweeking the model mesh, but not touching the physics mesh, reduce the physics cost nearly in half? And how can the physics cost vary for one model mesh, but suddenly become stable when that model mesh has been tweeked, with no change to the physics mesh? And why shoud it make a difference to upload costs using FS or SL viewer ... I thought the DL and physics costs were caluclated by the server?

 

Posted

A couple of questions...

1. Did you provide LOD meshes, or did you let the uploader generate them?

2. Did you specify a physics mesh? - if so, from a LOD or from a file?

3. Which buttons did you press on the physics tab?

4. Are these figures from the downloader, or from inworld?

5. If it was inworld, did you change the physics shape type?

It will be easier to suggest what's going on with answers to these. Meanwhile, the LOD generator is non-deterministic, meaning it can produce different results on different occasions with the identical input. Thae differences can affect the download weight. O don't know, but perhaps the LOD generator is different in FS.

Then, the default convex hull physics shape, which is what you see the physics weight of in the uploader, is made from the low LOD mesh. If that is different, then the resulting physics weight can be different. Changing the mesh could produce less variation in the vertices that make up the convex hull, even if the detail of the low LOD is still varying.

To have consistent and optimal  control over the weights, it is usually necessary to provide LOD and/or physics meshes explicitly, rather than relying on the automatic options.

Posted

I can verify this happens even with NO changes to the dae when uploading. Using your own dae file for physics, same size and same (more or less) LOD settings (sometimes they stay the same and sometimes they will shift a bit for no apparent reason). Sometimes the very same file even can give different results. This on Aditi where I have pretty much lived for the last three months. AND I also agree that there are differences between FS and LL viewer numbers.

 

EDIT: I do not use LOD daes. I get great uploads at .5 and 1 with really good LODs without them. It may be what I make -- so that is SOME of the difference.  If you use the linden viewer for Aditi and then upload at Agni, it remembers correctly by putting a .slm (I think that's it) file in your computer. Easy to spot those. In that case things stay the same.

I know that FS is not using the latest version of the uploader that is in the LL viewer. This from a LL tech guy. So presumably that has a lot to do with it. Lately I have ONLY been able to upload on Agni using the LL viewer (FS work fine on Aditi for me most of the time). So there are changes always happening and I think if we get TOO caught up in the fine details the frustration is just too much. So now I just accept the slight differences.


And, honestly, trying to figure out what is going on by fiddling (and I hear ya on this) will only get you so far as things with the uploader and the physics seem to change readily and often. It's a go with the flow thing -- especially when physics are involved.

Posted

Hi Drongle

To answer your questions:  

1:  no LOD meshes supplied, the uploader generated them

2: yes, I had the same physics mesh in a .dae file, and used it for each calculation listed above.

3: On the physics tab I just chose to get the physics from file, and pointed to the same .dae file each time.

4:  The figures are from the downloader, on the beta grid.

5:  I loaded the model inworld only once, and changed the physics shape type to prim.  The physics mesh did just what it was supposed to do.

Non-deterministic up LOD generator would certianly explain the variation of upload costs.  And that is what was really bothering me, I like it best when my computer produces the same gargbage out for the same gargabe in.  I noticed something similar last month, on a different group of models I made myself.  SL was always quite reproduceable, both DL and Phys costs, and always a bit cheaper, both in $L and DL, than FS.  But they both got the same physics cost every time.  The present model is the first where I've seen both DL and physics costs varying randomly.

Posted

Thanks Chic

I guess there was a certain element of "is it just me???" to my OP, thanks for verifying my sanity!

"go with the flow", sounds like good advice here.

:-)

 

Posted

Yes. I guess it's the LOD generator for the download costs then. However, if you were using an explicit physics mesh, the uploader should use that mesh to make the default convex hull whose weight it shows. In that case, the LOD generator isn't involved in the physics shape, and so the weight should be always the same, as with the second mesh. So I can't explain variation in the physics weights for the first physics mesh.

Posted

You asked before if it was in world, that made me curious.  So, I went back to the test grid, uploaded the model and rezzed it 3 times, using the current LL viewer.  I now have identical objects with LI 12, 14, and 16!   (I did not rez 6 or 8 other attempts, that rounded down to 12 LI).  

I do think there is something a bit squirley about this model -- what with all the extra verts and all.  I've seen small variation in the upload costs before, but nothing nearly this large.  At least now I know to blame the LOD generator, and try not to get fooled by the "noise" when I am tinkering with my meshes.

Posted

"blame the LOD generator"

Yes, but there's another possible cause for this sort of effect, and another question I should have asked too. Did you have UV map? If yopu don't have a UV map in the dae file, the uploader seems to use uninitialised data for it. That can be have quite large effects on the download weight because it increases the vertex count when the same geometric vertex has to appear with different UV coordinates for different triangles. How big the effect is depends on how much vertex dupliocation you already have from sharp edges (same vertex with different normals), and on exactly what the uninitialised data is. You can see the effect by applying a texture.

Posted

Ah, another reason my friend should bite the bullet and learn blender.  No UV maps with the sketchup dae file.  

In my short career learning mesh I've encounterd several friends who said, "i'll worry about learning UV maps later", and are then shocked to see what happens when they try to texture it.  Hehe, I did it myself.  Now I start working on the UV map as soon as I start designing the main mesh.

Posted

LOL. Really had to laugh at that one. While folks that can do great photoshop work shine in the finished product, the person making the maps is definitely king or queen in my version of the BlenderUniverse :D. Most of the time I spend MUCH more time on the mapping than on the making.

Now and then the generator wtth a few well placed seams does a great job and I clap and clap -- but MUCH of the time it is a puzzle why they put part of one piece  at the top of the map and the other at the bottom. Then of course comes the map it by bits and pieces (if you didn't already start out that way). Eventually you get a map you can align and weld and that looks good.

It DOES look pretty though when those bakes start appearing on the finished mesh model.

 

And don't forget the multiple textures on one object. I "almost" have that down (sigh). One of the most difficult things for me to get in my head.

I am not sure if the changes I have noticed were before or after mapping. I'll have to watch for that. I frequently upload before mapping to make sure the basic model is OK. So that might be the answer. And I do like answers.

You are about to reply to a thread that has been inactive for 4322 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
×
×
  • Create New...