Jump to content

Physics model issues - High poly model creates larger physics bounding box. [Solved Sort Of :D]


Chic Aeon
 Share

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

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

Recommended Posts

So I made a fairly low poly for what it is dropped drop cloth. Much higher poly than I usually make but it still isn't smoooooth of course. Anyway, I have the upload and LODs working fine but I can't get the physics model (OR A CUBE) to cling to the bottom of the model. 

 

I applied location, rotation and scale and transformed origin to geometry on both the cloth and the physics model. The physics is "fine" once the cloth is in the ground, but it rezzes a bit higher than ground level -- much like a lot of sculpt items of old.  I haven't seen this issue before but I haven't made anything like this. So hints appreciated.   I could find no difference between analyzed and unanalyzed physics. 

Thanks.

 

Link to comment
Share on other sites

The physics gets stretched to the extents of the bounding box (bb). So it looks like there is some extra, invisible geometry there in the visual mesh, that extends the bb. Would have to see the dae file to see for sure. What package did you make the cloth with, and how was it exported? There could be differences from either. Are there means to setect stray vertices etc?

Link to comment
Share on other sites

No stray vertices. Looked and looked -- especially where they would need to be to make the bounding box go below. Moved cloth to an unused and empty layer. Still nothing there. 

 Made totally in Blender using the cloth modifier. Exported as DAE file.   Hope that answers the "package" question.  :D. Thanks. 

Later note: I added a single vertex to that layer JUST to make sure I was looking for the right thing. That shows up well and brightly and I have all layers on.  But I can't see anything else.  So no clue.  I may just have to live with it. Thought maybe that I needed to use planes instead of a full shape because of all the curvy geometry. I will try that but have no great hope. [Nope, same issue.]   Moving on I guess.

 

 

Link to comment
Share on other sites

One more observation from the day.  I tried a SINGLE plane for the physics model (obvious not the best choice but I wondered).  In my first test, the plane showed up more or less in the middle of the dropped cloth -- so "better" location wise than the cube or custom physics model.  But when I uploaded, it STILL rezzed above the ground. 

 

The second time I tried (beta grid) the plane wasn't visible in the uploader so not sure what happened there. Guess I will go with the rezzing high but working choice :D.   

Link to comment
Share on other sites

So I went over to test to see if something was going to be toooooooo "primmy" and look what happened.  I tested something that I made yesterday that was lower poly but did have cloth (hence modifer) in it. It was fine. So not an overall uploader issue. Might be an issue with higher poly mesh in general?    Since I am usually a lowpoly gal, I wouldn't know.   

 

Any other ideas are welcome :D.

 

 

IF I move the origin to the geometry (I forgot in the first example), THIS is what I get. I haven't changed scale in the uploader.

 

 

I did a bunch more tests, making a thinner (hence much lower poly) version. It uploaded as expected -- no matter if I had adjusted rotation, location and scale OR put the origin point in the middle of the geometry.   

 

So it looks to me like the uploader is not happy with the higher poly mesh.   

 

The original drop cloth was 3 land impact with long distance LODs (even at 1ish) at 1.5 meters -- so not THAT high poly.

 

 

Link to comment
Share on other sites

Of course didn't know that was there :D.  Bounding boxes match and appear to be where they should be.  Its that pesky physics shape that is rezzing it higher than the ground.     See other posts on my testing. Seems to be a higher poly issue. 

 

 

 

 

Link to comment
Share on other sites

 

This is what happens when I create a cube in Blender and subdivide it so that it has 24,500 vertices (no materials assigned).Then in edit mode move the cube away from its origin.

 

This is how it appears in the Uploader (using the official SL viewer) with a simple cube used for Physics:

and when rezzed inworld:

 

If before exporting I Set Origin to Geometry at step 4 (first image) then the cube (and Physics) work as expected.

Repeating steps 1 to 6 for a cube which has only been subdevided 5 times (6,146 vertices) then it uploads as expected

 

 

 

Link to comment
Share on other sites

 This appears to be another issue with collada files referencing geometry in <polylist> attributes, rather than <triangles>.
Like the split materials above 21k faces bug. As I can't repro it with dae files with <triangles> attributes, but <polylist> does..

Probably worth filing a Second Life jira about it.

Link to comment
Share on other sites

I've had no problems with this kind of thing, as this cloth shape is similar to my 'terrain' or 'aquascape' shapes. I didn't try to use complicated physics shapes though, just a couple triangles, and set the uploaded mesh physics shape to the PHY.dae I used, with no analyzing.

Link to comment
Share on other sites

Ahhhh. OK.   Yes, more things uploading today go along with that. I am going to try one more "trick" and see if I can work around.       

 

Well that didn't work LOL.    I tried making a long word into a two MATERIAL long word rather than dividing the word.   The uploader wouldn't recognize the file. "missing detail".   Note: After reading your message again I see that it doesn't appear to be "that" bug but one similar.   I will try dividing the dropped cloth into two sections and uploading as a linkset and see if that works around the problem. At least I know it "wasn't me" -- simplistically anyway. I DID make that mesh *wink*

 

BUT I do understand what's going on now so that is VERY good. Thank you. I hardly ever make high poly mesh and I almost always have more than one material. Hence this hasn't showed up for me before.   I can either upload in pieces or as a linkset and that will likely work fine. 

 

THANK YOU ALL!!!   Lots of good info in here for the future. You know I "knew" about that number per material thing but since it has never happened to me, it just wasn't computing. 

 

Just some screenshots I took that make the differences obvious for those reading this thread later.

 

Link to comment
Share on other sites

ONE MORE TRY.

 

I have had FOUR long informative posts disappear now. Not going to redo them all. Hopefully the people they were meant for saw them. Guessing some major issues on the forums today and who knows what "I" missed reading also. 

 

The ANSWER is that you can divide the high poly mesh into two (or more) parts and upload as a linkset and that solves the problem.

 

Photos.  

 

 

 

Link to comment
Share on other sites

Mine was only (ONLY) 30000 ish :D.   Oh well.    The "phong" thing seems to have been fixed as I didn't have to do anything tricky the last time I made transparent wine goblets, so maybe this will get fixed someday.  Since I rarely do high poly it likely won't effect me much or often. 

Link to comment
Share on other sites

I did a few experiments, with results that surprised me a lot. It's not just physics. At least with a mesh cube which has abour 27k triangles, so that there is a secret second material made, the transformation calculations are affected in such a way that the origin is now included in the bounding box, although there is no geometry there. (In fact it's a little more than just the origin). So even if you just upload a 27k cube 2x2x2m after moving the geometry 3,3,4 m in x,y,z, and use default LODs and physics, you get this large bounding box, 4.5x4.5x5.5m, with the actual cube in one corner, with the pivot/origin outside the geometry. Because of that, any uploaded LOD or physics gets expanded to this bounding box. So it's the maths that's supposed to shift the origin to the center of the geometry that fails after the material split. I haven't been able to find out where this happens in the source code yet. Anyone know if there's already a jira for this?

Link to comment
Share on other sites

OK. Aquila (hope I spelled that right) did something of the same thing. I can't say I understand you completely but that isn't new LOL.

 

That was NOT my problem as far as I can see and I wrote back to Aquila with photos but whatever was going on that day I had four LONG posts with explanitory photos disappear. 

I had as always applied location rotation and scale -- and moved origin to geometry.  My bounding box was fine. Here is the photo again and maybe it will stay this time (I am assuming some big database issues that day). 

 

 

What I don't understand is that the VERY SAME piece of cloth (a subdivided plane of course) was used on another project (same size) with ADDED geometry as it had a bench too. It uploaded fine.

 

My issue obviously has something to do with triangle count --- or does it? The bottom photo was a higher poly upload and acted just as normal.  The dropped cloth was somewhere around 30,000 so I am guessing the bench would be a bit more. It is fairly low poly. 

 

Hope this posts STICKS. That was a tough day trying to document and having things repeatedly disappear :(.  

 

 

Link to comment
Share on other sites

Let me offer a more precise definition of the effect (bug) ...

If a material in the high LOD mesh gets split into more than one material because (a) it is specified in a <polylist>, and (b) it has more than 21844 triangles, then the bounding box will include the unit cube (1x1x1m) around the origin of the coordinates in the collada file, irrespective of where the actiual geometry lies with respect to that origin.

This causes the behaviour shown here by Aquila. It also explains the effect on the physics of your cloth. That had more than 21844 triangles, and was therefore split into two materials. Consequently, it's bounding box will stretch at least 0.5m from the collada (Blender) origin in each dimension. That goes below the bottom of the geometry. Then the physics shape is stretched to fill that bounding box. It doesn't matter that the origin is inside the geometry; the effect will still happen if the mesh is thin enough in one dimension (z in your case). In the larger mesh, which includes the bench, the offending unit cube is entirely withing the bounding box of the geometry, and therefore has no effect.

Still looking for it in the source code. Should be easier with the better definition.

Link to comment
Share on other sites

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