body splitting problem

[Miyuo]

i am testing a few things out with a custom mesh body. I am attempting to make an test alpha hud with it working with the body. 

when i split the body in half (upperbody and lowerbody) its connected as seen in blender, but when i upload it to secondlife the splitting is so clear even from far away

how can i keep the body connected without it splitting? This also happens when i cut other parts of the body, like the arms, and legs.

The vertices aren't moved and they're in the same place even after being split up.

 

 

 

 

[Wulfie Reanimator]

Looking at the background, you seem to be very high up in the air.

What you're seeing is normal, it's caused by math issues with the floating-point numbers Second Life uses for rendering.

[Miyuo]

16 hours ago, Wulfie Reanimator said:

Looking at the background, you seem to be very high up in the air.

What you're seeing is normal, it's caused by math issues with the floating-point numbers Second Life uses for rendering.

ahh thanks sm! i tried on mainland and it looks great ^^, there isn't a way around it when i am in a skybox though? 

[Wulfie Reanimator]

23 minutes ago, Miyuo said:

ahh thanks sm! i tried on mainland and it looks great ^^, there isn't a way around it when i am in a skybox though? 

Nope. The higher you go, the worse it gets.

[Mollymews]

SL uses 32-bit single precision floating point numbers

try to make parts which use size measurements that do not exceed 24 bits of significand precision. The lesser the number of significand precision bits used the greater the accuracy in matching edges/seams

a full explanation of what this means is here

https://en.wikipedia.org/wiki/Single-precision_floating-point_format

examples of problematic significand values are like 1/3, 1/7, 1/9, 1/11, 1/13 etc. These values cannot be stored precisely in binary bits and rounding occurs

[Miyuo]

1 hour ago, Mollymews said:

SL uses 32-bit single precision floating point numbers

try to make parts which use size measurements that do not exceed 24 bits of significand precision. The lesser the number of significand precision bits used the greater the accuracy in matching edges/seams

a full explanation of what this means is here

https://en.wikipedia.org/wiki/Single-precision_floating-point_format

examples of problematic significand values are like 1/3, 1/7, 1/9, 1/11, 1/13 etc. These values cannot be stored precisely in binary bits and rounding occurs

I am trying to understand what you are saying here, although there is a lot i feel like is being taken out of context when i look at the wiki to look more into it. Is there another source where I could fully understand?

[Mollymews]

2 hours ago, Miyuo said:

I am trying to understand what you are saying here, although there is a lot i feel like is being taken out of context when i look at the wiki to look more into it. Is there another source where I could fully understand?

i try to explain the arithmetic

say there is a head which is 0.333 meters tall. And there is a body 0.666 meters tall

if we position the body at 1.00000 on the Z and the head at 1.50000 on the Z then there is a tiny gap

because 0.333 + 0.666 = 0.999.

to compensate, the body needs to be 0.667 or the head needs to be 0.334
 
0.667 + 0.333 = 1.0    0.666 + 0.334 = 1.0  

we have to make sure that whatever size we make linked mesh objects there is a arithmetic ratio which sums to some number which fits into a 32-bit float without rounding

in the above the ratio is 1:2. The body is twice as long as the head

if the ratio is 1:3 then the body is 3 times the length of the head

at 1:3 then if the head is say 0.5 long then the body is 1.5

0.5 + 1.5 = 2.0

position body at 1.000 on the Z. Head at 2.000 on the Z. No gap

and so on

[Wulfie Reanimator]

I think there's too much background knowledge needed to understand the actual cause of the problem, so explaining it is kind of pointless. Especially when having that knowledge doesn't provide a solution, because this issue is unpreventable no matter how/what kind of mesh you create. (Even if the mesh is theoretically perfect, every individual vertex will still suffer and create jittering and/or gaps.)

Edited March 28, 2020 by Wulfie Reanimator

[Miyuo]

12 hours ago, Mollymews said:

i try to explain the arithmetic

say there is a head which is 0.333 meters tall. And there is a body 0.666 meters tall

if we position the body at 1.00000 on the Z and the head at 1.50000 on the Z then there is a tiny gap

because 0.333 + 0.666 = 0.999.

to compensate, the body needs to be 0.667 or the head needs to be 0.334
 
0.667 + 0.333 = 1.0    0.666 + 0.334 = 1.0  

we have to make sure that whatever size we make linked mesh objects there is a arithmetic ratio which sums to some number which fits into a 32-bit float without rounding

in the above the ratio is 1:2. The body is twice as long as the head

if the ratio is 1:3 then the body is 3 times the length of the head

at 1:3 then if the head is say 0.5 long then the body is 1.5

0.5 + 1.5 = 2.0

position body at 1.000 on the Z. Head at 2.000 on the Z. No gap

and so on

i think i understand what you are saying now, in this case does this mean the dimensions of the meshes? i am willing to know more because now this is new to me and very interesting and fun to learn imo

[Mollymews]

44 minutes ago, Miyuo said:

i think i understand what you are saying now, in this case does this mean the dimensions of the meshes?

yes

some people can make perfect seams and is because they have a good understanding of single-precision float calculations.  As Wulfie points out the further away from the inworld position 0.0 an object is, there are fewer least significant bits available to position the object (vertices) inworld. example: 0.123456 > 1.23456 > 12.3456 > 123.456 > 1234.56  etc

so what we try to do is use the lowest number of least significant bits for each of the vertices along the seams when creating/sizing our objects. The creators who do make seemingly perfect seams have this understanding. And most of these people will also go into the .dae file and manually edit these values to get the seam to be as perfect as is possible at all distances from 0.0   

[Miyuo]

On 3/28/2020 at 7:22 PM, Mollymews said:

yes

some people can make perfect seams and is because they have a good understanding of single-precision float calculations.  As Wulfie points out the further away from the inworld position 0.0 an object is, there are fewer least significant bits available to position the object (vertices) inworld. example: 0.123456 > 1.23456 > 12.3456 > 123.456 > 1234.56  etc

so what we try to do is use the lowest number of least significant bits for each of the vertices along the seams when creating/sizing our objects. The creators who do make seemingly perfect seams have this understanding. And most of these people will also go into the .dae file and manually edit these values to get the seam to be as perfect as is possible at all distances from 0.0   

hmm alrighty! i'll keep studying single-precision flat calculation and hope for the best results, although this has helped a lot! at least there is some solution to the problem 

[Mollymews]

37 minutes ago, Miyuo said:

hmm alrighty! i'll keep studying single-precision flat calculation and hope for the best results, although this has helped a lot! at least there is some solution to the problem 

to help with visualising the number of bits used then this online converter can help (there are other online converters as well)

https://www.binaryconvert.com/convert_float.html

like type in 1.25 for example and see how many bits are used.  Then add 3000 to this, so 3001.25. When the sum doesn't use the right-most bit then we will avoid a rounding error

try different numbers to get a more expansive view of how this works

 

[Kyrah Abattoir]

I sincerely doubt any body creator out here understands or even takes in account floating point math, but sure.

Long story short, floating point numbers are stored in a scientific notation form, mantissa+exponent, it allows small values to remain fairly precise, while still allowing large values.

The problem obviously is when you need both large AND precise values, which is a situation you find in skyboxes, the precision of the mantissa is finite, and so the larger the number, the less precision remains available for the decimal portion.

 

By the way, this visual artefact can be easily mitigated if the body creator adds a "cap" that closes off each separate body part, it doesn't remove the gap, but it prevents displaying pixels from the sky.

Edited March 30, 2020 by Kyrah Abattoir

[Miyuo]

On 3/30/2020 at 8:09 AM, Kyrah Abattoir said:

By the way, this visual artefact can be easily mitigated if the body creator adds a "cap" that closes off each separate body part, it doesn't remove the gap, but it prevents displaying pixels from the sky.

I was thinking of doing that, although i wasn't sure if it was going to create a difference for me. I still am trying both methods and seeing what happens. all i am trying to do is make sure everything is the way its suppose to be

[Mollymews]

On 3/31/2020 at 1:09 AM, Kyrah Abattoir said:

By the way, this visual artefact can be easily mitigated if the body creator adds a "cap" that closes off each separate body part, it doesn't remove the gap, but it prevents displaying pixels from the sky.

this is another way yes.  Neck sheaths come to mind, which introduce other visual elements into the mix

[Kyrah Abattoir]

On 4/1/2020 at 9:03 AM, Mollymews said:

this is another way yes.  Neck sheaths come to mind, which introduce other visual elements into the mix

That is not what I mean, You CLOSE the hole where you've sliced your mesh, there is no new visual element.

[Miyuo]

3 hours ago, Kyrah Abattoir said:

That is not what I mean, You CLOSE the hole where you've sliced your mesh, there is no new visual element.

but wouldn't that mess with the UV map in a way ? i wouldn't know how to fix it after that or is it okay to leave it like that ?

[Kyrah Abattoir]

UV wise, you can just stretch the existing uvs, you only need that part so the "sky" doesn't show up, it doesn't have to look fancy, it just has to be the same color as the other pixels that are on the seam.

I mean... you're making a mesh body you.. should know that already? >_>

[Miyuo]

1 hour ago, Kyrah Abattoir said:

UV wise, you can just stretch the existing uvs, you only need that part so the "sky" doesn't show up, it doesn't have to look fancy, it just has to be the same color as the other pixels that are on the seam.

I mean... you're making a mesh body you.. should know that already? >_>

yes but im also a perfectionist, so if something looks extremely out of line to me then i feel like i'm doing something wrong especially when it comes to meshing, errors occur so so so much! and im not too sure about that but i will see what i can do with that

or im not understanding properly, either way i found a method from this discussion which was very helpful ^^ i wouldn't have found out without the help of others

[Kyrah Abattoir]

Obviously you'll also want to rectify the normal orientation of the vertices bordering the seam so they match the un-sliced mesh, but you need to do that anyway, fill cap or not.

Edited April 4, 2020 by Kyrah Abattoir

[Beq Janus]

This question comes up in some form or other quite often. While I would be the first to agree that altitude is a large part of the problem,  there was some interesting input from @OptimoMaximo which apparently (I have not tested this in anyway what so ever so I am just passing this along) helps to reduce the problem. This may be of use?