Trying to solve sculpt baking issues


#1

I’ve been in touch with Maxon about this, but thought I’d see if anyone else is having this issue (or similar)

See the attached image to see the issue visually. It should look like a normal, perfect sphere.

If you have the time please try the following simple steps to see if you have the same results.
It appears that normal maps bake out properly, but displacement maps are full of artifacts rendering them nearly useless.

We won’t actually sculpt anything, we’ll just be going through the steps to show the issue.

  1. Create a sphere primitive.
  2. Make it editable - “c”
  3. Enter sculpting layout
  4. Hit “Subdivide” in the Sculpting palette
    6 times (which gives us a level 5 sculpt)
  5. Click on “Bake Sculpt Objects”
  6. Create name and save path for files.
  7. Change output size to 1024/1024
  8. Go to Options tab, Choose Displacement and Normal Map
  9. Set Displacement to RGB(XYZ Tangent)
  10. Set Normal to “Tangent”
  11. Click Bake
  12. Hide Sculpt object in Object Manager
  13. Do an editor render and you will see faint lines on the newly created model.
  14. Change the displacement value in the material to 30.

It gets even worse when you apply a deformer. (try putting a twist deformer on the baked out object)


#2

Yikes…
Confirmed


#3

yes, it seems to be a rgb(xyz tangent) displacement generation issue…i have a similar post last week and had similar results…but all other maps seemed to render out fine.

I am guessing it is just not functioning and is a bug for sure, but no one seems to have any answers as to why


#4

I’m pretty sure most of the displacement maps are messed up.
Intensity centered does the same thing.


#5

I’ve no idea if this is a good tut (I find the quality with DT varies a lot TBH) but it seems to cover baking so maybe worth checking out if you have a subscription with them. I guess since they are teaching it they managed to get the baking working for them.

http://www.digitaltutors.com/11/training.php?pid=849&autoplay=1

Cheers,
Brian


#6

here is a workaround (not my video)
http://3ddataflow.com.au/stuff/round_geometry_baking.swf


#7

Thanks for posting that link dataflow. Certainly not ideal, but it’s all we’ve got for now.

How can Maxon release this software in its current state? That’s a pretty major bug.

We really expected to be able to just get to work with sculpting and animating straight out of the box. Thanks to this work around we can at least make it work.

Thanks again for the link.


#8

I would also recommend Xnormal, it is pretty widely used.


#9

I appreciate and understand your frustration but the reality is that pretty much all software gets released with bugs. Not just Maxon do this but Autodesk, Pixologic, etc etc.
As an end user the best solution IMO is to diversify and invest in several programs. That way you have alternatives when one won’t do what you want. Yes it’s expensive but if your livelihood is at stake then it’s worth the investment.

Cheers,
Brian


#10

I know it will get resolved, and I have this workaround now, so we can move forward.

At the end of the day…it’s all good. Just have to work around the limitations


#11

That workaround is awesome. Thanks for sharing it. I’m going to download it and save it to dropbox just in case!


#12

The work around still didn’t work for me sadly…It almost works…but now I get a bunch of little specs as if 1 pixel here and there miscalculated and it causes some crazy spiking to happen during render almost looks like hair haha…


#13

Berzerker, I’d say try again with a simple object and simple sculpt. Make sure you do every step just as shown.

We tried it about 4 times today and it worked every time.

In the process, we found a work around using the “bake sculpt objects” button.

You basically bake out with Source set to highest level, and the Target set to highest level then apply the new material tag to a base level mesh and set the subpoly displacement to the level of your highest sculpt.

  1. make a copy of your base mesh (just duplicate your sculpt and delete the sculpt tag if you don’t already have a copy of the base mesh) If it is a heavy sculpt, you can always paste it into a new document, remove the sculpt tag, then copy and paste the object back in to the original document so you end up with a copy of the base mesh.
  2. Use the “bake sculpt objects” command. Set the Source level to the highest it will go (make note of what that number is). Set the Target level to the highest it will go (it will be one less than the Source).
  3. BAKE
  4. Move the texture tag from the new object that gets created onto the copy of your base mesh.
  5. edit subpoly displacement level to match level of your highest sculpt level
  6. hide everything except the base mesh with this new tag on it
  7. apply deformers and render

viola!

Worked every time for us. (Wes is the brain behind figuring that out)


#14

Thanks, but my problem is slightly different in that I created my mesh in zbrush and am trying to bake out the tangent space displacement in C4D…so I need to use bake texture instead of the sculpt baking process, which I did also try and that does work…it’s something in baking from one object to another object where tangent displacement baking still seems to be not working


#15

You can’t bake from the low poly object in Cinema… it’s adding info to the texture map based on the edges of the polys… plus some other random noise, from what I see.

You’ll have to bring in 2 objs from ZBrush, your high res sculpt (will probably make Cinema have a stroke) and the low res mesh… hypernurb subdivide the low res mesh to the same poly count as your ZBrush high density mesh then place your bake tag on the subdivided unsculpted mesh… Once you have those objects in your scene you can follow the above mentioned workaround… the swf link.


#16

On a side note… the workaround video uses a hypernurb object to subdivide your bake mesh, then made editable. Only problem with that is the hypernurb object seems to have a limit of 6. So you’re better off using hypernurb subdivide in addition to that or instead of… if your sculpt was divided more than the hypernurb object will allow. Make sense?


#17

its funny iv never notice that the hypernurbs stops at 6i usaully never go past 3.
you could always just subdivide (hypernurb) it more then once.


#18

interactiveBoy what are the other issues you contacted maxon about?


#19

They have to do with Physical Render. They have been confirmed issues. I feel they are bugs, they call them limitations. Semantics. :slight_smile:

  1. When using particles with Physical Render and motion blur turned on, as the particles die, they internally change their index number. This confuses the motion blur so you end up with frames of flashes of white or certain frames not looking like the same color range as other frames. It’s due to the index ID’s changing on all the particles and the motion blur interpolating a particle from its previous index number (which was a different particle altogether)
    Solution: NONE
    Workaround: don’t let particles die. Set their lifetime to be as long as the segment you are rendering so no particles will die.

  2. Animating light brightness when using Physical Render. If you intend to fade lights to 0% there is a good chance you will get white flashes or complete shifts in color at the time (frame) that the light goes to 0%. When a light goes to 0% it is removed from the scene, thus that index number is gone, and all the other lights shift to a new number ID.
    Solution: Sounded like there was no fix planned when I talked to tech support.
    Workaround: Never set the light’s brightness to 0%. Instead go to 0.01%

Couldn’t this be fixed on their code? I understand killing off particles for memory reasons, but if the “fix” is to never let them die anyway, then why keep that in the code which is causing MAJOR render glitches?

As for the lights, why kill them off at all? Couldn’t they keep their index numbers? How much memory could that really be taking up? I’m no coder. These are just hypothetical questions.

Also on number 2, I requested that they code it on their end (since it is a “limitation” with their render engine). I asked why not have the code convert 0% to 0.01% under the hood when physical render is the active render engine. Seems like it would be an easy fix in the code.

I have started compiling a C4D Bible here. Sadly, it is not a gospel. It is a book of sins. LOL

I have to document all these workarounds we have to do. It’s getting to be a real nuissance to our workflow.


#20

That one doesn’t seem like much of a workaround! :curious: