Is it normal that it works with everything but UV (in texture coordinate node) with images files ?
There’s another way… I’ve tested it and it works good, but I must perform other tests to check every possibilities.
This was basically what I’ve done:
1 create the basic object, unwrap, add a multi-res and sculpt.
2 prepare a temporary image texture, for baking the original vertices position (preferably with the float option)
3 with the multires turned off, bake the Object coordinates (i.e. plug the object coords to an emit shader)
4 create another texture, to store the displacement (also with float)
5 turn multires on
6 subtract the first bake from the object coordinates and bake.
the result will be the XYZ displacement map.
I’ve notice that we must be carefull to store the textures without any color correction. (save as render, exr or anything that allows negative values, node set to non-color, etc)
1 Like
With geometry cache is slower than without for scene fitting in memory. If you can render your scene on the GPU, it already fits into memory and you will get only perf loss from activating it. Point of the cache is to let in memory the current “hot” geometry visible in the current tile, the rest being written on disk through the swap. Only AMD GPUs would profit from it at the moment as only the OpenCL render allows to render scenes that are bigger than the on board memory.
@Secrop, Thanks.
In point 3 you say: (i.e. plug the coords object to emit an shader)
What does that mean? (Sorry if my questions are very basic)
@Secrop, Thank you very much for the nodes. Sorry for the late reply, I’m still experimenting and trying to get the correct map.
again, any news when its going to get into master build ?
Hi.
Baking displacement map from Blender Internal I have noticed that there are small imperfections, pixels/small square missing. Looking for I have found this:
Do you think this is really a bug that needs to be reported? or am I doing something wrong?
Here is the file. You Bake and then zoom in the image much and you see carefully looking for those little squares
http://www.pasteall.org/blend/42130
EDIT:
Well, apparently you have to properly configure the camera from top. I had not even touched the camera in the scene, so I do not know how I was getting something without configuring the camera. So, my mistake.
EDIT 2:
I reported and it seems a bug. Actually it should not depend on the camera.
https://developer.blender.org/T48550
bump! Anyone ? master ?
Things have gone silent on the development front for now (amid a debate over which method Cycles should use for the geometry cache).
On that, there’s several different approaches that Cycles can use for such a feature, and the initial patch chose one of the more basic methods (it’s possible the silence could be based on a combination of time constraints and research into other implementation types).
Many thanks Ace 
you always respond
My idea is only speculation though, we won’t know for sure until we get a developer response.
xnormal seems to have vector displacement baking
Added a new render map type: The ray direction map. It’s good to perform vector displacement
mapping for uniform tessellation and also to debug visually problems with the cage
from the xnormal help doc. there is also a tut “Baking vector displacement maps for use in Modo” in their tutorials section.
Finally, an update on the development front
https://lists.blender.org/pipermail/bf-blender-cvs/2016-June/087119.html
This may seem like disheartening news, but the developer wants to get the subdivision/displacement completely nailed down first and the cache code caused it to become a slow process (so it will likely be added back as the final piece).
The rounds of commits to the microdisplacement branch is resuming, today it’s about adding support for a dedicated patch primitive
You can see why he may have wanted to wait on the geometry cache.
Yaay! Thanks for the info Ace… lets hope for the best!
corrected.
nice to know that there are coder girls too into the blender world
I like how your gender is not necessarily defined on the internet. It’s not very relevant.
Actual development state linux64 build:
www.jensverwiebe.de/Blender/blender_microdisplacement_linux64_bf8c67e.tar.bz2
Shasum: 1f22ee5cae236e65fbfefc72ea057bc87f48cc3a
Jens