>>2884933AFAIK, it doesn't work like that. For HLSL, it's about the texels within the world, not the materials, so it's per texel, not a material. See for yourself:
https://files.catbox.moe/ogwajn.rarThese are all the same base model with 240k vertices and 80k faces, but the first one is 1 material, the second one has 34, and the third has 77. The stabilized FPS values drop neither in MMD nor in MMM with sdPBR and Ray-MMM. Instead of 1,200, you will have 240k cycles for vertices and god knows how many for pixels (affected by pass arguments (culling, alpha) and then clip/discard, which would involve at least one "if" check per pixel anyway). Modern GPU performance is measured in trillions (1,000,000,000,000) of floating-point operations per second, by the way, been so for over a decade.
>> But, as you say, this is a setting that only works in MMM.What? The L flag is not used in the demo.
>> The movement at 8 seems to be exactly what would be neededAssuming you can confirm that 270 degrees (displayed as -90) will be -0.5f or -0.5*pi...
I think so, but I'm not fully sure when converting a bone's rotation to degrees results in a 0–360 range.
https://files.catbox.moe/529sgz.rar (+カメラtest)
>> discontinuities at face boundaries that we get from using ddxNo idea what you're talking about. Mogg simply explains the skinning functions as something that has to be inserted in the vertex shader in order to output the current transformation, which is done automatically in MMD. I.e., if you don't skin & pass the skinned values to pixel shader and try to move/rotate the model's bones, the rendered shape will stay frozen in the default state, as this video shows. Normals output can be edited, but it'd be regular HLSL code, nothing MMM-specific.
>>2884547L O N D O N?
O
N
D
O
N
?
(gg wp if britbong. Captcha: GSVPN hints at potential tho.)
