Jump to content

Recent Uploader PhysX Calculations versus Rezzed Object


Sabanco
 Share

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

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

Recommended Posts

Hi there.

Since the last Server Rolls (with the Old Viewer on 12/10/14) and later with the new Viewer Update yesterday, there is a slightly difference between the physX calculus of my mesh and when I do rezz it on the land and change the shape to Prim.

I was working on a little house for a friend of mine. Low Poly and Lower Poly PhysX. The Uploader shows me 1.240 Li of the whole thing, PhysX 1.240, Download 0.266. When rezzed it has one Prim. When I change the Shape to Prim = up to 27.

I tried it a couple of times with different Objects, PhysX Objects and different Specs for the PhysX Uploader Tab.

I had all the tested Things already uploaded months before, so I could compare them.

I use Maya or Blender. Nothing changed there.

 

Anyone else having that issues now?

 

-Sabs

Link to comment
Share on other sites

Are your physics shapes hull-based (Analyze clicked") or triangle-based (no Analyze")?

Simple things first. The physics weight you see in the uploader is the weight for the default physics you get when you set the type to Convex Hull. That is a single convex hull for the whole object (Low  LOD by default). You can't see the Prim type weights until you upload and rez the mesh. Jiras requesting that the uploader display the Prim type weight were made a very long time ago, apparently to no effect. If the physics is triangle-based, it is dependent on the size of the object, and will change if it it stretched or squeezed.

Now for more complicated issues...

For triangle-based shapes, I did an extensive analysis (links below) of the physics weight. The outcome was to show that the physics weight was hugely dependent on the order of the triangles in the uploaded collada file, and on the order of vertices within the triangle(s). I could not find a universal method of optimising that order. This was all done by manual editing of the collada file. Authoring programs, and their exporters, do not generally give you an explicit way of setting these orders. So the physics weight becomes highly variable and unpredictable for identical geometry when it is constructed and/or manipulated differently. In general, the "same mesh" could give very different weights unless you used exactly the same collada file.

Now, the uploader doesn't upload collada to the servers. It converts the data into an efficient internal format first. Changes to that process could certainly affect the order of triangles in the uploaded data (to be more precise: could change the effect of the collada order on the structure of the uploaded data). So changes to the resulting physics weight could happen as the result of changes in the viewer code, even if you use the same collada file. I am not aware of any such changes, but I haven't been looking for them.

Since the physics weights are calculated by the server, it is also possible for changes in the server to change the weights. Indeed, it's even possible that the server could have been changed to eliminate the inconsistencies I documented (although I doubt the because the jiras I submitted were dismissed). However, in that case, as triangle-based weights are recalculated whenever an object changes size, the weights of previously uploaded objects would change too. LL are usually very reluctant to make changes that affect existing content.

The situation for hull-based weights is much simpler. They don't (generally) change with size. The calculation specified in the wiki is incorrect, but an alternative is used consistently. However, the "Analyzed" hulls are made by a third party library used by the viewer. So if that changed, the physics weight could change with a new viewer, as an identical collada file could produce different hulls. Also be aware that the results may be different unless all the settings on the physics tab are identical and any changes to their defaults were made in the same order. I guess the calculation on the server could have been changed too, although my jira for this was rejected, and I would say it's the wiki documentation that's wrong rather than the calculation.

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

Here is the triangle weight story, four episodes....  Episode 1  Episode 2  Episode 3  Episode 4

 

Link to comment
Share on other sites

Yes thank you. I am not new to the uploader and to mesh nor 3d nor whatever. something changed on the servers.

I was asking if anyone else might have this problem. A clean install ist not so often a solution to any occuring bug in sl. A few days before I was oploading a chair with its more or less complicated physX. It worked out as every time before. But this time from the 10. on I'm having this issue. Not so nice when trying to make a christmas gift for a friend :(((((((((((

Anyone?

Link to comment
Share on other sites

A clean install ist not so often a solution to any occuring bug in sl. ??? Did I suggest it was ???

I found you jira and used the dae files you put there. I did the following with currrent SL viewer and on two servers; beta grid, 296624 (older than yours)' main grid 297277 (newer than yours, which was 296988 in the jira). Results were the same on both servers.

All three: Upload with default auto-generated LODs. Rez at uploded scale (at least one dimension < 0.5m). Set physics shape type to Prim. Scale up to all dimensions just greater than 0.5m. Note physics weight (More Info from edit dialog). Scale up to about 10m X dimension. Note physics weight.

Three versions had different physics: A=your physics mesh, not Analyzed (triangle-based); B=your physics mesh Analyzed with all default settings (hull based); C=removed all narrow triangles from edges of your physics mesh (84 of 136 triangles left; still some redundant triangles, could be fewer), not Analyzed (triangle-based).

The Analyze in C produced 72 hulls with 272 vertices. These numbers are large because the uploader does a bad job decomposing a mesh like this into hulls. The physics weight is roughly 0.04 x (number of hulls + number of vertices). For these numbers, it is expected to be about 14. Inworld, the Prim type physics weight for this is 15, independent of size, which is pretty much as expected.

Using your physics mesh without Analyze, to get the triangle-based shape, the physics weight depends on size, as expected. As long as at least one dimension is less than 0.5m (which it is as uploaded without a scale factor), the server secretly treats the type as Convex Hull instead of Prim, and the physics weight is correspondingly low. As soon as one dimension exceeds 0.5m, the triangle-based shape gets used, and the physics weight at that size is 28. As expected for triangle-based shapes, it decreases as the house is stretched to a larger size, until at about 10m it is 1.7.

Using the alternative physics mesh, with the narrow triangles removed, the physics weight at just over 0.5m is 13, decreasing to 0.7 at about 10m.

All that seems to me to be completely normal behaviour for SL.

You didn't say whether you used Analyze or not. If you did, the high weight is because the decomposer that turns the mesh into a set of hulls does a very bad job with the kind of mesh you have given it. Looking at it by hand in Blender, it should be at most 14 hulls with 72 vertices. That would give a Prim type weight of 3. Usually, the only way to get the uploader to do this is by simplifying the physics mesh so that it already consists of the hulls you want, with none of them connected or overlapping.

In the case of this model, assuming it's scaled to about 10m, you are better off anyway with the triangle-based shape, Even with the narrow triangles left in, that gives you a LI of 2. With them taken out, it drops to 1. Removing the narrow triangles is a good idea because it reduces the work for the physics engine while making no practical difference to the collision behaviour, as well as reducing the physics weight.

As far as the question whether anyone else has seen this: by looking at your model, I haven't seen anything different with server versions with version numbers either side of the one used for your jira report. That doesn't necessarily mean your server version was not different though. Changes can appear and then be reverted. In the versions I tested, I did not see any unusual behaviour. It is also possible that a different viewer version may use a different version of the decomposition library giving different results for the hull-based shape. I was using Second Life 3.7.22 (297128) Dec  1 2014. Yours was later (Second Life 3.7.23 (297272) Dec 5 2014). I don't know why mine didn't auto-update yet. Do you get the same hull/veretex counts if you Analyze? 

Link to comment
Share on other sites

You said: All that seems to me to be completely normal behaviour for SL.

A few weeks ago I uploaded a lot of houses with different physics shapes. Some of them use only boxes, others more accurate physics shapes. None of them hughe buildings and parts reacted like this. 15 Li for this little piece is absolutely inacceptable. As I wrote: this building is old. I already uploaded it a few times in the past. And it went all good, not like now. What I also wrote: I tried it with different settings, different objects, old objects, new objects, used Blender and Maya to determine if my converter, my scene, my object is cranked up or not. Did a restart of my pc, checked my internet. All the testings were not good enough and also the older buildings I uploded, had not the same Li as before.

Link to comment
Share on other sites

I always wonder why people uploading a mesh more than once. Even more so when they claim they did not change a thing on it.

Also your thread title is kind of missleading. PhysX is a physics engine owned by nVidia. Second Life does use the Havok physics engine though. So you would be better of by referring just to a Physics Shape, or Collission Shape to begin with.

Anyhow, to answer your initial question. No, I haven't seen different behavior for the same objects upload years ago and today, which I just tested.

Link to comment
Share on other sites


arton Rotaru wrote:

I always wonder why people uploading a mesh more than once. Even more so when they claim they did not change a thing on it.

Well, reuploading the same mesh adds a little bit of lag to SL since it means more mesh asset models and it can help reduce the balance of your L$ account. But in either case the effect is so minute you're better off trying some other methods if that's what you want.

(Edit: Serioulsy: if I understood Sabanco correctly, what he did was reupload some old files just to see if they gave the same result as they did the first time and that makes quite a lot of sense in a case like this.)

Something did change in the way physics weight is calculated in SL a couple of months ago though - or more like a year or something, can't remember exactly when. Some of the high LI prim shapes suddenly dropped significantly in physics weight over night. I know because I had a few heavily twisted toruses rezzed on a parcel when it happened. I don't know if the change affected meshes though and in any case it seems to have been a reduction rather than incrrease of the physics weight.

Link to comment
Share on other sites

There has been a change a year ago, or maybe even 2 years ago already (idk, time flies), where the download weight of prims and sculpts has been clamped to 1, respectively 2 for sculpts, due to a change where LL had removed some hack, where it was possible to set certain childprims phantom. To minimize the content breakage, they clamped the download weights, under meshy accounting, to make it possible to set these former phantom childprims to physics type None, without increasing the primcounts of such builds. (Btw. that's why mesh and prims are still on a different page, even if they are both on meshy accounting.)

Though the physic weights weren't affected by this. LL can't increase the physics weights silently over night anyway, or half the grid would be returned over night as well :matte-motes-grin:. And I'm also not aware of any change to the servers, and I'm almost every week, since a couple of years, at the Server Beta User Group meeting, where new server releases are discussed. So I truly doubt there has been any change to the calculation at all.

Good old prim torus can have still nice physics weight numbers. At least more than a fullsim can hold. This pic I have

taken just a few minutes ago. :matte-motes-sunglasses-3:

Torus_lol.jpg

 

Link to comment
Share on other sites


arton Rotaru wrote:

Good old prim torus can have still nice physics weight numbers. At least more than a fullsim can hold.

 Yes but... ummm... err... I suppose it's safe to come clean now.

One of the other land owners in a sim where I also own some land left SL for several months, leaving the parcel with no autoreturn and wide open for anybody to rez and build. This of course attracted a lot of griefers and since it's in an area with many newcomers, the parcel also started filling up with prims left by people making their first steps towards building not realizing they ought to clean up after themselves. Now, **bleep** shaped particles and such may seem like fun to some but it gets rather boring in the long run. LL refused to do anything about it and I couldn't get hold of the landowner so eventually I just filled up the parcel with high LI invisible phantom prims.

That worked well for a while but one day I found a squatter had taken up residence on the parcel. When I checked, it turned out nothing had been removed from the parcel but my filler sim had suddenly dropped drastically in LI, leaving room for others to rez there again.

Oh btw, I did eventually get hold of the landowner and she agreed I had done the right thing, cleaned out the parcel and fixed the land settings. She's a good friend of me now.

 

(Edit: I didn't write "''bleep**" but it's actually better than the original. Turns out censorship can actually improve a text occasionally :matte-motes-big-grin: )

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 3414 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...