Feature request: UV morphs about blender_mmd_tools HOT 22 CLOSED

Okay, new test demonstrates addUV1.zw components can be accessed by MME. UV morphs affecting base UV do not send zw components, however.

Was able to make a UV morph for addUV1 (not complicated, I think I just wasn't looking at correct interface context). AddUV morphs will not work unless AddUV is present on the model (which I created with Collapse script, not sure of any other way). Didn't test addUV>1, but expect similar behavior.

(This seems like a really strange way to handle things. 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.)

One way to preserve addUV in MMD_Tools would be to divide .pmx addUV into two separate UV channels. For instance, a model with UV and addUV1 could take advantage of UVMap, UVMap.001 (for addUV.xy), UVMap.002 (for addUV.zw).

An import/export UV morph could act similarly, giving the option to export/import .zw to/from maps independent of .xy maps.

This wouldn't work for a model with AddUV4 (too many maps); import/export wouldn't work well for a model with even AddUV3 (no free slots to play with). That could still be handled, but with some work, by creating UV lookup textures (which is ridiculous, but...) that stored 4-channel values for each pixel. This wouldn't require any extra UVMaps in Blender, but it would require additional import/export to make it editable/useful, and you might have some interpolation drift unless you made at least one extra UVMap to make sure all your verts landed on pixels.

This all seems pretty strange anyways; it is extraordinarily rare to see any MMD model with AddUV, or to create any MMD model with AddUV, rare enough that if one wants to take advantage of AutoLuminous AddUV behavior, it's probably easier to make a custom version of AL_Object.fxsub than to use AddUV.

Edit: If you did make a special UV mapping to prevent interpolation and special textures to store additional vertex information, this might be a better way to store values like vertex number and outline weight, because it would allow a user to preserve this information even through edits that required weight normalization.

from blender_mmd_tools.

Currently, we can import UV morphs and preview in blender via mmd_tools ("Morph Tools" panel), but my method is not ideal and is a little limited (no support for multi mesh objects). 😢

Maybe, we should store UV morph data in UV2+ fields as you said, but blender has a limitation that we can not create more than 8 UV maps which means you can only create 7 UV morphs in one mesh object. That's why I store UV morph data in the root object at the moment.

And it is another challenge to animate UV morphs. Blender provide some methods to animate UV, such as "UV Project" modifier or keyframe the offset of texture mapping..., but I don't find a good way to apply on PMX UV morphs. 😢

Actually, it is possible to import UV morph motion in a dirty and laggy way since we can keyframe UV points via Python script, just like what I did in "Morph Tools", but that would not be playable. 😏

So, I'd like to wait to see other approach. :)

from blender_mmd_tools.

I thought of a different way to handle UV morph editing.

An import UV morph -> UV n (like UV2 or UV3) and export UV n -> UV morph would be handy. This would get around issues with limited number of UV slots (assuming you have even 1 free for editing, which ought to be the case with a model intended for use in MMD or imported from .pmx).

I have no idea how hard interface is, but the math would be easy: morph(vert) = UVn(vert) - UV1(vert). Interface could be handled with 2 buttons (import from UV, export to UV) and a drop list (UV2, 3, 4 etc). "Morph Tools" on UV tab would be the obvious place to put it.

from blender_mmd_tools.

FYI, there is a Blender add-on called animall (animate all) which can be used to keyframe animate uv co-ordinates of vertices.

from blender_mmd_tools.

Well, another issue is that the PMX UV morph has 4 components, we normally only use first 2 components (x, y), and blender's UV can only store 2 components, that's why it becomes so tricky. We may need to figure out a better way to handle most case (include your method, @nathanvasil). But it is beyond my ability currently. 😢 Hope it can be solved someday. 😄

from blender_mmd_tools.

4 components? To my knowledge, it only uses 2, xy, a straight shift of UV. There's no way to edit 3rd or 4th components in PMXE, and they're always initialized to 0. The last two numbers in the model file (as seen on exported .csv) are just placeholders, aren't they? Testing via export to .csv, manual edit, import from .csv shows no difference on changing 4th field from 0 to 0.25.

However, if this isn't interesting to you, or beyond your ability, I understand.

from blender_mmd_tools.

The 3rd or 4th components can be used by MME, and maybe there is also a way to edit these values (but I don't know how to do, just got this information somewhere before). 😃

from blender_mmd_tools.

You can edit them like I did, by exporting to .csv, editing the .csv, and then importing from .csv back into your model.

I've never heard of them being used by MME. That would be weird if they did. UV is explicitly float2, only ever used as float3 with 3D textures, and some HLSL functions use a w component for LOD bias and such; float4 vertex UV is basically unheard of because of that. I've never seen any MME effects using a float4 UV, and I've looked at quite a few. Nor is their any conceivable reason to do so, because you can access a control morph in effects, and making a control morph (possibly the same as the UV morph, possibly a group or flip morph referencing the UV morph) is a hundred times easier than editing a UV morph's zw.

But I can do some testing later to see if a four-component UV morph can actually pass values through to MME.

from blender_mmd_tools.

Tested. When trying to use a float4 for UV in MME, the z component is always zero and the w component is always 1. Regardless of any UV morphs affecting the 3rd or 4th components. This behavior is consistent with the behavior of HLSL when casting from a float2 to a float4-- for purposes of matrix math, the fourth element gets cast to 1.

A UV morph of (0.5, 0, 0.25, 0.74) has no effect on the output of a pixel shader ouputting (UV.z, 0, 0, 1) or (UV.w, 0, 0, 1). These return a black and red model respectively. (And to clarify, outputting (1.0f-UV.z, 0, 0, 1) outputs a black model.)

So, no, as far as I can tell, these values don't even get passed on to MME for use in any effects.

If you'd like the edited model and shader I used to test this, let me know, but otherwise I won't bother.

from blender_mmd_tools.

http://permayuyuko.deviantart.com/journal/PMX-Validation-Every-modeler-should-know-and-do-469367980
"System
Number of additional UV sets:
Oh well, almost nobody uses additional UVs anyway. (It only has 3 uses: sub-texture, per-vertex coloring, and effect support. Currently supported effects include Autoluminous and model disintegration effect)
Anyways, this value should be between 0 to 4. If you've chosen "Automatically determines numbers of additional UV sets" then it should not be a problem.
Otherwise, adjust it properly at the model information tab, on the top-right side."

(That's all I know. I'm not an expert.)

from blender_mmd_tools.

The collapse effect (probably what they mean by "model disintegration effect") creates addUVs with its script, but its effect doesn't actually access those addUV at all, and testing with zw components of a UV morph has no effect on the script.

Autoluminous does use addUV if present, so I used it as a test; zw components of a UV morph are not affecting addUV (addUV1, addUV2, and addUV3 all tested).

from blender_mmd_tools.

Autoluminous does use addUV if present, so I used it as a test; zw components of a UV morph are not affecting addUV (addUV1, addUV2, and addUV3 all tested).

I read the code, Autoluminous can use 4 components of a addUVn, and you created some UV morphs for addUVn which show that the zw components of a UV morph have no effect, right? ...maybe I was confused about the 4 components of a addUVn and a UV morph, so I thought the zw of a UV morph can be used by MME. 😅

from blender_mmd_tools.

Actually, the version I tested (AL4.2) uses three addUV components (referenced by AddUV1, AddUV2, and AddUV3 in struct MMM_SKINNING_INPUT, which is not actually unique to MMM but also used by MMD/MME, found in the file AL_Object.fxsub). I tested with those three components, looking for any effect from the 3rd and 4th component of a manually (.csv) edited UV morph and couldn't see any difference. I tested them just by outputting various addUV components directly as colors and then playing with the morph slider. So I don't think those components affect addUV coords. I didn't test in MMM, which uses different code, with which I'm unfamiliar.

from blender_mmd_tools.

Wait, I think I see what you're saying, which is that the addUV coords used by AL are float4s. Yes, I tested xyzw/rgba for those. 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).

As far as I can see, there's no way to specify a UV morph as affecting addUV rather than base UV. Not sure if UV morphs affect addUV, as I was using a morph with components set to 0,0,0.25,0.74.

If there are any other tests you'd like run, just to make sure, I don't mind.

Of additional interest, importing to Blender/ exporting to .pmx destroyed addUV on a model, but it wasn't the most recent version of MMD_tools. Not sure if it got lost on the import or on the export.

from blender_mmd_tools.

As far as I can see, there's no way to specify a UV morph as affecting addUV rather than base UV...

Yes, there is a parameter of a UV morph which allow you to specify a UV index (for UV, UV1, UV2, UV3, UV4), so maybe you forgot to change that value to affect addUV on your test I guess. 😃

[EDIT] Sorry, I have to check this. (In pmx file format, the morph type 3 to type 7 are for UV, UV1, UV2, UV3, UV4, I'm not sure if there is a way to specify that) 😓

Of additional interest, importing to Blender/ exporting to .pmx destroyed addUV on a model,...

Yes, mmd_tools currently not support addUV, and I don't have any idea how to handle those 4 components yet (handle xy would be OK though). 😢

from blender_mmd_tools.

In the data which I posted here, I can clearly see 4 components of UV 'offset' data:
#64

So do I correctly assume that all 4 components are preserved when importing and exporting PMX?
And the first 2 components are x and y?
And the first 2 components are the only relevant components for almost all purposes?

from blender_mmd_tools.

Thank you for the test, @nathanvasil . So, it is very tricky to handle that properly in blender, unless we drop zw support to make it easier. 😃

@Hogarth-MMD

So do I correctly assume that all 4 components are preserved when importing and exporting PMX?...

No, currently zw will be set to 0 on exporting, but it is easy to change code to preserve zw data. :)

• (x, y, z, w) of a UV morph in PMX will become (x, -y, z, w) when importing to blender. (see importer.py)
• (X, Y, Z, W) of a UV morph in blender will become (X, -Y, 0, 0) when exporting to PMX. (see exporter.py)

from blender_mmd_tools.

@Hogarth-MMD While base UV.zw can exist, I seriously doubt that it's used anywhere. PMXE grays out editing of these values, while it doesn't gray out editing of .zw for addUV. And in my tests, I was unable to get UV.zw from base UV, only from addUV.

So the current behavior of mmd_tools should be fine, as regards base UV. The only place it fails is with addUV, which again, is used rarely if at all.

So it depends on whether you're talking about base UV or addUV. As far as I can tell, only the first two components are relevant for base UV. Yes, the the first two components are x and y, but in UV, it's traditional to refer to those as u and v components (hence, UV). Here, I've been referring to UV in terms of xyzw, because there aren't any naming traditions when it comes to 4-channel UV.

from blender_mmd_tools.

@powroupi How is the current state of the mmd_tools for animating UV morphs. Im not that good with coding so it would be simple if it supports it. otherwise i have to search for another solution
Thanks in advance :) !

from blender_mmd_tools.

@oKeii , currently you can preview & edit UV morph (xy channels only) in Blender for MMD, but it is not suitable for animating in Blender (the performance is bad), sorry. 😢

from blender_mmd_tools.

@powroupi Ok, thanks for the fast response :)!

from blender_mmd_tools.

UV morph feature is completed I think. (see #131)

from blender_mmd_tools.