Darth Vader beta v.2

[grinsegold]

...can be downloaded for testing purposes as zip here:

viewtopic.php?f=15&t=14087&p=38035#p38035

Feedback highly appreciated.

[wolgade]

Vader (beta): Mask

There's avoidable trouble with the material. Here's my suggestion to fix it:
Don't use a separate alpha mask but the alpha channel of the diffuse texture. This way it will get imported correctly.

diffuse+alpha

Material file should be changed to

Code: Select all

# Material definition for vader_maskMaterial

name vader_mask
description VADER_Mask material
ambientColor 1.0 1.0 1.0
diffuseColor 0.0 0.0 0.0
specularColor 1.0 1.0 1.0
shininess 0.5882
emissiveColor 0.0 0.0 0.0
opacity 0.0
translucency 0.0

shadeless False
wireframe False
transparent True
alphaToCoverage True
backfaceCull False
depthless False

castShadows True

receiveShadows True

diffuseTexture VADER_Mask_d.png
specularmapTexture VADER_Mask_Mirror_Color.png
specularmapIntensity 1.0
displacementmapTexture VADER_Mask_Displace.png
displacementmapIntensity 1.0


shader shaders/glsl/phong

shaderConfig ambientOcclusion True
shaderConfig normal False
shaderConfig bump False
shaderConfig displacement True
shaderConfig vertexColors False
shaderConfig spec True
shaderConfig diffuse True


Displacement map gets ignored by MH. At least it doesn't make its way into Blender using MHX2.

[grinsegold]

... This way it will get imported correctly.

Good point!

ambientColor 1.0 1.0 1.0
diffuseColor 0.0 0.0 0.0
specularColor 1.0 1.0 1.0
shininess 0.5882
emissiveColor 0.0 0.0 0.0
opacity 0.0
translucency 0.0

Are you sure? Ambient 1, diff 0.0, opacity 0?

displacementmapTexture VADER_Mask_Displace.png
displacementmapIntensity 1.0

I thought displacement is used if real displacement is wanted - in terms of vertex movement, unlike bump or normalmap, which are more like a fake. Therefore you need a dense mesh. Am i wrong?

[grinsegold]

The rendering of the alpha part of the mank inside of MH flips at 85.2 / 85.3 % opacity from rather transparent to opaque. So, to make it interesting, i set it to 85.3.

[wolgade]

Are you sure? Ambient 1, diff 0.0, opacity 0?

No, didn't care about these settings. I left them unchanged. Looks ok in MH and gets transfered correctly to Blender (Cycles).

I thought displacement is used if real displacement is wanted - in terms of vertex movement, unlike bump or normalmap, which are more like a fake. Therefore you need a dense mesh. Am i wrong?

You're right, but you called your texture VADER_Mask_Displace.png, so I assumed a displacement map. I doesn't matter anyway. It gets ignored as bump maps. BTW: In Cycles there's a displacement connector in the material output node. It doesn't need a dense mesh. Most probably it does more or less the same as bump mapping. I read somewhere that it shouldn't be used in connection with normal maps, but I never tested this.

[grinsegold]

BTW: In Cycles there's a displacement connector in the material output node. It doesn't need a dense mesh. Most probably it does more or less the same as bump mapping. I read somewhere that it shouldn't be used in connection with normal maps, but I never tested this.

The displacement-output got new functionality recently. In the render-tab, switch from "Supported" to "Experimental". Call a subdivision surface-modifier. You'll notice that it looks different now from what you're used to. In the rendertab, where you switched to experimental, further down there's a tab called "Geometry". Depending on your computing device, set the subdiv.-rate for the preview to something smaller than 8. In the node-editor, plug a b/w-bumpmap in the displ.-output. In the material tab, go to "settings" and look what happens if you switch from bump to true. If you set your preview subdiv.-rate to 1 and you don't own a supercomputer, be careful not to start viewing as a close-up. Note that in this early version you have to refresh the viewport tesselation manually by e. g. switching the modifier off and on again, or go into edit mode for a fraction of a second.
The displacement output is where blender looks for textures when baking normal maps. Imagine you modelled a cloth. You sculpted the wrinkles and want to bake a normalmap from that, but you also want to include the bumpmap for the stitching you made in Gimp. If you plug your bumpmap into the shaders, using a bump-node, your bumpmap won't be taken into consideration for baking. Using the displ.-output instead does the magic. But as you said, it wants black and white maps. A simple value range from 0 to 1.
It kind of works if you take only the z-value of the normalmap-triplet, but not very well. I'm no mathematician, but obviously there's some extra information in the vector triplet that gets lost that way. Maybe some of our more clever users can tell us if there is a mathematically proper way to convert a normal map into a bumpmap, but my expectations aren't too high here.

[wolgade]

Thanks for your explanation. The experimental feature might need a bit polishing.

[wolgade]

Ok, I found out want went wrong. Displacement in true mode assumes a value of 0 for no displacement. In bump mode it assumes 0.5 (mid grey). Additionally you have to set your subsurf level very high for true mode. True mode acts exactly as a displacement modifier. You need real geometry.

[grinsegold]

Hello! Who's that pretty girl?!?
Yes, the true mode makes real mesh subdivisions, but pixel-relative. Have you checked "Adaptive" in the modifier-settings? Close-ups of the mesh get more tesselated than far away parts. So you render details only where they make sense. The subsurf-modifier subdivides the mesh automatically, depending on the mesh density per screen pixel. This doesn't mean that invisible vertices won't be tesselated. It's the opposite. You will want to put all out-of-screen-vertices into a mask group to prevent Blender from tesselating all that unseen geometry.

[wolgade]

I'm sure that this feature needs some time to get familiar with. For the time being I'll stick to bump msooing. It's cheap and gets the job done.