"Tearing" of smooth mesh when using displacement maps in SKP

Frutiger · Post by **Frutiger** » Sat Mar 03, 2012 5:48 am

Hey Guys,

We briefly touched this once in another thread, but I thought it might be worth getting into.

While smoothing and "welding" corners on a mesh with a displacement map, sometimes SketchUp gets some funny ideas as to how it should be done. See this image:

: WTFBBQ

It seems to happen when the image that's getting smoothed gains complexity, ie more holes get punched it it. But not always. Here's a similar object that sketchup interpreted in a friendlier way.

: that's more like it

Anyone have some guidelines for avoiding this problem?

CTZn · Post by **CTZn** » Sat Mar 03, 2012 7:50 am

The solution here, as you illustrated, is really the knife (line tool) to constrain triangulation. It may be counter-intuitive for a SU user but a clean mesh has often more edges than the volume requires.

Hint: Try not cleaning construction lines, or try to extrapolate lines from rectangles.

Lines should be intentionally added from the corners and around the openings, and generally to divide the wide, plain surfaces into square zones. Much like Qix.

More seriously there is this notion of "edgeloops", equivalent to splitting accross the whole surface for walls, wich is crucial for predictable subdivisions (and potentially absent from SU).

You can look for polygon topology images, topics and tutorials over the web for the best ways to add lines depending on the shapes you are dealing with (this one for instance).

Frutiger · Post by **Frutiger** » Fri Mar 09, 2012 5:45 am

CTZn wrote:The solution here, as you illustrated, is really the knife (line tool) to constrain triangulation. It may be counter-intuitive for a SU user but a clean mesh has often more edges than the volume requires.

The Qix example is perfect. Dividing these planes into several rectangles creates much more predictable subdivisions. Thanks CTZn!

Here's a new funny little bug though. The edge on the bottom front of the hole in this wall is welded/smoothed but still seems to be popping a hole in the mesh. Any clues on this one?

: Don't drop your keys in there.

CTZn · Post by **CTZn** » Fri Mar 09, 2012 9:18 am

I'm glad that you where able to enhance the resulting triangulation already !

Being just coplanar for edges is not satisfying the requirement to have them merging together, even though they are sharing the two same points (given two unique points, it is possible to have an arbitrary number of coplanar edges between). If you are however certain that they were effectively welded into one single smoothed edge, then you may want to make the scene available to Whaat.

Because coplanar edges are usually hard to detect (smoothing does the job best btw), it may be necessary to delete and rebuild all the surfaces in contact with both points. Implicitely you would then need to delete the points themselves.

Note that I am hereby ignorant about the specific tools SU is offering in order to detect and merge coplanar edges...

Pibuz · Post by **Pibuz** » Fri Mar 09, 2012 8:23 pm

..this topic reminds me that SkIndigo REALLY needs some displacement handling re-thinking..
You don't know how many times I dropped using displaced surfaces because of these problems.. There should be no difficulty in using displacement, as there is none when one uses a bump map..

I guess that displacement would already have been made easier if possible, but sometimes we need some users' opinion, and there are not so much around. This is probably caused by two main reasons:
1. high RAM consumption in Indigo
2. too many problems when trying to use displacement with SkIndigo.

Concerning point 1, many steps have been done, and now the memory consuption is less than before.

Concerning point 2..I don't know ANYTHING about programming, and everyone knows I'm always thankful to Whaat for his extraordinary work. I'm just saying this: in Vray for sketchup there is no trouble in setting any displacement map. No welding problems, no smoothing issues,..nothing. In SkIndigo, every time I try to displace something more complex than a plane with a hole I get problems/errors. And displacement could be so cool in many of my work scenes! I'm sad I often have to drop it and use less effective bumpmaps..

The problems we encounter can possibly be related with some kind of issues in the SkIndigo export coding? Could it be optimized/re-written? (this is just a request from a very topic-ignorant person)

CTZn · Post by **CTZn** » Sat Mar 10, 2012 12:56 am

Hi Pibuz, please allow me to jump onto my keyboard straight away again; I am concerned with the same issues, and I believe that Indigo is impeding some restrictions in welding vertices that exporters writers, including Whaat, have to deal with.

1. REQ: restore view-dependent subdivisions. Feel free to add your voice, you Pibuz and any one feeling concerned with displacement and RAM consumption.

2. (edit: I just raised this issue into our tracker, hoping that my analysis on this point is correct) Currently, Indigo allows to merge two vertices if and only if they are: at the same position (obviously), AND are sharing the same normal (belonging to a smoothed edge). The problem here is the AND, wich may benefit everyone if it was made an OR (e: more precisely, if the smoothed edge restriction could be optional). This would allow exporters writers to address most if not all welding issues I naively believe, instead of requiring occult operations from users, at the best.

Displacement is a major asset in realistic modeling as it can keep an eye busy for a while.

Whaat · Post by **Whaat** » Sat Mar 10, 2012 2:29 pm

I admit that part of the problem, Pibuz, is that the new workflow in SkIndigo 3.2 for subdividing meshes is not properly documented yet. It is next on my TODO list for a tutorial but I have gotten quite busy lately with other things. However, I hope to do it soon.

zeitmeister · Post by **zeitmeister** » Sat Mar 10, 2012 11:21 pm

In fact,
Proper subdivision needs proper subdivided faces in general.

Large differences in the scale of neighboured faces have to result in subdivision problems, because the amount of subdivision is equal to all of them.
You'll need not only a more or less proper meshflow/edgeloops; creating more or less equal scaled faces is essential to apply and result the same subdivision factor to all of them.

So use your knife to create many average-scaled faces as possible!

Problems with Displacement occur in many other renderers, not only in Indigo.

Pibuz · Post by **Pibuz** » Sun Mar 11, 2012 3:48 am

..you know how fond I am of Indigo, but I have to admit that I had no problems with vray or Fryrender. Some issues in Maxwell, to tell the truth.

CTZn · Post by **CTZn** » Sun Mar 11, 2012 4:57 am

tip: to visualize the natives triangles from SU in Indigo, disable subdivisions and assign a diffuse material to the mesh. Then, in the Indigo's Property Editor for that material click Random Triangles Color down the material parameters (only iffuse materials have this option).

You will then clearly see wich parts of a surface need to be cut down in order to harmonize triangles sizes. This last step is important in order to get an homogeneous level of detail from displacement all over the object.

For instance a first step in the case above would be to add a line between the collar and crotch.

zeitmeister · Post by **zeitmeister** » Sun Mar 11, 2012 7:00 am

@Pibus:
Smoothing issues in that cases are Indigo issues, no doubt.
But problems with inconsistent face measures and displacement are in the nature of displacement subdivision.
Maybe Vray uses microdisplacement?

Pibuz · Post by **Pibuz** » Sun Mar 11, 2012 9:23 am

..well, maybe. I don't know! I'm a user, not a programmer

Frutiger · Post by **Frutiger** » Wed Mar 14, 2012 10:03 am

CTZn wrote:instead of requiring occult operations from users, at the best.

To be fair, rendering technology is a little like black magic. We spend hours sitting infront of glowing panels, waving our arms around and wiggling our fingers, until we suddenly stop and wait for a blurry image to materialize infront of us, seemingly conjured from thin air.

Wizardry if ever there was!

More on topic: is there any other rendering platform that automates the process of creating even and regular subdivisions? It seems like this would be something that the user would have to manage.