[Steve Bentley]

Boa will do the job – does it have to look like a rope? The indents at the edges might be tough where the grooves between wraps are. I haven’t tried this but you could make a copy of your main “rope” and increase the spacing and make this second rope a little smaller so the “balls” of the brush that makes the shape of the spline barely overlap are the width of the first rope at the edges of the balls only. Use this second spaced rope to mask out the first boa object – when you get the spacing right it might line up with your rope wrap texture and voila, edge bumps.

Depending on how you want the ropes to move (other than just growth along their length) you might have to combine boa with a few other scripts available at the same place to get proper easing control of the spline control points.
And depending on your realism requirments you may have to cheat to get the overlap shadows by adding a masked soft or hard edged element within the rope shape itself.
Doing this in 3D would be easier but unless you want to go with a collision dynamics system you have the whole problem of intersecting geometry which can detract from the realism – shadows would be solved but again you have the issue of point level animation for the spline points. But you can always conscript some nulls and animate them and have their positional data control the spline points. This will give you the easing you can’t get from PLA.

[Steve Bentley]

I wasn’t going to say anything but since you brought it up…
We just went through hell because of Mixamo/Fuze/Adobe.

Adobe bought what was a sweet little company we have used successfully in the past. It was great: you could combine mocap data in the app and then export as a seamless peice-together of the data without the hassle of appending or retargeting or realigning the adjoining datasets. The characters all had the same bone structure… I could go on an on.
But now since V2.0 under adobe’s watch, they have broken it and see no point in fixing things since they are working on project Felix (project Pinnocio might have been a better name – they can’t even get that right). In the forums you can find a huge number of people asking what happened and where this feature or that has gone. Only to be told they are no longer developing and are now focused on Felix, and besides”less than one percent of users used that feature”. That “feature” in question was the combining of data in the app – it was the killer app, so I highly doubt that number. Its all very much a flip of the finger to long time users.

If you down load the example character (there used to be more of these but now just the one and it’s not even a single mesh! (So it hides a variety of sins that a single mesh wouldnt) and start playing, you will start to go “hey this could work”. Then the fangs set in. If you pick another character – different bone set. if you pick another mocap routine – different hierarchy. They have made a mess of what used to be an elegant solution for people who don’t do this everyday.
And fuze is just so much vapour ware right now. And because it’s cloud based I think if Adobe decides to scuttle it as they have done with Mixamo you’re stuck.
But not wanting to be a nay sayer only. Here’s a link that we’ve found helpful but has it’s own issues.
https://www.proanimationbank.com
This is just data – we’ve never gotten any useful meshes here even though they have some for sale. If you read their bio they say they scrutinize all data meticulously – can’t be true- because even in the previews you can see glitches and our sets are full of them. Women and men data sets have different hierarchies, and depending on the age of the data it may have another hierarchy again. The “this data links with Data set A” feature isn’t always true. So “Man walks to chair – man sits down- man types” – all are supposed to link together. They do but not without some major issues. Walk routines tend to be static in place while the linking “turns” tends to be in motion, so again, not so easy to link for some one who doesn’t do this everyday.
The up side – the data sets are cheap. $4-18. But very segmented to up their profits. They could be overly segmented because they can’t get the data to mesh seamlessly either.

There is a free data set out there on the web originally captured at Carnegie Melon U (sp?). You often have to go through a number of servers as it’s so old. The catch? Its quite noisy and uses what I would consider an old hierarchy style.

I think the overarching problem you will encounter with bought characters or motion sets is due to no set standard with bone hierarchies and joint directions. The reason we don’ t have a standard yet is that each use is unique and someone sitting and typing will have different heirarchy needs than a character from Seal Team Six. I think too that the investment to set up a system to do this in house means that you won’t find a lot of affordable boutiques that do this, and in the in house types are going to their bone structures for what works for their projects.
Within an animation with lots of different moves, you will often find a number of different versions of the same character depending on what he’s doing – and the closer you get to a proper realistic human mesh (especially with clothing) the more often that happens. Woody from Toy story most likely has one rigged character for most of the movie(I don’t know that, but given his stylized shape it’s possible). But other complex humans in other productions often have a new rigged version of the character for each specific task so that they don’t get hollow armpits or twisting forearms or flat butts when they sit.

What about shooting and using silhouettes – that way you can simulate brian may’s hair with a wig and in silhouette people will assume it’s him, whereas a model of him just won’t get there without a huge amount of work. We’ve done tons of this kind of stuff with mocap (silhouettes I mean) its very forgiving from a rigging point of view. But if you have the means nothing says real like real. And you get exactly what you want – purchased mocap is always a compromise.
FYI – For some reason this kind of thing looks better with a little slow mo on it.

[Steve Bentley]

Hey thanks Brian,
I was trying the uniform point distribution in the spline itself but didn’t think of using it in the node. That should do it.

I’ll give the rail idea a try – I was trying to avoid this as I’m moving the spline points around so that means I’ll have to manage a bi-rail point system AND the handle tangents and that might be tough to keep them aligned.

If it is indeed gimbal lock and not some sort of axial twist, I might be able to deal with it since I can change the rotation order. (re the “twist”: as the handles get close to a zero angle I’ve seen some applications of the math where divide-by-zero errors kick in and result in an axial flip flop, but I didn’t know how cinema handled it (ha!) )

I also thought about approaching the gimbal lock problem with vectors instead of rotation – or am I just climbing up the opposite side of the same tree… er, spline?

Cheers

[Steve Bentley]

As a fellow projection mapper, I guess it begs the question how real do they need to look.? Even with the best techs in hollywood we’re only now just seeing the other side of the “uncanny valley” (albeit still a hazy distance away).

Will you be animating them yourself or using motion capture? Then there’s the rigging, and painting of the weights – this alone can take a quite a while even in practiced hands. Textures too but if you go stylized that might be the easiest part of the job. People are just hard- we’re all so intimate with them we know when something’s not right: motion, the way the skin transmits light, eye tracking… when it’s not right it’s kinda creepy.

I’m not trying to discourage but painting weights and rigging can be an art and I find that depending on the action planned for the character each sequence may need special treatment depending on what they are doing – 3D characters aren’t quite as flexible as we rubbery humans are – at least and still have the character look good: without arms passing through other body parts, or shirts smearing as the arm passes by the torso, or underarms caving in. Shoulder joints are probably the toughest (and I think your drummer will be utilizing that spot a fair bit).

Here’s a thought though – what about just shooting the perfomers (you might have to anyway to get good motion capture data). Then map the real footage into a 3D enviro and do your warp as needed to fit your achitecture. A one day shoot could save you weeks. In the end it’s all 2D and an illusion, so whether it’s 3D animated characters or 2D footage, it all becomes a flat image plane(s).

[Steve Bentley]

Just the obvious off the bat – are all the textures in their proper folders? – I get so involved sometimes I just say “ya ya” to cinema wanting to put the texture somewhere, that I don’t realize that it’s put it in the wrong folder. Just add a whatever folder they are in to your preferences list of texture map locations. (under edit/preferences/files)

Second, are you using R15 or before? We had a terrible time with that reload button never working. Seems to have been fixed in R16+

Finally – any cloners involved? We’ve had bad luck with xref and cloners. They work for a while and then they seem to loose the link. Even a cloner inside a character’s heirarchy will do it or visa versa.

[Steve Bentley]

Its funny how things happen in clusters in seemingly unrealted ways. A friend was having some color/lighting issues in blender today – there’s a very sweet third party solution for those guys. But similar issue to the problem you were having.

After saying there is no way to tweak the view port – turns out there is – although not on my system, I’m not sure if that’s a video card thing or a versioning issues or what. In the C4D preferences, under View, is the display color profile. And if it’s there you can set the viewport to a number of built in things or link to an external file (i’m not sure if that’s going to a be LUT you link to or what but I’ll look into it).
I personally don’t have that feature on my system (PCWin 7 R16 and R17) but I was shown it on an R16 and R18 today on another system – and to be fair I have been having some vid card issues so it could be a glitch that is unique to me (that’ll teach me for buying a top end nvidia!)

I’m glad that helped. I’m about to start doing what you were doing for a project we have here so I’ll let you know what I find.

I have noticed, and I”ve had no good answers on this, that when I render multipass with EXRs, if I don’t include RGBA in the list, usually I get an RGBA layer but sometimes not. I think it’s there regardless, as I can see it in the picture view window as its rendering but try as I might (even with extractoR) I can’t pull an RGB from the multi pass sometimes (which is really annoying after a long render – ever down a presentation to a client with depth channel only?). But when I force an RGBA layer by adding it to the multipass list, that RGB looks very different from my viewport; whereas the one that comes with the multipass usually has no surprises vs the viewport look). Now I think that’s because I don’t have the setting to change my viewport to Linear (and the multipass remember is always linear). We tried it on another system that did have the view port set to linear so forced RGB’s looked the same as the view.

[Steve Bentley]

Hey Ryan,
What version are you running and what platform? Can you set the color mode of your viewport? I have a feeling that (ironically) it’s the linear mode that’s causing the “problem” (ok its not actually a problem). When you multipass, all files are written in linear mode, but I’ll bet dollars to donuts that the viewport is showing SRGB or some other antiquated space. Many of the premium color spaces can’t actualy be viewed directly on a monitor since most screens are 8bit linear (or close to it) so there is always a Look Up Table at work converting the vast range of colors and curves in your files down to something that looks normal on an 8 bit screen. And SRGB is made for the old CRT’s which hardly anyone is running anymore (sniff… I miss my blacks!)

I can’t see anywhere I can set the color space of the viewport (nor could I find what it defaults to). There is a linear setting for a background image but that’s just how C4D should interpret an incoming image to display in the background for reference. (so you could use a cineon file or exr without converting and c4d will do its best to interpret). But that setting won’t actually affect what a render looks like in the viewport. I just don’t have enough info on what’s going on between c4d rendering, and showing you what it made.

I have a feeling that with the linear multipass, especially if you use 16bit or above, you have the head room to apply curves to the glow pass in your compositor without it blooming or clipping and you will get something you would be happy with. Try to get there in your compositor without using Screen or Multiply as once they are in the image stack everything below gets slammed down to a lower color space and you loose the headroom you need to make the adjustment in the first place.

We’ve been trying for a while to figure out a pipeline to use the Acadamy’s ACES format inside cinema, or even Filmic Log encoding. EXR is pretty damn good but…. Keep in mind too that unless you have an interpreting LUT on the composting end (or something similar), while the comp might output just fine, it might not “look” fine while you are working on it. So if you did the work “by the numbers” and ignored odd antialiasing and color shifts it might output to a film recorder and would look perfectly fine, but on your 8bit screen, without some sort of conversion, somethings gotta give.

One other tip: always use straight alphas when it comes to light effects rendered out for compositing. The renderer creates a bloom of light that extends beyond the alpha area and its the alpha that cuts off the light at the edges and puts it cleanly over the background in the composite. If you use premultiply, then the light effect is rendered on black and the black is passed through the alpha along with the light – technically it’s getting cookie cuttered twice – once in the initial render when it’s compositited by C4D on to the black and then again when it’s passed through the alpha “window” and on top of your background. This is why you will often see a dark halo on light effects comped onto light-colored backgrounds.

One other tip – rendering out quicktime severely limits your color space options. It won’t even handle a vector motion or depth pass properly in its limited space. 9 times out of 10 when someone is having depth of field issues it’s because they rendered out to a quicktime for that pass (that and the fact that C4D’s depth is just plain wrong out of the box)

I know that’s more than a simple solution answer but I think you can push and pull that file in your comper more than you think.

[Steve Bentley]

Hey Ryan,
Ya we run into this a lot. Especially when you’ve spent hours tweaking that look in the view port and then run the multipass and no transfer function in the world in the composite will get you close to the viewport look you have gotten used to.

We used to think this was a c4d dynamic range issue but as you found out if you render without multipass, no issues.
What format are you rendering to? EXR rendered at 16bit or higher might help as you can really crush things in the larger color space when you comp and pull a killer hot spot out of the glowy things. Also, try having the exr’s “preserve RGB” when they come into your compostiting program and make sure your comp is in 16 bit or higher color space.
You didn’t mention if you were GI rendering or using a thirdparty engine.

Personally I think this is caused by the way the internal composite engine works vs the transfer functions (screen, add etc) in the external packages when using multi pass, and the fact that the internal engine can combine everything before it has to pick a color space, but when you make a multipass each layer has to be “set” to a dynamic range – at least you are off to a good start with linear, although a log version might give you more headroom. We also find this problem with shadows and some glass/reflection/fresnel settings too. So it seems that the internal engine is better (or at least different) at combining light-based-glowy things than another package will do with output layers.

So try a file format with a larger range (EXR) or try just rendering out the glowy things seperatelty on your own with everything else set to a black texture that will still catch the ambient and reflected glow and then do a composite with a screen blend function – we like this the best as you can often over do the glow in the viewport after staring at it for hours – your eye gets tired and needs more and more glow to make it sexy. This way you can tone it down in the post process (but then that’s the whole idea behind multipass isn’t it!)

I too would love to know if there is something we’re missing and a proper or better way of approaching this.

[Steve Bentley]

I can open those files just fine. I’m not sure I understand the problem as I can set keyframes and it doesn’t mess things up. One thing to note is that after he (she?) does his little tapping thing if you move the other leg, it hasn’t had a key frame set since the beginning so the computer will interpolate the move you just made back to the start position over the 240 frames it takes to get to the tapping. So that might seem like its messing things up but in reality its just slowly changing the legs position over that many frames. This may be true of other limbs and their positions/rotations. Remember if you haven’t keyframed one of the three attributes for each of these two aspects (x,y,z and h, p, b) it will interpolate back to the last key frame set, or be a new key frame that will anchor that joint in place until you set another keyframe.
On another note, if you set limits or restrictions for your joints, your Ik chain will work a little smoother. Most of time you don’t want the knee to bend backwards and there are limits to how far a person (or pineapple) can raise it’s leg forwards (no really, drink enough and you will see a pineapple try!) In grabbing the one leg’s goals I was not able to make the leg bend the way I would imagine you want it to. Depending on the viewport you do this in it can look like it’s bending correctly but it ended up looking like one of those sports clips with dislocated joints that makes you wince.

[Steve Bentley]

There is definitely something up with the Xref and the cloner. I’ve yet to be able to swap out the referencing object with the real deal while the cloning heirarchy remains intact. The machine crashes (not just cinema either – the whole PC). I have to take the object out of the cloner before pointing to a reference object and then put it back in. Not a huge hardship but I thought it just didn’t work for while.

Thinking of your issue: what if you offset the time function of the cloner. Do you have a “home” pose or T pose right at the start that the cloner is fixated on? Perhaps if you tell the cloner to look down the object’s timeline it wont ever see that start pose.