Miyuo Posted March 27, 2020 Share Posted March 27, 2020 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. Link to comment Share on other sites More sharing options...
Wulfie Reanimator Posted March 27, 2020 Share Posted March 27, 2020 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. 1 Link to comment Share on other sites More sharing options...
Miyuo Posted March 28, 2020 Author Share Posted March 28, 2020 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 comment Share on other sites More sharing options...
Wulfie Reanimator Posted March 28, 2020 Share Posted March 28, 2020 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. Link to comment Share on other sites More sharing options...
Mollymews Posted March 28, 2020 Share Posted March 28, 2020 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 comment Share on other sites More sharing options...
Miyuo Posted March 28, 2020 Author Share Posted March 28, 2020 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 comment Share on other sites More sharing options...
Mollymews Posted March 28, 2020 Share Posted March 28, 2020 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 comment Share on other sites More sharing options...
Wulfie Reanimator Posted March 28, 2020 Share Posted March 28, 2020 (edited) 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 Link to comment Share on other sites More sharing options...
Miyuo Posted March 28, 2020 Author Share Posted March 28, 2020 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 comment Share on other sites More sharing options...
Mollymews Posted March 28, 2020 Share Posted March 28, 2020 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 1 Link to comment Share on other sites More sharing options...
Miyuo Posted March 30, 2020 Author Share Posted March 30, 2020 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 comment Share on other sites More sharing options...
Mollymews Posted March 30, 2020 Share Posted March 30, 2020 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 comment Share on other sites More sharing options...
Kyrah Abattoir Posted March 30, 2020 Share Posted March 30, 2020 (edited) 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 1 Link to comment Share on other sites More sharing options...
Miyuo Posted April 1, 2020 Author Share Posted April 1, 2020 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 1 Link to comment Share on other sites More sharing options...
Mollymews Posted April 1, 2020 Share Posted April 1, 2020 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 comment Share on other sites More sharing options...
Kyrah Abattoir Posted April 4, 2020 Share Posted April 4, 2020 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. 1 Link to comment Share on other sites More sharing options...
Miyuo Posted April 4, 2020 Author Share Posted April 4, 2020 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 ? Link to comment Share on other sites More sharing options...
Kyrah Abattoir Posted April 4, 2020 Share Posted April 4, 2020 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 comment Share on other sites More sharing options...
Miyuo Posted April 4, 2020 Author Share Posted April 4, 2020 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 comment Share on other sites More sharing options...
Kyrah Abattoir Posted April 4, 2020 Share Posted April 4, 2020 (edited) 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 Link to comment Share on other sites More sharing options...
Beq Janus Posted April 5, 2020 Share Posted April 5, 2020 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? 1 Link to comment Share on other sites More sharing options...
Recommended Posts
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