Jump to content

Trying to bake normals from the body and create body mods for ebody reborn


PixelBerry
 Share

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

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

Recommended Posts

Hello, so I recently got both mesh and skin ebody dev kits, I'm a beginner in blender that have a lot to learn. I'm trying to make body materials by sculpting and then baking the normals from the body. But for some reason it gives me this as a result, dark blue and poor quality, I have absolutely no idea why it turns this way, so I was hoping if anyone could give me insight, I've done this before with other types of objects without a problem, so I'm kinda lost.

I also wonder if anyone got any tips on how to make body mods for the reborn body, or any tutorials that could be helpful for that, as there is no uv with the mesh devkit, it is something I would love to learn how to do. 

Thank you! 😄

 

8190188df44b7872e663dda7cc1e29a3.png

Link to comment
Share on other sites

Can't comment on the rest of the process, but when baking normal maps and using them as image textures, you must set the image color space to "non-color". For generated images like this, you must set it before baking since it's grayed out.

Using the default sRGB will corrupt the normal map, since it's actually vector data that's just represented as colored pixels, and color correction will twist those vectors.

  • Like 1
Link to comment
Share on other sites

5 hours ago, Frionil Fang said:

Can't comment on the rest of the process, but when baking normal maps and using them as image textures, you must set the image color space to "non-color". For generated images like this, you must set it before baking since it's grayed out.

Using the default sRGB will corrupt the normal map, since it's actually vector data that's just represented as colored pixels, and color correction will twist those vectors.

Well one step closer at least! However the abs and other details other than the underboob shading aren't showing up, what can I do to fix that? 😅

 

 

6633a89e9aec88b2ecb45193e9e715c4.png

Edited by PixelBerry
Censoring.
Link to comment
Share on other sites

You can get that dark blue type normal map bake if you have assigned the high poly mesh the same material as the low poly mesh and in the Image texture you're baking to you has the Color Space set to sRGB. 

 

Example:

Low poly mesh with Torso material applied and Color Space of the blank image texture that is to be baked to set to sRGB. This image texture is selected ready to be baked to :

1a-min.thumb.png.c3b1ae1211222cab198fa94830ae7e8d.png

 

The high poly mesh has been assigned the same material (Torso) as the low poly mesh :

1-min.thumb.png.0b5c3c03f72f7aa2dfadb37a1d574898.png

 

bake result :

2-min.thumb.png.cf01fe1d59004183e8f4a08f3a97c7d8.png

 

Next a normal bake with no material assigned to the high poly mesh but Color Space still set to sRGB:

3-min.thumb.png.6dccb78c286d8e7a38d4321320cfac87.png

 

Bake result :

4-min.thumb.png.2c668b8d54894d3d534c1d73ba8b2b00.png

 

And the result of this normal map when used on the low poly mesh :

4b-min.thumb.png.8e62f472b06b25163bf1aad17023fb4b.png

Finally the correct normal map bake with no material assigned to the high poly mesh and the Color Space set to Non Color:

5-min.thumb.png.101cc8ac63f200e692e5e719f42f9c3e.png

 

The correctly baked normal map used applied to the low poly mesh:

6-min.thumb.png.0ff7faf04ed9b3246e866622286670c6.png

 

TLDR : check that the high poly mesh is not using the same material as the low poly mesh and set Color Space to Non Color data.

 

Edited by Aquila Kytori
Link to comment
Share on other sites

1 minute ago, Aquila Kytori said:

Are you not trying to bake the details from a high poly mesh to a low poly mesh ?

If so where is your low poly mesh?

A-min.thumb.png.e7ddda2e8047f9d751b961da827dd0e8.png

No, I'm not baking onto a low poly mesh, I'm trying to create body materials with this body sculpt, so making a normal map per se. Not sure if I'm explaining it right.

Link to comment
Share on other sites

35 minutes ago, PixelBerry said:

No, I'm not baking onto a low poly mesh, I'm trying to create body materials with this body sculpt, so making a normal map per se. Not sure if I'm explaining it right.

 

17 hours ago, PixelBerry said:

I recently got both mesh and skin ebody dev kits, I'm a beginner in blender that have a lot to learn. I'm trying to make body materials by sculpting and then baking the normals from the body

So, using the sculpt tools, you have added details to the default ebody mesh with the intention of baking out a normal map and then using this normal map on a default ebody avatar mesh ?

If that is the case then all you need to do is  add a default ebody mesh to the scene, this will be the "low poly mesh" and the ebody mesh that you have sculpted added details to becomes the "high poly mesh".

Now you can bake high to low :)   or not ?

 

Edited by Aquila Kytori
Link to comment
Share on other sites

1 hour ago, Aquila Kytori said:

 

So, using the sculpt tools, you have added details to the default ebody mesh with the intention of baking out a normal map and then using this normal map on a default ebody avatar mesh ?

If that is the case then all you need to do is  add a default ebody mesh to the scene, this will be the "low poly mesh" and the ebody mesh that you have sculpted added details to becomes the "high poly mesh".

Now you can bake high to low :)   or not ?

 

Followed what you said, not sure what the yellow indicates tho. 

1c518e44f3b8eb87708d7a4c59c5fa83.jpg

  • Like 1
Link to comment
Share on other sites

The "yellow" indicates that you need to increase the Extrusion value a little. This increase the ray distance that are sent out from the low poly model to "search" for the high poly. (think I got that right :) )    You find this in the Bake panel when Selected to Active is enabled > Extrusion.

You need to do some tests to find the correct Extrusion distance by increasing the value little by little until those yellow artefacts disappear. Too much and it may cause other yellow bits to appear where the fingers are.

see image below:

7-min.thumb.png.1c9bae5b9be0325bfcfb577b6fc01653.png

Edited by Aquila Kytori
  • Like 1
Link to comment
Share on other sites

10 minutes ago, Aquila Kytori said:

The "yellow" indicates that you need to increase the Extrusion value a little. This increase the ray distance that are sent out from the low poly model to "search" for the high poly. (think I got that right :) )    You find this in the Bake panel when Selected to Active is enabled > Extrusion.

You need to do some tests to find the correct Extrusion distance by increasing the value little by little until those yellow artefacts disappear. Too much and it may cause other yellow bits to appear where the fingers are.

see image below:

7-min.thumb.png.1c9bae5b9be0325bfcfb577b6fc01653.png

I put Extrusion to 0.1 after playing around with it, and this is as much I could get rid of the yellow, there is some at the neck area. I'm not sure what the other glitches are. But I think this will be fine for now, I only need the stomach and parts of the lower body for my materials, so I will do some manual editing in gimp.

41c5c13c272dc42724b73a7a41bffb89.png

  • Like 1
Link to comment
Share on other sites

Fix in Gimp is not a bad idea.

Instead of increasing the Extrusion value there is an other option which can give better results and that's to use a cage.

A cage is a copy of the low poly model that has been scaled up (inflated) so that it completely covers the high poly model. and it is this inflated version that is used to cast the rays that search for the High poly mesh.

I think it is quite well explained in this video :

 

Its a Blender 2.8 video but the principals stay the same only the bake normals panel is slightly different now in Blender 3.6

If you decide to try this method I would suggest you  use the Shift key while scaling the cage mesh (this is mentioned in the video), (Alt + S) (its the Fatten tool in Blender) and keep an eye on the splayed fingers while doing this scaling. You don't want the fingers of the cage mesh to start overlapping because this will cause more issues. Scale the cage up very slowly.  :)

 

Edited by Aquila Kytori
  • Like 1
Link to comment
Share on other sites

17 hours ago, Aquila Kytori said:

Fix in Gimp is not a bad idea.

Instead of increasing the Extrusion value there is an other option which can give better results and that's to use a cage.

A cage is a copy of the low poly model that has been scaled up (inflated) so that it completely covers the high poly model. and it is this inflated version that is used to cast the rays that search for the High poly mesh.

I think it is quite well explained in this video :

 

Its a Blender 2.8 video but the principals stay the same only the bake normals panel is slightly different now in Blender 3.6

If you decide to try this method I would suggest you  use the Shift key while scaling the cage mesh (this is mentioned in the video), (Alt + S) (its the Fatten tool in Blender) and keep an eye on the splayed fingers while doing this scaling. You don't want the fingers of the cage mesh to start overlapping because this will cause more issues. Scale the cage up very slowly.  :)

 

That seemed to do things a little better, however I noticed that there is a seam where the upper and lower body connects on my normal map, is there a way to fix that other than with paint mode?

6757dc36a7f6288c90cbdd5642d5575f.png

Edited by PixelBerry
Picture.
Link to comment
Share on other sites

 

6 hours ago, PixelBerry said:

I noticed that there is a seam where the upper and lower body connects on my normal map, is there a way to fix that other than with paint mode?

I tried baking the upper and lower body normal maps: at at first I was also getting seams. Not sure what I did differently but baking a second and third time for some reasons there were no longer any seams visible when the upper and lower body normal maps were applied and viewed in Blender.

Can you confirm that for both the high poly and low poly models the upper and lower body parts were joined together properly and not two separate meshes with overlapping vertices at the waist.

1-min.thumb.png.c706b0edb62befb270ffed0eb78173ea.png

 

Are you baking both upper and lower normal maps together at the same time ?

That's to say the low poly model has 2 materials assigned to it, in my example named Torso and Lower, :

2-min.thumb.png.daae9ec820f5527b1bfe9460b041f1c9.png

3-min.thumb.png.1dc66111d3d63fb682e61e6403043ea2.png

 

With the image textures selected in each of these materials, when baking high to low both upper and lower normal maps are baked together :

4-min.thumb.png.c46da37a727b76cbaf2104ae70621c3f.png

5-min.thumb.png.71633256444acf4d6a4d0887749a3e2e.png

 

When in material preview I am not seeing any seams where upper and lower parts meet :

6-min.thumb.png.3bd1342297b32de431fcdf141f116c8c.png

 

and in-world :

inworld-min.thumb.png.a234667ef3bae69595106d276da3ccd8.png

 

Avater mesh used in above examples is the Ruth2 v4 model from https://github.com/RuthAndRoth/Ruth2

 

Edited by Aquila Kytori
Link to comment
Share on other sites

19 hours ago, Aquila Kytori said:

 

I tried baking the upper and lower body normal maps: at at first I was also getting seams. Not sure what I did differently but baking a second and third time for some reasons there were no longer any seams visible when the upper and lower body normal maps were applied and viewed in Blender.

Can you confirm that for both the high poly and low poly models the upper and lower body parts were joined together properly and not two separate meshes with overlapping vertices at the waist.

1-min.thumb.png.c706b0edb62befb270ffed0eb78173ea.png

 

Are you baking both upper and lower normal maps together at the same time ?

That's to say the low poly model has 2 materials assigned to it, in my example named Torso and Lower, :

2-min.thumb.png.daae9ec820f5527b1bfe9460b041f1c9.png

3-min.thumb.png.1dc66111d3d63fb682e61e6403043ea2.png

 

With the image textures selected in each of these materials, when baking high to low both upper and lower normal maps are baked together :

4-min.thumb.png.c46da37a727b76cbaf2104ae70621c3f.png

5-min.thumb.png.71633256444acf4d6a4d0887749a3e2e.png

 

When in material preview I am not seeing any seams where upper and lower parts meet :

6-min.thumb.png.3bd1342297b32de431fcdf141f116c8c.png

 

and in-world :

inworld-min.thumb.png.a234667ef3bae69595106d276da3ccd8.png

 

Avater mesh used in above examples is the Ruth2 v4 model from https://github.com/RuthAndRoth/Ruth2

 

I tried it all I think and it made no difference, there is still a seam there when I try on the texture on the low poly body and in world, however I noticed that without the texture and the body just being tinted a color and the normals just being baked on the body itself that there is no apparent seam. I contacted you in world, hope that is okay. 😅

Edited by PixelBerry
Link to comment
Share on other sites

On 10/12/2023 at 5:48 PM, PixelBerry said:

I tried it all I think and it made no difference, there is still a seam there when I try on the texture on the low poly body and in world, however I noticed that without the texture and the body just being tinted a color and the normals just being baked on the body itself that there is no apparent seam. I contacted you in world, hope that is okay. 😅

This happens because the two areas you're baking differ in their tangent space, therefore the normals *look* like they create seams, and visually do, but for the purpose of modifying the normals at the pixel level during rendering, they're correct.

Why do they have different tangents? Well, because those derive from a few factors, namely edge orientations in 3d space, edge orientation in the uv 2d space, connected faces areas and 3d world orientation. All these factor into the calculations involved for translating the surface detail from the high poly into pixel encoded normal data.

Edited by OptimoMaximo
  • Like 1
  • Thanks 1
Link to comment
Share on other sites

3 hours ago, OptimoMaximo said:

This happens because the two areas you're baking differ in their tangent space, therefore the normals *look* like they create seams, and visually do, but for the purpose of modifying the normals at the pixel level during rendering, they're correct.

@OptimoMaximo Thanks for trying to explain this. I need to spend a some more time investigating vertex normal space and why the  UV layout effects normal maps .......

 

3 hours ago, OptimoMaximo said:

Why do they have different tangents? Well, because those derive from a few factors, namely edge orientations in 3d space, edge orientation in the uv 2d space, connected faces areas and 3d world orientation. All these factor into the calculations involved for translating the surface detail from the high poly into pixel encoded normal data.

But for now I have one simple question : Are you saying that for an SL avatar mesh that is  using normal maps to add detail like Pixelberry's example, "seams" are inevitable because the UV mapping (seams and island placements and orientation in the UV space) are fixed. ? 

And these 2 bug reports are they therefore not fixable because they aren't bugs at all ?

https://jira.secondlife.com/browse/BUG-227448

https://jira.secondlife.com/browse/BUG-5975

Not even in the new PBR viewer?

 

I don't find any seams when viewed in Blender :

Blender-min.thumb.png.d27ad344cf1d1cce5dab20554edf3593.png

 

but when rezzed in SL using the standard SL viewer  with a skin texture and normal maps the seams are very noticeable:

SLdefaultviewer-min.thumb.png.13dfa3b88ba157562ece665385026b24.png

 

The seams are less noticeable  when using the SL pbr viewer :

SLPBRviewer-min.thumb.png.64ef3e89eee24571e76ba9253f446531.png

 

I'm guessing this is because the SL PBR viewer is using Mikkelsen Tangent Space ?   : 

SLPBRwikiMikkTNormals-min.thumb.png.7ecd4e83fe45f50eaf02a10b7bdcb9ed.png

https://wiki.secondlife.com/wiki/PBR_Materials

 

Which is,  I read somewhere  what Blender also uses. A secondary question follows :  Why don't we see the "seams" in Blender? :) (Smile because I just know that I am not going to understand the answer) .

 

Edited by Aquila Kytori
  • Like 1
Link to comment
Share on other sites

6 hours ago, OptimoMaximo said:

This happens because the two areas you're baking differ in their tangent space, therefore the normals *look* like they create seams, and visually do, but for the purpose of modifying the normals at the pixel level during rendering, they're correct.

Why do they have different tangents? Well, because those derive from a few factors, namely edge orientations in 3d space, edge orientation in the uv 2d space, connected faces areas and 3d world orientation. All these factor into the calculations involved for translating the surface detail from the high poly into pixel encoded normal data.

Is there a way around this? I got inspired by this method by someone else who made normal maps by sculpting and baking the normals, however I'm unsure whenever they used a body for that or a sculpt of their own and somehow applied that to a body, their normal maps were seamless but I don't know how they did that.

Link to comment
Share on other sites

4 hours ago, Aquila Kytori said:

Which is,  I read somewhere  what Blender also uses. A secondary question follows :  Why don't we see the "seams" in Blender? :) (Smile because I just know that I am not going to understand the answer) .

While with the PBR viewer we now have a synced workflow using MikkT for normal maps, there are 2 things to keep in mind as well.

1) Normal maps that are uploaded as a GLTF file will use lossless compression. Hence we don't suffer from lossy compression artifacts on those.

2) To achieve the synced workflow the mesh will have to be uploaded using the GLTF viewer on a GLTF region.
in the past, meshes were stored internally packed into a unit cube. Tangents are generated on the fly in the viewer, but they were generated from that internal unit cube scale.
Means, if the mesh doesn't have a cubic shape to begin with, the tangents were generated wrongly. To correct that a change to the mesh asset format was necessary to store the original scale along with the mesh. This leads to slightly higher land impact because more data is stored.

 

  • Thanks 2
Link to comment
Share on other sites

 

 

4 hours ago, arton Rotaru said:

1) Normal maps that are uploaded as a GLTF file will use lossless compression. Hence we don't suffer from lossy compression artifacts on those.

2) To achieve the synced workflow the mesh will have to be uploaded using the GLTF viewer on a GLTF region.
in the past, meshes were stored internally packed into a unit cube. Tangents are generated on the fly in the viewer, but they were generated from that internal unit cube scale.
Means, if the mesh doesn't have a cubic shape to begin with, the tangents were generated wrongly. To correct that a change to the mesh asset format was necessary to store the original scale along with the mesh. This leads to slightly higher land impact because more data is stored.

I couldn't go to bed without trying this

I uploaded the mesh using the SL PBR viewer in a PBR (glTF) region and uploaded textures using Blender's glTF 2.0 exporter.

...... and ................... if I am not mistaken .........no "seams" ! !   :)

UploadedwithPBRviewerandPBRmaterials-min.thumb.png.1ded05b9966bb8fc7c239fb7cc6bed6c.png

  • Like 1
Link to comment
Share on other sites

On 10/15/2023 at 3:29 PM, Aquila Kytori said:

@OptimoMaximo Thanks for trying to explain this. I need to spend a some more time investigating vertex normal space and why the  UV layout effects normal maps .......

 

But for now I have one simple question : Are you saying that for an SL avatar mesh that is  using normal maps to add detail like Pixelberry's example, "seams" are inevitable because the UV mapping (seams and island placements and orientation in the UV space) are fixed. ? 

And these 2 bug reports are they therefore not fixable because they aren't bugs at all ?

https://jira.secondlife.com/browse/BUG-227448

https://jira.secondlife.com/browse/BUG-5975

Not even in the new PBR viewer?

 

I don't find any seams when viewed in Blender :

Blender-min.thumb.png.d27ad344cf1d1cce5dab20554edf3593.png

 

but when rezzed in SL using the standard SL viewer  with a skin texture and normal maps the seams are very noticeable:

SLdefaultviewer-min.thumb.png.13dfa3b88ba157562ece665385026b24.png

 

The seams are less noticeable  when using the SL pbr viewer :

SLPBRviewer-min.thumb.png.64ef3e89eee24571e76ba9253f446531.png

 

I'm guessing this is because the SL PBR viewer is using Mikkelsen Tangent Space ?   : 

SLPBRwikiMikkTNormals-min.thumb.png.7ecd4e83fe45f50eaf02a10b7bdcb9ed.png

https://wiki.secondlife.com/wiki/PBR_Materials

 

Which is,  I read somewhere  what Blender also uses. A secondary question follows :  Why don't we see the "seams" in Blender? :) (Smile because I just know that I am not going to understand the answer) .

 

While everything Arton says is also true and correct, if we're taking the regular upload and the unit cube upload method, we can still get the seams to go away by a simple "trick" : copy the vertices normals from a chunk of mesh to their correspondent vertices on the other chunk and only then bake the normal maps. It isn't going to be perfect to the absolute match, but the seams will literally be imperceptible to sane view distances, like roughly 30 cm away from the surface.

Now, about the point of tangents being geometry and uv dependent, it doesn't really matter much in terms of the texture baking effectively being precise and true to the original surface, that's what the normal map is supposed to take into account. It's more about the three vectors that a normal map samples, most importantly the normal of course, with its tangents being calculated perpendicular to it. If they (the normals) match across the border of the involved pieces, also the tangents will be calculated accordingly, providing data that conforms to the high poly surface in a consistent manner. Regardless of the calculation method, whether it be mikkt, right handed or left handed, clockwise or counterclockwise. It's a matter of vectors' consistency.

Link to comment
Share on other sites

On 10/15/2023 at 6:32 PM, PixelBerry said:

Is there a way around this? I got inspired by this method by someone else who made normal maps by sculpting and baking the normals, however I'm unsure whenever they used a body for that or a sculpt of their own and somehow applied that to a body, their normal maps were seamless but I don't know how they did that.

The method I'm explaining in my previous post gives that result. I made a tool for Mayastar exactly to achieve this vertex normals transfer easily and quickly, that I know is being used by at least 3 major mesh heads creators that I won't name here, besides the mayastar body at every mesh junction (hands and feet). I used it on my own monster avatar as well, which is split in several pieces, none of which show any seam, regardless of the upload method (indeed that avatar upload dates back a few years by now, so no gltf magic involved).

For blender, I don't know whether there is a tool that automates that. But you can do it manually, as far as I know.

  • Like 1
Link to comment
Share on other sites

32 minutes ago, OptimoMaximo said:

The method I'm explaining in my previous post gives that result. I made a tool for Mayastar exactly to achieve this vertex normals transfer easily and quickly, that I know is being used by at least 3 major mesh heads creators that I won't name here, besides the mayastar body at every mesh junction (hands and feet). I used it on my own monster avatar as well, which is split in several pieces, none of which show any seam, regardless of the upload method (indeed that avatar upload dates back a few years by now, so no gltf magic involved).

For blender, I don't know whether there is a tool that automates that. But you can do it manually, as far as I know.

I'm pretty new with blender so all these words don't mean much to me right now, as well as I have a reading and learning difficulty. But I will try and figure this out somehow lmao. Thank you for your insight, I will try googling around some more. 

Link to comment
Share on other sites

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

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
 Share

×
×
  • Create New...