[BUG] Displacement

[The Unknown]

Blender 2.48
Blendigo 1.1.14 (24.02.2009)
Indigo 1.1.18 win32
Vista 32-bit
Intel Core 2 Quad Q6600

Scene:
Single rounded plane with textures for albedo, bump, exponent and displacement.

It looks like some triangles have wrong calculated normals or so...
First I removed the bump map but the result was the same.
Is it a displacement bug, nudge_distance, kd-tree problem or I'm doing something wrong?

(Packed Indigo scene attached as zip-file.)

[CTZn]

That is strange, I do have inconsistent results too...

When I remove all optimisations for displacement and ask for a level 12 for subdivisions, Indigo will leave a lot of triangles unchanged while it should procees them all the same way:

Code: Select all

    <mesh>
        <name>Plane</name>
        <merge_vertices_with_same_pos_and_normal>true</merge_vertices_with_same_pos_and_normal>
        <normal_smoothing>true</normal_smoothing>
        <max_num_subdivisions>12</max_num_subdivisions>
        <subdivision_smoothing>true</subdivision_smoothing>
        <embedded_2>
            <expose_uv_set>
...

Code: Select all

Merging vertices for mesh 'Plane'...
	Initial num vertices: 49
	New num vertices: 49
	Done.
Subdividing and displacing mesh 'Plane', (max num subdivisions = 12) ...
	Doing subdivision level 0...
		num triangles subdivided: 47
		num triangles unchanged: 25
		resulting num vertices: 129
		resulting num triangles: 244
		Done.
	Doing subdivision level 1...
		num triangles subdivided: 6
		num triangles unchanged: 207
		resulting num vertices: 142
		resulting num triangles: 262
		Done.
	Doing subdivision level 2...
		num triangles subdivided: 8
		num triangles unchanged: 223
		resulting num vertices: 164
		resulting num triangles: 286
		Done.
	Doing subdivision level 3...
		num triangles subdivided: 5
		num triangles unchanged: 250
		resulting num vertices: 176
		resulting num triangles: 301
		Done.
	Doing subdivision level 4...
		num triangles subdivided: 29
		num triangles unchanged: 241
		resulting num vertices: 239
		resulting num triangles: 388
		Done.
	Doing subdivision level 5...
		num triangles subdivided: 77
		num triangles unchanged: 280
		resulting num vertices: 397
		resulting num triangles: 619
		Done.
	Doing subdivision level 6...
		num triangles subdivided: 243
		num triangles unchanged: 345
		resulting num vertices: 850
		resulting num triangles: 1348
		Done.
	Doing subdivision level 7...
		num triangles subdivided: 381
		num triangles unchanged: 936
		resulting num vertices: 1615
		resulting num triangles: 2491
		Done.
	Doing subdivision level 8...
		num triangles subdivided: 601
		num triangles unchanged: 1859
		resulting num vertices: 2831
		resulting num triangles: 4294
		Done.
	Doing subdivision level 9...
		num triangles subdivided: 698
		num triangles unchanged: 3565
		resulting num vertices: 4316
		resulting num triangles: 6388
		Done.
	Doing subdivision level 10...
		num triangles subdivided: 1056
		num triangles unchanged: 5301
		resulting num vertices: 6524
		resulting num triangles: 9556
		Done.
	Doing subdivision level 11...
		num triangles subdivided: 1419
		num triangles unchanged: 8106
		resulting num vertices: 9534
		resulting num triangles: 13813
		Done.
	Done.

Can you use an external mesh (obj) instead of embedded_2 for testing ?

[The Unknown]

Subdivision depends on the camera view and there should not be all of the triangles subdivided then, or am I wrong?

I don't know how to use an external mesh so here is the blend-file with the obj-plane and all textures.

[CTZn]

Subdivision depends on the camera view

Good point, I totally missed that mesh::view_dependent_subdivision was set to true by default... I was not expecting that

Mmm, I must review my basics then... I can't use blender, I'll integrate the external file into the previously posted IGS and return to you... but I feel a bit confused right now, I hope someone else will come and help.

edit: one small detail though: the plane is 6x6 faces, so one should find 7 uvs per side but I'm finding 12; the border UVs aren't welded. But that shouldn't cause the issue since the camera is framing inside the surface. I'm investigating further...

[The Unknown]

Where can i find view_dependent_subdivision?
There is no parameter in the igs-file or in my indigo inifile.xml!?

In the igs-file is merge_vertices_with_same_pos_and_normal set to true,
the border UVs are welded than?

I'm using a blend material.
The first material (logo) uses 4 textures for albedo, bump, exponent and displacement.
The second one (metal) uses NK data and 3 textures for bump, exponent and displacement map.
The blend material uses an alpha map (i used the reflectionmap for this).
There should be 8 uvs per side? What are these 7 and 12 uvs?

Perhaps a problem with single sided plane?
Could it be a scale issue?

[CTZn]

Where can i find view_dependent_subdivision?
There is no parameter in the igs-file or in my indigo inifile.xml!?

That's the deceiving point, when the doc says it's true by default that means (I think) that it is implicitly used as soon as max_num_subdivisions is invoked, even if it is not explicitly mentionned in the igs; I added it manually to set it to false.

In the igs-file is merge_vertices_with_same_pos_and_normal set to true,
the border UVs are welded than?

I suppose, yes. I can be positive for vertices and normals, but it would take me another round of tests for UVs and I gave enough tonight

There should be 8 uvs per side? What are these 7 and 12 uvs?

No, check that: 6 continuous edges take 7 vertices to be drawn, 12 if they are not welded I'm reffering to the obj file wich is 6x6 faces.

- - - - - - - -

This is a pure displacement bug:

Some triangles resulting from displacement have one normal on three inverted. This is obvious when <subdivision_smoothing> is set to false; one could think the triangles are missing, but on the attached image you can very well see that their top edge is shaded. If they where missing, holes would still be visible with <subdivision_smoothing> set to true.

This is not involving scene build, results are the same for both schemes.

Tough one

[The Unknown]

Ah ok, you mean the number of connections of the vertices. I thought uvs were related to textures only...

[CTZn]

I thought uvs were related to textures only

to textures and geometry (edit: precisely, they link geometry to texture space). But I should have said "segments" and "points" for illustration.

Sorry if you felt like I was attacking your competences in 3d, that's for sure a communication issue because I was just trying to explain my own says.

[The Unknown]

Thanks for your help.
My English is not the best (communication issue)...

In this render I only used a displacement map to exclude a problem with multiple textures (mesh is unsmoothed) but it's the same.

I think there's nothing we can do here.

[CTZn]

Same regarding my own english

If there is something that can be done about this issue, at least I wasn't able to figure it out. I even introduced displacement_error_threshold to prevent Indigo from being (eventually) confused with an homogeneous displacement map but that didn't help.

Let's hope for a fix/workaround.

[The Unknown]

Finaly we understand us!

I think I saw some time ago a thread with walls and undisplaced triangles.
It was solved by theses threshold (I think).
The forum search gives no result and i looked in almost all threads but I can't find this thread...

[CTZn]

This was a thread from whaat. In that case the displaced value used was below the error threshold, thus the geometry remained unaffected. This is an expected behaviour.

Another thread in wich I was mildly usefull :/

[The Unknown]

That's it!
I must have been blind, I had in mind subdivision but I searched for displacement.
I will test these displacement_error_threshold...
Thanks a lot!!!

[The Unknown]

Ok, I set the error_threshold to 0.0 and it looks all right now.
The resulting number of triangles than was ten times larger.
Perhaps the error is not visible because of the large number of tris?

I have the feeling that there is a bug in the subdivision code and because of this
related tris are subdivided along there edges and not over the whole tri ("top edge is shaded").

[CTZn]

Perhaps the error is not visible because of the large number of tris?

No, if you look at my posted image you can see that details are even thinner, the mesh has more than 4 millions polygons.

Well, I used a small value for the error threshold but it didn't come to me that zero would do better...

congratulations The Unknown !