Subdivision Bug?

Whaat · Post by **Whaat** » Sat Feb 07, 2009 5:34 pm

I can't figure this one out. I have a brick material with a brick pattern displacement map. Max subdivision is set to 10. Indigo is NOT subdividing the brick mesh. However, if I simply change the displacement map to a different texture image and render the scene again, it will subdivide the mesh as expected.
No other parameters were changed. I simply edited the XML file to change the displacement map path, and the mesh subdivided properly.

Can anyone else confirm this?

Subdividing and displacing mesh 'Brick', (max num subdivisions = 10) ...
Doing subdivision level 0...
num triangles subdivided: 0
num triangles unchanged: 6
resulting num vertices: 12
resulting num triangles: 18
Done.
Doing subdivision level 1...
num triangles subdivided: 0
num triangles unchanged: 6
resulting num vertices: 12
resulting num triangles: 18
Done.
Doing subdivision level 2...
num triangles subdivided: 0
num triangles unchanged: 6
resulting num vertices: 12
resulting num triangles: 18
Done.
Doing subdivision level 3...
num triangles subdivided: 0
num triangles unchanged: 6
resulting num vertices: 12
resulting num triangles: 18
Done.
Doing subdivision level 4...
num triangles subdivided: 0
num triangles unchanged: 6
resulting num vertices: 12
resulting num triangles: 18
Done.
Doing subdivision level 5...
num triangles subdivided: 0
num triangles unchanged: 6
resulting num vertices: 12
resulting num triangles: 18
Done.
Doing subdivision level 6...
num triangles subdivided: 0
num triangles unchanged: 6
resulting num vertices: 12
resulting num triangles: 18
Done.
Doing subdivision level 7...
num triangles subdivided: 0
num triangles unchanged: 6
resulting num vertices: 12
resulting num triangles: 18
Done.
Doing subdivision level 8...
num triangles subdivided: 0
num triangles unchanged: 6
resulting num vertices: 12
resulting num triangles: 18
Done.
Doing subdivision level 9...
num triangles subdivided: 0
num triangles unchanged: 6
resulting num vertices: 12
resulting num triangles: 18
Done.
Done.

CTZn · Post by **CTZn** » Sat Feb 07, 2009 6:18 pm

It's allright whaat, you just need to boost the displacement value

Code: Select all

            <texture>
                <uv_set>default</uv_set>
                <path>PACKED_1_brick_displace.jpg</path>
                <a>0.0</a>
                <b>0.2</b>
                <c>-0.1</c>
                <exponent>1.0</exponent>
            </texture>

Congratulations !

Whaat · Post by **Whaat** » Sat Feb 07, 2009 6:36 pm

no that's not the problem. Look at the Indigo output that I pasted in the first post. Indigo is not subdividing my mesh (clearly, it worked fine for you). So it seems to be working on your system but not on mine. I am using 1.1.16 Windows 32 bit version and running Vista.

I hope that someone else can duplicate this problem....

FYI, the displacement value for the checker map I used was the same as the brick map so the 'b' value has nothing to do with this.

CTZn · Post by **CTZn** » Sat Feb 07, 2009 7:06 pm

Of course, that would have been too simple... I am using the 32 bit build for windows (XP) too, I did not edit mesh settings. Could be a local issue.

would png work ?

CTZn · Post by **CTZn** » Sat Feb 07, 2009 7:49 pm

Right sorry whaat, I didn't read you in first instance.

After further testing I can say that it is related with the texture parameters/total height specified. Your scene didn't work for me in first instance (same log), I then changed only b and c values and the displacement threshold (but wich ?) was passed, mesh was subdivided.

I don't think this is an expected behaviour that said...

CTZn · Post by **CTZn** » Sat Feb 07, 2009 7:58 pm

Also photoshop is complaining about an icc color profile that can't be loaded because this color profile is invalid. Resulting image is colored (PACKED_1_brick_displace.jpg) if the user discards the color profile. The same happend for PACKED_2_SkIndigo UV Helper.jpg, same image I assume.

So if Indigo loads that image the same way than photoshop, the resulting coloured image has a much weaker range than expected and thus needs to be boosted to be visible in displacement.

The image format seems to be in cause, my 2 cents. Use another app to save your jpgs or use another format ? For some reason I never use jpgs...

Whaat · Post by **Whaat** » Sun Feb 08, 2009 12:33 am

This just gets weirder and weirder. I tried playing around some more with the B and C parameters. These were the ONLY values that I changed. in about 80% of my trials, the mesh would NOT subdivide, however sometimes it would!

The strangest test occurred when most of the mesh subdivided but there were still huge triangles that did not get subdivided at all. See pic.

FYI, I always have subdivide curvature threshold set to -1. Maybe this has something to do with it.

CTZn · Post by **CTZn** » Sun Feb 08, 2009 4:52 am

Sorry, I'm the guy who downloaded the archive 3 times, it's saved now

I'm continuing my analysis, maybe that could help handle this. I hope it's not all wrong.

In this theory where the image is loaded by Indigo as I posted above (color 1: 220 128 128, color 2: 0 128 128), the final color range is 27.34% of the typical 0;1 range (modified linearly by <b>) for a scalar texture. So the initially set displacement would really be 4mm, not 15.

What was this threshold value you used that produced the last image ? Possibly you spotted an hardcoded threshold for planarity

CTZn · Post by **CTZn** » Sun Feb 08, 2009 6:02 am

Finally, converting the image to a grayscale mode png fixed the issue, whaat.

Also there was an evidence of a wrong image format: in windows, thumbnails of displacement texture are showing that there is mortar represented. However, when I click on the image, its preview show black where mortar was visible in the thumbnail.

edit: I'm suspecting that final displacement under 1mm is automatically discarded by Indigo. Perhaps i'ts using one channel data instead of averaging (I won't test that) ?

Please excuse-me for my posting attitude whaat, I'll try in the future to run complete tests before reporting, instead of generating a realtime mess

Behrendt · Post by **Behrendt** » Sun Feb 08, 2009 1:25 pm

Try playing around with your scene size. I have in mind that a very similar error occured to me once and it had something to do with global scale.

Whaat · Post by **Whaat** » Sun Feb 08, 2009 4:41 pm

I think that the image format and apparently invalid color profile may be related to the problem but I do not think it is the cause of the problem. Clearly there is a strange issue here. How do you explain the large unsubdivided triangles in the one image I posted? I would like to here from Ono on this one. This is a show-stopper in my opinion.

I changed the 'B' value to 0.03 and converted the displacement map to a gray-scale PNG.

Code: Select all

<mesh>
			<name>Brick</name>
			 <normal_smoothing>true</normal_smoothing>
			 <max_num_subdivisions>10</max_num_subdivisions>
			<subdivide_pixel_threshold>1.0</subdivide_pixel_threshold>
			<subdivide_curvature_threshold>-1</subdivide_curvature_threshold>
			<subdivision_smoothing>false</subdivision_smoothing>

Still, NO subdivision!!

Whaat · Post by **Whaat** » Sun Feb 08, 2009 4:41 pm

Behrendt wrote:Try playing around with your scene size. I have in mind that a very similar error occured to me once and it had something to do with global scale.

I doubt global scale is the issue. the box is 4 feet (1.2 meters) wide.

CTZn · Post by **CTZn** » Sun Feb 08, 2009 6:18 pm

Behrendt: No doubts about scale:

Code: Select all

Building Object Tree...
	9 objects.
	calcing root AABB.
	AABB: (0.000000, 0.000000, 0.000000), (1.219200, 1.219200, 1.219200)
	max tree depth: 8
	reserving N nodes: 9(72 B)
	total nodes used: 35 (280 B)
	total leafgeom size: 47 (188 B)
Finished building tree.

Whaat, with your settings and the attached image I do have subdivisions happening, if that image does it not for you then I suppose there is a broader issue than just a fuzzy image writing application.

Of course Ono's input is much expected

Zom-B · Post by **Zom-B** » Mon Feb 09, 2009 1:17 am

in my displacement tests I also discovered a similar issue... afaik it was related to flat meshes (like the walls) and view depended subdivision... it simply never wanted to subdivide!

Bad luck is that the manual is missing documentation on this stuff and Ono also changed the functionality of some parameters silently afaik!

For displacement and subdivision tests the colored triangles material is our best friend!

if you want another bug try a view depended closeup of a mesh (with colored triangles!) to the borders of the image the subdivision will become strange, and behave like "melted" mesh ^^

Post by **OnoSendai** » Mon Mar 02, 2009 4:51 pm

Hi Whaat,
For flat triangles that you want to be subdivided, try messing around with displacement_error_threshold. Basically, if a point should be more than a distance of displacement_error_threshold from the unsubdivided triangle, then the triangle is subdivided and displaced. However, the default value for displacement_error_threshold is 0.1 m, so it wasn't kicking in in this case.

Code: Select all

<normal_smoothing>true</normal_smoothing>
        <max_num_subdivisions>9</max_num_subdivisions>
        <subdivide_pixel_threshold>2.0</subdivide_pixel_threshold>
        <subdivide_curvature_threshold>-1</subdivide_curvature_threshold>
        <subdivision_smoothing>false</subdivision_smoothing>

		<view_dependent_subdivision>false</view_dependent_subdivision>
		<displacement_error_threshold>0.01</displacement_error_threshold>

gives:

Subdivision Bug?

Subdivision Bug?

Who is online