Subdivision texture mapping error
Brought to you by:
ltatkinson,
pgregory
Menu
▾
▴
#246 Subdivision texture mapping error
When creating a subdivision surface (in this case a simple sphere from the cube control mesh - so regular smoothing), a texture mapped bitmap seems to be mapped to each recursive level of subdivision rather than as an even one-sized bitmap across the entire surface.
Attached is the RIB file. A texture to test against is:
The following are renderings:
// BMRT
// 3Delight
// Aqsis
While the light intensity is quite different in Aqsis as compared with the other renderers, the biggest problem is how each subdivided face gets its own copy of the texture (unlike BMRT and 3Delight).
RIB file
Logged In: YES
user_id=1031528
Originator: YES
File Added: tester-1-BMRT.tif
BMRT rendering
3Delight rendering
Logged In: YES
user_id=1031528
Originator: YES
File Added: tester-2-3Delight.tif
Logged In: YES
user_id=1031528
Originator: YES
File Added: tester-3-Aqsis.tif
Aqsis rendering
Logged In: YES
user_id=1031528
Originator: YES
File Added: texture.tif
Texture map
Logged In: YES
user_id=1031528
Originator: YES
Sorry, forgot you could go back and attach files. The files linked to my google site can be downloaded or the ones I've just uploaded to Sourceforge.
:-)
Logged In: YES
user_id=1086736
Originator: NO
This bug is related to the fact that there is no global or unique parametrization for a subdivision surface in general, and aqsis is using the arbitrary (u,v) coordinates which it decides upon as the default (s,t) texture coordinates.
If you want this to work as you expect, better to properly specify the (s,t) coordinates for each vertex in your subdivision patch.
I'm not sure if the fact that we do this differently from the two other renderers you mention should be considered a bug, and I'm equally unsure whether there is any really sensible way of choosing default (s,t) coordinates. The code which performs the choice for "s" and "t" which you're objecting to may be found at subdivision2.cpp:1618.
I'm going to downgrade this bug, since (1) it has an easy workaround, and (2) relying on the default (u,v) parameters isn't likely to be very useful for serious graphics work. I hope that's reasonable.
I'll second that with a shader only example that yields the same kind of error. Output for 3Delight and Aqsis with source files to reproduce them joined in subd-bug.tar.gz
Shader only example