One way to preserve addUV in MMD_Tools would be to divide. Additional texture slots would make more sense than 4 channel addUV and preserve the intended role of UV, which is a texture lookup a texture lookup that could easily provide 4-channel information while taking advantage of things like HW mipmapping options.)
(This seems like a really strange way to handle things. Didn't test addUV>1, but expect similar behavior. AddUV morphs will not work unless AddUV is present on the model (which I created with Collapse script, not sure of any other way). Was able to make a UV morph for addUV1 (not complicated, I think I just wasn't looking at correct interface context). UV morphs affecting base UV do not send zw components, however. Okay, new test demonstrates addUV1.zw components can be accessed by MME. Not sure if it got lost on the import or on the export. pmx destroyed addUV on a model, but it wasn't the most recent version of MMD_tools.
Of additional interest, importing to Blender/ exporting to. If there are any other tests you'd like run, just to make sure, I don't mind. Not sure if UV morphs affect addUV, as I was using a morph with components set to 0,0,0.25,0.74. W/A components all appeared to be initialized to 1 and unaffected by the morph, as with regular UV Z/B components all appeared to be initialized to 0 and unaffected by the morph, as with regular XY/RG components were all initialized to 0 and unaffected by the morph, rather than inheriting UV from base UV (the model I tested had no actual addUV defined on the model, maybe I ought to re-test with a model with defined addUVs).Īs far as I can see, there's no way to specify a UV morph as affecting addUV rather than base UV. Wait, I think I see what you're saying, which is that the addUV coords used by AL are float4s.
0 kommentar(er)
