Hi guys.
I’m trying and trying and no matter what I do, I can’t seem to get this to work. This is what happens all the time(should this be an expected result?):
I think I’ve followed all of the steps and I always get this result. Is there anything that I’m missing?
Thank you so much,
tehtoast
True displacement is as experimental as you can get in Blender…
It is nowhere near production ready and any kind of erratic behaviour is indeed to be expected. The only reliable way of getting displacement in Blender still is the Displace modifier.
Ahhh, I was afraid of that… Thanks for the explanation and I’m hoping they put opensubdiv into blender as soon as possible, because it’s much needed for optimized rendering. Thanks again!
not true
displacement method true will give you the same result as the displace modifier (direction -> normal)
@ tehtoast just use a subdivision modifier and it will work
heres a blend file with the correct setup
cycles_displacement_nudelZ.blend (128 KB)
Sorry, but I tried your file on two different machines and Blender crashes immediately when activating the rendered viewport or hitting F12. That’s not exactly what I call “reliable”…
BTW, I never said that it does not work. I just said that it is unfinished and buggy and I fully stand to that statement.
Quod erat demonstrandum…
Again, I was talking about reliability. Using an experimental build to maybe get an experimental feature to work is not.
Wait, isn’t the point of true displacement that it subdivides the mesh itself? I don’t see the point in using a subdivision modifier if there’s a dicing rate option in object data? Ultimately it should of course tessellate the mesh dinamically. Thank you for your replies, guys
Ugh, 2.75, true displacement still not working
I wouldn’t hold my breath. Not sure if anyone is actively working on that at all.
Wait, isn’t the point of true displacement that it subdivides the mesh itself?
no
“true” displacement works. the dicing option has nothing to do with displacement…
these are 2 things:
dicing is for the geometry you could use that without displacement its just another way of subdividing your mesh (this is not working at the moment don’t use it)
the true displacement function (which works - if not make a bug report) is for deforming the geometry. It doesn’t matter where the geometry comes from…
works as expected…
Then I will file a bug report for dicing. Without the dicing option it is the same as subdividing the mesh using the subdivide modifier and then displacing the mesh using the displace modifier. The point of this is for it to subdivide the mesh when you start rendering or previewing. If I’m going to subdivide the mesh using the subdivide modifier it’s already taking up loads of RAM. And no, the Simplify option doesn’t help, because there is no setting for Viewport. If I set the subdivision level low to be able to use the viewport normally, the preview render also has the same low subdivision level. The whole point - as I see it - of this setting is the dicing option. Otherwise I might as well use the displace modifier.
no don’t post a bug about dicing its an experimental feature and incomplete (displacement bug ok but not this)
you can’t use displacement properly without polygons that simply doesn’t work - dicing also would use “a lot of ram” if you need fine mesh details
the displace modifier (with “normal”) is the same function as the displacement option in cycles - doesn’t matter what you use
