Technique behind the Neckling

#21

Evil he is doing two things as far as i can see.

  1. Blending of displacement maps which are connected to bone rotations. This is used for the eye blinking and mouth curling. The bones afect the base geo but also control a blend between different localised displacementmaps.

2.Muscle Displacement via seperate muscle objects. This is responsible for the nice neck deformation** and the illusion of sliding skin.

** Its not really a deformation as the muscles do not affect the base geo verticies. What happens is at render time via a plugin (called texturedeform) the many musle objects displace the skin independantly of the normal bone rigging. This is why say the front neck flesh can move up but the addams apple stays in place.

If i have got the wrong end of the stick please correct me Taron, but i believe that is what the situation is.

-I also wondered about the isolated displacement maps out of Zbrush, are they really in separate parts, or they cover the whole model with the exception that everywhere other than the displaced part is 50% gray…

He probably saves texture memory by doing as many displacements as he can on one head saving it out to a texture. Then uses an animated alpha map to do the blending/composition.

#22

Very exciting stuff, Taron … looking forward to the new and improved “not-so” basic shader! :slight_smile:

#23

very imprssive tech man … thanks alot

#24

THANKS for sharing!:thumbsup:

#25

Rebo, You’re right on the money. Except I used the scaling of the Y-axis of the bone that squeezes the eyelids, although I also slightly rotate it. They do not really exist in the geometry, those eyelids, so squeezing a bone just brings the few polygons closer together to give the impression of the eyelids closing. Since the fold of those eyelids is also in the displacement map, but should vanish when the eyelids are pressed close hard I made this additional map. It only begins to blend after a certain threshold of the Y-scale.

The fact that memory is saved is actually just a beautiful side effect of the textureDeform principle. I’m saying this in advance, but textureDeform is not made to effect UVmaps, but to either deform any other form of mapping or to be its own mapping. UVmaps require a bit more complicated routine for the readout as well and can never be as fast as primitive types of mapping (planar, cylindrical, etc…) …however, the other reason for why I decided not to waste any time on working UVs in there was the fact that displacement map driven low res subdivision geometries are very sensitive to the map itself. You can’t just offset anything on the UV coordinates, because it would break the placement of the deformations undesirably in 99% of all possible cases. However, through the bones we have a freeform type of mapping that is even designed to allow twisting around bends, which other wise has previously been impossible to even think of. I’m very excited to see what people will come up with as soon as they get there hands on this. Too many new possibilities!!!

Thanx for taking over in answering, Rebo! Very cool! :wink:

#26

I know taron has said the possibility of this becomeing a tutorial to play with,would this be a newbie or advanced,would this involve a the balnk head stage,the rigg stage then the application of the material.

It would be nice because it would change a decision to upgrade to messiah 2 from animate 5.

Of course i hope someone will review this tut if and when it arrives.

Thanks

#27

I guess thats one of the advantages of having the render engine linked at the basic level to the geometry engine. I.e. that you can access the neck muscles when displacing the skin.

Trickier to implement in something like PRman where you only have access to the local surface data.

#28

Great work as usual Taron.

Thanks for breaking down the Basic Shader properties. Very helpful and enlightening.

You should post a before and after pic of the mesh for those who have not seen it. :slight_smile:

#29

This work is simply breathtaking.

I thank you for the detailed explanation of your technique. Looking forward to more of your experiments, studies and findings.

Truly inspiring.

#30

Thanks for all the information :smiley:

Yay… I watched the movie at zcentral… Amazing!

@Taron: One little suggestion tho: You see the skin slide over stylomastoid muscle and adams apple perfectly, but when closing the eye, the eye-rims move down along with the eyelids… It would be really nice if the eye-rim (created by the the frontal bone of the head) stayed put and only the eye-lids moved, and the skin slid over the eye rim. Maybe if you just added some polygons over top of the eye, this would be achieved easier, but I guess you over-simplified the base mesh to emphasize the power of displacement mapping…

@Evil: Do you know for sure DX10 does displacement for realtime-on-die subdivided vertex??
Currently at DX9Level ATI does support subdivision, but it is much too limited (skinning has limitations, and vertex shaders cannot do any texture fetches), Nvidia’s latest hardware can do texture fetching in vertex shaders, then I don’t know if it would displace the on-die generated vertex , but it would only displace the main vertex I -suppose-. I don’t know about directX10 specs tho, if it would require a hardware that can displace subdivided surfaces. Maybe it is better to try things with manipulating normal maps for facial expressions.

#31

Taron, do you think that render shaders on polys would work or killrender times in they were to be be baked. I know environments in games and architectural renderal rendering have improved because of baking but whatabout SSS, would that help. Maybe 4 images map that would alter themselve according to the angle of the camera and blended with a nice gradient. So you woldn’t get a constant lit side. Just babbling!

and lets not get started on normal baking.

#32

Hey hesido, you’re perfectly right!

Hey Julez, baking SSS would be just as useful as baking radiosity, you’re perfectly right. As long as people don’t bake moving objects there should be no problem. SSS is very sensitive to lighting changes, more then radiosity I would say, because the impression it makes really depends heavily on the lighting situation, while radiosity is a bit more forgiving due to it’s spread. But that’s a really funky statement…in other words: Sure!

Thing is, if you have a radiosity lit scene and shine a light across it, it may still work almost fine, but an SSS object would totally not work, I’m afraid.

Thanx for all the replies, I’m really happy to see such a reception. That’s better than what I could have wished for…great! :slight_smile:

#33

Taron, is SSS generated by lightsources only, or by irradiance AND lightsources ?

#34

Panikos, hey, the ordinary “Extnd” lights (volumetric translucency) only gathers info from lights, but the Extnd radiosity not only incorporates irradiance but actually reads the scattered illumination including lights as well.

So: YES (if you chose the proper mode ( Extnd radiosity ))

The obvious drawback is the additional rendering time, although it is stunningly fast considering what it does. I also need to give it some more attention eventually to add even more possibilities as I can think of plenty of substancial responses that would make it even more attractive. Although I do love the simplicity we’ve got with it now. Results are super fast and control is extremely comprehensive.

NOw, I shall wake up and start my day… :wink:

#35

Taron, thanks for the reply.
/me excited :bounce:

#36

Bounce… I am covering the extend lights now

#37

Great technique. Can this be tranfered over to Max?

#38

I wish Xmas will find us all very happy with 2.0c
Waiting with excitement :slight_smile:

#39

Ambiguous workding – You’ve asked two different questions!

Understanding that I’m a Max user with no experience in Messiah, take these answers with a grain of salt…

1 - Can the same techniques be used in Max instead of Messiah?

Depends. Are you a scripting god? It’s doable, but it wouldn’t be easy. If your time is worth money, you’d get better value from buying Messiah.

Plus, assume that something enabling this will be built into Max 8, and weigh your efforts now accordingly – is it worth your time to pre-invent the wheel? Likewise, understand that the Max implimentation will be less intuitive to use and set up, whether you build it or Discreet does.

2 - What of Messiah-as-Plugin? Can the animation you’ve created be brought into Max?

This requires either a material plugin (reading in Messiah’s displacement at every frame), or that your dynamically generated displacement itself be rendered to sequential images and applied in that form. Assuming one of those abilities is provided, it shouldn’t be too hard.

#40

Very cool technique.
anyway you could use the same technique in Maya?
I am not familiar with other software.

cheers,
chia