Cyan-style blends?

[Tayrtahn]

Hm, so nothing fancier than dragging the UVs around, huh? I ask because the imports of Cyan Ages have some crazy complicated UV maps on some of the blends (Relto, for instance).

I also seem to have lost track of where (or if) vertex painting fits into this technique. My current test plane doesn't seem to be affected at all by changes to my vertex paint layers.

[Paradox]

Cyan doesn't do their blends using textures (in Max), but rather using vertex alpha or vertex illumination colours. Sadly, Blender doesn't seem to allow this.

[Nadnerb]

I did all my texture blending in Odema using ramp texture layers like cyan did. In order to easily edit the uvs in an intuitive way, I would vertex paint the objects, and then run a simple python script to translate the vertex colors into uv coordinates. (and then moved the vertex colors to a separate vertcol layer so that pyprp would ignore them during export)

Code: Select all

from Blender import *
scn = Scene.Get()
for obj in scn[0].objects.selected:
   mesh = Mesh.Get(obj.data.name)
   for face in mesh.faces:
      for i in range(len(face.uv)):
         face.uv[i][0] = face.col[i][0] / 255.0
         face.uv[i][1] = 0

(this maps vertex colors to uv space on all selected objects in scene 0. Beware that objects are immutable to python while you're in edit mode, so run only run the script in object mode.) Note that the resulting uv map may look a bit funny (banded/over-repeated) in blender's real-time textured view, but it will come out right in plasma.

[Tayrtahn]

Aha! Now that's what I was looking for! I had a feeling that Cyan was doing this with vertex paint or something... interesting that Blender doesn't support this method.

Note that the resulting uv map may look a bit funny (banded/over-repeated) in blender's real-time textured view, but it will come out right in plasma.

Argh! I need to learn to test things in Plasma before giving up on them. Look at what I have sitting in the text editor of an older file:

Code: Select all

for f in me.faces:
   for i, v in enumerate(f):            
      f.uv[i].x = f.col[i].r/255.0
      f.uv[i].y = 0

Sigh. On the bright side, I know how to do this now! I'll probably take a crack at it tomorrow to see how well I really understand it. Thank you all for your help!

[Tayrtahn]

Not the prettiest of blends, but it's just a test. Great to have another tool in my kit. Thanks again for all the help!

For those interested, this is done by setting up a stencil just like the tutorials in the wiki explain, but loading in the 64x4 ramp texture for the stencil layer. Create a second UV layer (I called it "uvStencil") and point the stencil layer to it under MapTo. Make two vertex paint layers, Col and whatever (I used "Blend"). Now go to town painting in black and white on the second layer. Next, making sure you have the stencil UV layer and the Blend vertex paint layer both set as active, run the Python script mentioned earlier in the thread*. And that should do it!

*I found that Blender (and sometimes Plasma) got upset by pure white and pure black vertexes (the UVs would be at the very edge of the ramp texture and would get a mix of black and white). Adding checks to the Python script to limit the value range to 0.01 - 0.99 fixed it easily.

[Paradox]

*I found that Blender (and sometimes Plasma) got upset by pure white and pure black vertexes (the UVs would be at the very edge of the ramp texture and would get a mix of black and white). Adding checks to the Python script to limit the value range to 0.01 - 0.99 fixed it easily.

You can probably fix this by clamping the texture.

Very nice, it would be cool to see this integrated with PyPRP to provide an easier way of stenciling

[Aloys]

If I understand correctly you are using a single mesh?
After importing Relto and other Ages that use this technique (two years ago?) I was under the impression that Cyan actually used a decal appproach with separate meshes on top of each other using a simple vertex painting as stencil. Which is a technique we can use, but it is a bit of a ressources/performance waste..
At the very least PyPRP certainly imported a bunch of different meshes. (see this picture). Was that a PyPRP quirk?

[Nadnerb]

Cyan's technique varies depending on what they're trying to accomplish. In the example you showed, I believe that the meshes are separate because one of the decal "layers" is actually an object that can be enabled/disabled (the green stuff on the relto ground that you can turn on and off) Permanent parts of the ground are blended in a single material/object using the ramp texture method.

Also, Paradox is correct with respect to the max/min values on the uv map. You can use the perfect 0/1 values on your uv map if you set the texture properties to "clamp" (this sets it such that the sampled texture color is the color of the last row of pixels beyond 1 or below 0, rather than flipping back to the other side and repeating, which is what causes the weird appearance of banding) however, this texture setting in blender only affects the ray-traced material, (though it is exported to plasma) thus, the real time view will not be corrected when this setting is enabled. (I think there might be another setting that would correct this in the real-time view, but that is ignored by pyprp.)

[Paradox]

(I think there might be another setting that would correct this in the real-time view, but that is ignored by pyprp.)

There is indeed such a setting in one of the UV Image editor panels, but you might be correct that (trunk) PyPRP ignores it.

[Aloys]

Cyan's technique varies depending on what they're trying to accomplish. In the example you showed, I believe that the meshes are separate because one of the decal "layers" is actually an object that can be enabled/disabled (the green stuff on the relto ground that you can turn on and off)

Oh.. right. I hadn't thought about that. A single object makes more sense performance-wise then.