Jump to content
You are about to reply to a thread that has been inactive for 176 days.

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

Recommended Posts

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.

 image.png.9388b402b3ee427d977e79fc8b2562b5.png

 

 

 

Link to post
Share on other sites
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? 

Link to post
Share on other sites

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

Link to post
Share on other sites
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?

Link to post
Share on other sites
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

Link to post
Share on other sites

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 by Wulfie Reanimator
Link to post
Share on other sites
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

Link to post
Share on other sites
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   

  • Like 1
Link to post
Share on other sites
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 

Link to post
Share on other sites
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

 

Link to post
Share on other sites

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 by Kyrah Abattoir
  • Thanks 1
Link to post
Share on other sites
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

  • Like 1
Link to post
Share on other sites
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

Link to post
Share on other sites
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.

blender_2020-04-04_10-51-08.png.26c17bbbd8036a6e64631c7018ffe73e.png

  • Thanks 1
Link to post
Share on other sites
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.

blender_2020-04-04_10-51-08.png.26c17bbbd8036a6e64631c7018ffe73e.png

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 ?

Link to post
Share on other sites

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? >_>

Link to post
Share on other sites
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

Link to post
Share on other sites

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 by Kyrah Abattoir
Link to post
Share on other sites

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?

 

  • Like 1
Link to post
Share on other sites
You are about to reply to a thread that has been inactive for 176 days.

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

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...