rigged mesh issue on high altitudes

[daFlesh]

hello , I just noticed an issue with my rigged mesh when I was testing it on high altitudes 1000 m or more . its combination of many pieces for alpha cuts

here is gyazo snapshot. I wonder how can I fix that. I use maya. as far as I see there is a solution for this cause some well known mesh bodies dont have this issue

(its not about LOD by the way , I checked it ) 

https://gyazo.com/e5d4f52c76c9bf7e5c51e59539668a29

 

Edited March 2, 2018 by daFlesh

[Anna Nova]

There are a limited number of decimal places allowed in coordinates.  So the higher you go the fewer decimal places of precision you have in the Z coordinate.  This results in the sort of thing you are seeing.

 

[daFlesh]

thank you so much for reply, well okay I am a bit lost. could you tell in other words please,

 how can I fix that for my mesh body. (I m developing a mesh body) I dont see this issue with other mesh bodies in market. they are working fine with high altitudes but

 my mesh body is having that issue.

Edited March 2, 2018 by daFlesh

[Anna Nova]

1 hour ago, daFlesh said:

thank you so much for reply, well okay I am a bit lost. could you tell in other words please,

 how can I fix that for my mesh body. (I m developing a mesh body) I dont see this issue with other mesh bodies in market. they are working fine with high altitudes but

 my mesh body is having that issue.

I don't think you can fix it.  And all builds must suffer from it - for many things you can get away by using the same vertices in a seam, and then they must coincide, but if you have a link-set then the positioning just cant be precise enough at height.  Despite the proliferation of sky boxen, SL is really designed as a low-level platform.

I'm sure if anyone knows how to fix this they will be along shortly.

As for a better explanation, I'm not totally sure I can explain it very well, but here goes...  A coordinate is a vector of 3 floating point numbers <x.x,y.y,z.z>.  As far as the X and the Y axes are concerned they only have to describe a point in the region, 256x256 meters, but for the Z axis there is no limit.  So if you are at 1000 meters, that's 1000 meters-worth of coordinates lost in the precision of the vertical.  I'm not a math whizz, but again, I'm sure there will be one along....

[OptimoMaximo]

This occurrance is due to error accumulation in the floating point range.

Between a value and another, theoretically there is an infinite number of decimals, which a computer must round into value with a maximum amount of decimals (say, 6 numbers after the dot) in order to process them and give a result in a timely fashion.

Now, if the possible values range between 0 and 255 (X and Y axis sim dimensions are 256 meters) you have a limited amount of positional values that, at the scale end value, gives out a neglectable error by accumulation of the truncated values approximation. The Z axis instead has a cap of 4096 meters for prims, but there's no limit to the avatar position. Let's assume an height of 4096 meters, and the imperceptible error we had when we were within the "regular" 256 meters gets up to at least 16 times it previously was.

For my avatar, i came up with something that diminishes this effect, although it doesn't remove the issue completely. Hopefully mesh baking services will let us get rid of sliced avatars.

Basically it's due to the unused joints removal that the Bento project introduced, and you're slicing an avatar. If you make sure that each troublesome sections contain ALL the joints names of the old classic avatar joint list, as it was previously required, this gap effect almost vanishes. 

Side note: this isn't an optimal thing for the asset itself, because you'd be keeping a lot of unnecessary data for a lot of pieces. You should manually remove the unused joints from each piece basing off their actual distance from the slice, and retain only neighboring unused joints.

Edited March 2, 2018 by OptimoMaximo
typo

[Love Zhaoying]

9 minutes ago, OptimoMaximo said:

This occurrance is due to error accumulation in the floating point range.

Between a value and another, theoretically there is an infinite number of decimals, which a computer must round into value with a maximum amount of decimals (say, 6 numbers after the dot) in order to process them and give a result in a timely fashion.

Now, if the possible values range between 0 and 255 (X and Y axis sim dimensions are 256 meters) you have a limited amount of positional values that, at the scale end value, gives out a neglectable error by accumulation of the truncated values approximation. The Z axis instead has a cap of 4096 meters for prims, but there's no limit to the avatar position. Let's assume an height of 4096 meters, and the imperceptible error we had when we were within the "regular" 256 meters gets up to at least 16 times it previously was.

For my avatar, i came up with something that diminishes this effect, although it doesn't remove the issue completely. Hopefully mesh baking services will let us get rid of sliced avatars.

Basically it's due to the unused joints removal that the Bento project introduced, and you're slicing an avatar. If you make sure that each troublesome sections contain ALL the joints names of the old classic avatar joint list, as it was previously required, this gap effect almost vanishes. 

Side note: this isn't an optimal thing for the asset itself, because you'd be keeping a lot of unnecessary data for a lot of pieces. You should manually remove the unused joints from each piece basing off their actual distance from the slice, and retain only neighboring unused joints.

 

[Anna Nova]

15 hours ago, OptimoMaximo said:

This occurrance is due to error accumulation in the floating point range.

Between a value and another, theoretically there is an infinite number of decimals, which a computer must round into value with a maximum amount of decimals (say, 6 numbers after the dot) in order to process them and give a result in a timely fashion.

Now, if the possible values range between 0 and 255 (X and Y axis sim dimensions are 256 meters) you have a limited amount of positional values that, at the scale end value, gives out a neglectable error by accumulation of the truncated values approximation. The Z axis instead has a cap of 4096 meters for prims, but there's no limit to the avatar position. Let's assume an height of 4096 meters, and the imperceptible error we had when we were within the "regular" 256 meters gets up to at least 16 times it previously was.

For my avatar, i came up with something that diminishes this effect, although it doesn't remove the issue completely. Hopefully mesh baking services will let us get rid of sliced avatars.

Basically it's due to the unused joints removal that the Bento project introduced, and you're slicing an avatar. If you make sure that each troublesome sections contain ALL the joints names of the old classic avatar joint list, as it was previously required, this gap effect almost vanishes. 

Side note: this isn't an optimal thing for the asset itself, because you'd be keeping a lot of unnecessary data for a lot of pieces. You should manually remove the unused joints from each piece basing off their actual distance from the slice, and retain only neighboring unused joints.

I love it when he talks dirty.

[daFlesh]

22 hours ago, OptimoMaximo said:

This occurrance is due to error accumulation in the floating point range.

Between a value and another, theoretically there is an infinite number of decimals, which a computer must round into value with a maximum amount of decimals (say, 6 numbers after the dot) in order to process them and give a result in a timely fashion.

Now, if the possible values range between 0 and 255 (X and Y axis sim dimensions are 256 meters) you have a limited amount of positional values that, at the scale end value, gives out a neglectable error by accumulation of the truncated values approximation. The Z axis instead has a cap of 4096 meters for prims, but there's no limit to the avatar position. Let's assume an height of 4096 meters, and the imperceptible error we had when we were within the "regular" 256 meters gets up to at least 16 times it previously was.

For my avatar, i came up with something that diminishes this effect, although it doesn't remove the issue completely. Hopefully mesh baking services will let us get rid of sliced avatars.

Basically it's due to the unused joints removal that the Bento project introduced, and you're slicing an avatar. If you make sure that each troublesome sections contain ALL the joints names of the old classic avatar joint list, as it was previously required, this gap effect almost vanishes. 

Side note: this isn't an optimal thing for the asset itself, because you'd be keeping a lot of unnecessary data for a lot of pieces. You should manually remove the unused joints from each piece basing off their actual distance from the slice, and retain only neighboring unused joints.

Hello OptimoMaximo: as you mentioned above , its due to removal of unused joints (in smooth bind menu, I unticked that button). and so far it seems like issue solved. I dont 

see that broken blanks in my mesh anymore. well what is more I need to ask about your side note >>

"this isn't an optimal thing for the asset itself, because you'd be keeping a lot of unnecessary data for a lot of pieces. You should manually remove the unused joints from each piece basing off their actual distance from the slice, and retain only neighboring unused joints." <<

so should I manually remove the unused joints from each piece? I just tried witout touching anything but making the thing above "not removing unused joints" everything is working fine so far but I wonder  what if I dont remove those manually ?  it decrease LI if its done (manual remove)  or where should I check to see its effects (not removing VS removing manually unused joints)  (cause I dont know much about manually removing unused joints, but I can learn) as I said : so for , without removing manually those, nothing seems wrong. but I wonder advantages of manually removing those. 

note : how can I learn about removing those joints manually, any tutorial suggestion? I am good at skin weights but never played with those stuff (removing manually etc) I am not sure if it can cause issues but  I just  deleted joints that I dont use , as seen in the link below. to keep max joint limit , I think it was 116 ? 

this is one piece of mesh, not sliced one. but I use same skeleton for sliced pieces too. 

(uv maps material assignment not done) 

https://gyazo.com/5d5e78bdedc18c1ee6f38a0aceeabde8

 

Edited March 3, 2018 by daFlesh

[OptimoMaximo]

29 minutes ago, daFlesh said:

so should I manually remove the unused joints from each piece? I just tried witout touching anything but making the thing above "not removing unused joints" everything is working fine so far but I wonder  what if I dont remove those manually ?

If you don't remove the unused joints, each slice of your mesh avatar will carry the full skeleton in its description, making it heavier in terms of contained data.

Now my suggestion was to go in for each slice and remove the joints influences from such piece making sure only the "not too close" unused joints get removed. I'ts a matter of optimization and, in the end, the final download and render weight is lower if you do so.

32 minutes ago, daFlesh said:

as you mentioned above , its due to removal of unused joints (in smooth bind menu, I unticked that button).

From this part i understand you're using Maya, so in Maya you can remove the unused joints manually by:

Rigging Menuset

Skin menu  -> Edit influnces -> Remove influences

So basically you have to select all the joints you want to remove from a a piece, then shift select the piece and run the function i just mentioned above. You can do it in more steps if you need, of course.

[OptimoMaximo]

2 hours ago, daFlesh said:

note : how can I learn about removing those joints manually, any tutorial suggestion? I am good at skin weights but never played with those stuff (removing manually etc) I am not sure if it can cause issues but  I just  deleted joints that I dont use , as seen in the link below. to keep max joint limit , I think it was 116 ? 

this is one piece of mesh, not sliced one. but I use same skeleton for sliced pieces too. 

(uv maps material assignment not done) 

https://gyazo.com/5d5e78bdedc18c1ee6f38a0aceeabde8

I just noticed your edit.

As far as the bento joints go, you can delete the joint from the scene hierarchy no problem.

The procedure i was pointing out earlier, instead, is to remove the influence that a joint has on a piece, by removing it from the list of joints in the skin cluster for a specific piece.

If i remember correctly, the limit number should be 110 joints per piece. If the avatar isn't split in pieces, this removal isn't necessary. But, you most likely want to have head, hands and feet (also the other bento appendages if any) as removable pieces anyway, even after the release of baking services on mesh. It's not only to increase the chance of customized additional content, but it's actually proactive in reducing the number of joints in a single skin cluster.

[Alekso Minotaur]

20 hours ago, OptimoMaximo said:

Rigging Menuset

Skin menu  -> Edit influnces -> Remove influences

So basically you have to select all the joints you want to remove from a a piece, then shift select the piece and run the function i just mentioned above. You can do it in more steps if you need, of course.

Thanks Optimo! I was looking for that to clean up weights manually!

[daFlesh]

On ‎3‎.‎03‎.‎2018 at 7:27 PM, OptimoMaximo said:

If you don't remove the unused joints, each slice of your mesh avatar will carry the full skeleton in its description, making it heavier in terms of contained data.

Now my suggestion was to go in for each slice and remove the joints influences from such piece making sure only the "not too close" unused joints get removed. I'ts a matter of optimization and, in the end, the final download and render weight is lower if you do so.

From this part i understand you're using Maya, so in Maya you can remove the unused joints manually by:

Rigging Menuset

Skin menu  -> Edit influnces -> Remove influences

So basically you have to select all the joints you want to remove from a a piece, then shift select the piece and run the function i just mentioned above. You can do it in more steps if you need, of course.

THAnks Optimo I am working on that now

[Beq Janus]

On 02/03/2018 at 5:21 PM, OptimoMaximo said:

This occurrance is due to error accumulation in the floating point range.

Between a value and another, theoretically there is an infinite number of decimals, which a computer must round into value with a maximum amount of decimals (say, 6 numbers after the dot) in order to process them and give a result in a timely fashion.

Now, if the possible values range between 0 and 255 (X and Y axis sim dimensions are 256 meters) you have a limited amount of positional values that, at the scale end value, gives out a neglectable error by accumulation of the truncated values approximation. The Z axis instead has a cap of 4096 meters for prims, but there's no limit to the avatar position. Let's assume an height of 4096 meters, and the imperceptible error we had when we were within the "regular" 256 meters gets up to at least 16 times it previously was.

For my avatar, i came up with something that diminishes this effect, although it doesn't remove the issue completely. Hopefully mesh baking services will let us get rid of sliced avatars.

Basically it's due to the unused joints removal that the Bento project introduced, and you're slicing an avatar. If you make sure that each troublesome sections contain ALL the joints names of the old classic avatar joint list, as it was previously required, this gap effect almost vanishes. 

Side note: this isn't an optimal thing for the asset itself, because you'd be keeping a lot of unnecessary data for a lot of pieces. You should manually remove the unused joints from each piece basing off their actual distance from the slice, and retain only neighboring unused joints.

Hi Optimo,

I had also explained the floating point error issue to @daFlesh as being the underlying cause of this issue, but I had never heard of the partial "workaround" you suggest. I'm really curious as to how this works. Are you effectively saying that bones that are referenced by the mesh but not weighted to ANY have a different impact than if those bones were unreferenced in the Mesh file? If I am reading this correctly too, the issue lies only with the original bones needing to be present and not the bento extensions?

I am no expert on rigged mesh (in fact someway towards the other end of the spectrum). I was under the impression that a vertex can have up to 4 influences only, though of course, each vertex may have a different 4 if it needs. It, therefore, puzzles me that the presence or not of bones that are unweighted makes such a difference. It seems to me that if we can find a way to demonstrate the problem fully then we can fix this part of the issue properly in the uploader or at least give far better guidance on the wiki as to why this needs to be so. Given that this issue only becomes evident as part of the cumulative quantisation error seen at long distances, it would suggest that the unused bones are still causing lossy quantisation, which, from my position of comparative ignorance, seems like a bug. Quantisation is an unavoidable feature of how things work, but this rigging issue ought to be fixable. 

I am tied up on Fantasy Faire until April but I'd be happy to try to get a better understanding of this once the time crush is over.

 

[OptimoMaximo]

hi Beq

this solution of mine comes from issues i had in the past with modding for Skyrim. Over there, they use what is called a dismemberment section. I-m not geting into the details of the issues in there, but basically this system has one skeleton in game resulting form the reconstruction of the dismemberment sections within the character controller. A modular skeleton. The problem with it was a reference point, or transform, that could be used cross distance calculations instead of relying only on the local root in the section itself. 

When Bento was introduced along with the ability to remove unused joints, during my experiemnts re-importing the assets in Maya, i could observe a similar behavior to what i was describing above. So i thought that referencing one or more extra joints near the actually weighted one might help. This doesn't disrupt the skinning and its rules, as each vertex can take max 4 weighted influences, while leaving the unused ones there means they'll be listed although they don't exert any weight whatsoever.

[OptimoMaximo]

It was quite late last night when i wrote my previous post, so i think i would expand on the matter

When we remove the unused influences, we're letting the realtime, lossy calculation determine the position of our attachment(s). If we leave a reference to a joint, instead, that is listed in one piece and not used, a neighboring piece that uses it already defines its position in a more precise way. It's like a sort of triangulation method to more precisely determine an attachment (or bento appendage, the thing works the same) position relative to other attachments. So the skeleton is effectively dismembered, carrying one part of the source skeleton it should attach to, in its skin cluster list of joints, using it not for weights but as attachment spot definition, we may say. It's like saying "use this as anchor spot, weights begin from next joints", in order to take advantage of transform inheritance instead of raw calculations alone, easing the process because there's a smaller mismatch to begin with (i think).