Displacement Issues

[dj_buckley]

Hi

Still getting displacement issues, same old problem it looks like.  I'd pay a premium to have the old dispalcement back.

Render on the left with displacement, middle shows the mesh, right with no displacement.

Corona 8 Official Release

[romullus]

Are you sure that this particular case would look better if rendered with the old displacement? To me that doesn't look like typical artefacts that are sometimes produced by the new displacement, but rather fundamental "issue" of how displacement works in general.

[dj_buckley]

Unfortunately I can't even test it to find out.  But I'm pretty confident based on previous experience, that the old displacement made this effect much much less noticeable.

Also it's artifacts along the long edge loops near tight curves, which is exactly the problems I was having with the new displacement in my old original thread about it.

Either way it looks awful and renders displacement useless in this scenario.

[romullus]

Also it's artifacts along the long edge loops near tight curves, which is exactly the problems I was having with the new displacement in my old original thread about it.

Unless i'm missing something, your example shows artefacts exactly along the edges of original mesh. That happens because displacement does not interpolate location of newly added triangles, it precisely follows original geometry, unlike turbosmooth, which interpolates new triangles based on original mesh. To solve your issue, you just need to increase turbosmooth iterrations.

Either way it looks awful and renders displacement useless in this scenario.

Personally, i don't use displacement if it doesn't change object's outline. As a result, i rarely have issues with displacement.

[dj_buckley]

It's a catch 22, to make displacement play nicely you need to densify densify densify, which in turn affects performance, and the solution to improve performance is simplify simplify simplify

[maru]

Could you please share this scene with us? (or just the chair object where this can be reproduced)

[dj_buckley]

I'll send the chair across later, the scene is quite large but I don't have to time to prep it right this second

[romullus]

It's a catch 22, to make displacement play nicely you need to densify densify densify, which in turn affects performance, and the solution to improve performance is simplify simplify simplify

You can crank up turbosmooth iterations just for render and leave default, or even zero iterations for viewport. That way you will get good performance in viewport and good render, where's the problem?

[dj_buckley]

How does the number of poly's/amount of geometry affect Ram consumption?

[maru]

How does the number of poly's/amount of geometry affect Ram consumption?

It does, but as far as I understand, one way to resolve this "blockiness" issue would be doing some tesselation / subdivision pass on the geometry before displacing it, which would result in just the same. :)

[dj_buckley]

How does the number of poly's/amount of geometry affect Ram consumption?

It does, but as far as I understand, one way to resolve this "blockiness" issue would be doing some tesselation / subdivision pass on the geometry before displacing it, which would result in just the same. :)

For sure, that's what I was getting at.  The question was more in response to the 'What's the issue' question from Romullus.  In other words, it doesn't take much to start hitting the ram error messages (performance issues).

[romullus]

You are using displacement on that model, so it doesn't matter if you will use 2 iterations, or 5 iterations of turbosmooth, triangles count and hence RAM consumption will stay roughly the same. The only thing you should worry about, is the viewport performance, but that's easy to address with different settings for viewport and rendering.

[dj_buckley]

I'm using displacement across the entire scene, a massive floorplate fully populated, that's just the model I highlighted in that particular screenshot from that particular camera.  As I'm sure you can appreciate, just subdividing everything to oblivion to ensure displacement works nicely isn't always a viable option, because it doesn't take long before the aforementioned ram issues pop up.  Especially on an already ram hungry/geometry heavy scene.  If I was only rendering that chair and that was the only thing with displacement, then sure, crank the turbosmooth up to 15.

We're still not really addressing the issue either.  The point being, this (as far as I can remember) wasn't an issue with the old displacement, certainly not as noticeable if it was.

[romullus]

It's either you didn't read my last message carefully, or i'm struggling to understand what you are complaining about. As i already said, if you are using displacement on particular model, you can subdivide it to your heart's content, it will not add to the RAM consumption, unless your subdivision is more dense than displacement itself (realistically this can happen if model is far away from camera, but then you should ask if you need such fine displacement on that model).

We're still not really addressing the issue either.  The point being, this (as far as I can remember) wasn't an issue with the old displacement, certainly not as noticeable if it was.

Unless you have side by side comparison, anecdotal "evidence" is not the most reliable thing. Don't forget we're not talking about objective artefacts that randomly manifests along hidden edges on irregularly shaped polygons. Those issues are real and no one is denying them. Your case here is the lack of subdivision and i'm pretty sure that the old displacement would show very similar behaviour in this situation.

[dj_buckley]

I'm confused because Maru himself said that heavier geometry = RAM usage increase.  A geometry heavy scene uses more RAM than a geometry light scene.  I'm looking at this from a wider perspective than a single chair.

This scene is already very close to maxxing my RAM (64GB) when I render it, there are a number of models in the scene that use displacement where these 'artifacts' are visible.  Let's say there are 100 different chairs, for examples sake.  If the solution is to subdivide those 100 chairs multiple times until the artifacts disappear, then there's a high possibility I'm now at peak RAM usage and will start to suffer performance issues at render time.  And I'm 100% sure that if I then started another thread to say I've got 'running low on RAM' errors, the suggested solutions would be to make the scene less heavy, whether that's in terms of texture sizes, poly counts etc etc but one of the first places I'd look to simplify/optimize is getting rid of unecessary geometry, hence the need for modifiers like ProOptimize etc.

The only evidence I have is that I've never had this happen with the old displacement.  Imo that's enough evidence.  Surely if the issue was lack of subdivision then the model would look crap without displacement too?  If the model doesn't look crap without displacement, then wouldn't adding turbosmooth be classed as adding 'unecessary geometry' which takes you back to the optimizing point I made above. 

As far as I'm concerned this is the still the same issue I highlighted way back when 2.5D Displacement was first introduced in Corona.  I had a huge thread about it.  I've been told it was fixed multiple times.  I've proved it isn't multiple times, even on a flat plane.

[romullus]

I'm confused because Maru himself said that heavier geometry = RAM usage increase.  A geometry heavy scene uses more RAM than a geometry light scene.  I'm looking at this from a wider perspective than a single chair.

That's right, more polygons, equals more RAM, but what i'm trying to tell you is that in most cases displacement produces much more polygons, than turbosmooth. Let's say you have two chair models, one of them has 50 K polygons and the other has 2 M polygons. If you apply the same material with displacement on them and both models will be at the same distance from the camera, then at render they'll have virtually the same polygon count and will use the same amount of RAM, but the one with 2M real geometry will be much less prone to artefacts and if you will turn off turbosmooth in viewport, you won't be paying any performance penalty.

It's kinda hard to explain the nature of these artefacts in words, so i draw a picture. Maybe it will helps to explain why this is happening and why higher turbosmooth iterations are helping.

[maru]

I think everyone in this thread understands the main issue.
What Romullus is explaining is correct.
The only workaround that I can think of right now is subdividing the original mesh to make it more smooth.

I will report it to the devs and maybe some improvements here are possible, but I am afraid it will not be something that we can immediately implement.

(Report ID=CRMAX-1581)