[Steve Bentley]

Ah thats right; I spilled ketchup on the keyboard last week – that explains it. First three ingredients are HFCS!
I’ve got the SubD working again by deleting the C4D prefs. so that’s something at least, but still a mystery on the slow resolve rate of the materials. Same project is on another machine and there are no issues on that box. I’ve been wondering if its a card/OGL issue.

[Steve Bentley]

Perfect job for the cloner and mograph. Even more perfect if you have R20 and above because you could use a moving noise and fields to have the villi wave in the current (you can get there in pre-R20 but its a little harder).
I would use a number of slightly different villi objects under the clone so they aren’t all the same and you can “stick” them to the surface of the tube using object mode and “surface” to get them scattered around. Depending on your intestine model you have may have to reverse the normals to get the villi on the inside, but if the tube is meant to be viewed from inside the normals should already be right.

[Steve Bentley]

There’s two things at work there (I think – wasn’t sure based on description but I’ll take a stab). There’s snapping in the view port (the magnet icon) and the same kind of thing in the Fcurves. But its called Quantization. You can turn that off in the timeline prefs. Quantization acts like snapping to discreet frames. This way as you move keyframes about you don’t get keyframes landing between frames – nothing wrong with this, the system will still work things out correctly no matter where keyframes are, but as you tweak the animation and add new keyframes or think you are editing old keyframes you can accidentally put a changed keyframe on a integer frame while an older keyframe is lurking half a frame away – this can produce some odd jumps especially with motion blur

[Steve Bentley]

It really depends on how the render is stopped. If C4D gets to close the file that is has been laying to disk then yes you can play that file, and then start the render again, joining the two movies later. This is the same for QT movies. If there is a crash or you happened to hit stop just as the file was being worked on (mid save on a frame) that file may not get closed properly and it will be corrupt.
As a general rule its better to save to frames. This way if there is a crash it only affects that one frame and all the others are still intact. The picture viewer can play frames out as if they are joined in a movie, so you don’t need to make a movie in another program to see it in motion, so there’s really no reason not to render to frames. Plus rendering as frames let you render in some very useful formats that you can’t really do as a movie (EXR for instance)

[Steve Bentley]

Is “sub polygon displacement” turned on in the render settings/options? I mean I can’t see it working in the view port render if its not, but its worth a look.

[Steve Bentley]

Here we go again. R19 Win7
Its been going well and now suddenly, what I thought was a cache issue has turned out to be a viewport vs render issue. Attached are the files and images from view port render and the render engine.
The view port view is reasonable and an expected result (and it also matches a non viewport-render viewport working view). But the render version is just out to lunch. But of course the render version is the one that matters. I can’t imagine how C4d gets to the render version given the single guide hair.
I’ve turned off all the waves and curl etc in the shader to try and simplify and target the problem. I’ve removed all other hair objects in case its a memory issue (but on a 128GB machine I can’t imagine that).
This has happened in the past and as per the sage advice of others here I’ve turned off the cache in the hair object (which just makes manipulation in the viewport handleable anyway). This cache-off solution has worked everytime this has happened so far. But not this time.
I’ve sent this file to other machines, I’ve restarted, i’ve used chicken blood and howled at the moon. I’m stuck.
Thoughts?


13910_backstrandexport.c4d.zip

[Steve Bentley]

Once I’m done I’ll fire it into R21 and see. This is an ongoing project that we update a few times a year and the changes to R20 broke it so we had to stay in 19 for this one.

Since turning the cache off and deleting the latest bad hair object its been behaving. So I’ll get the renders on and then check the reset you suggest. Historically when we do that we lose the grooming and we get the guides going back to their “straight out from normal” positions, and that’s not undoable even when you have the “undo dynamics” turned on in the prefs. So I’m always leery.

While I’m always amazed at what the hair system can do (and appalled at the examples provided my Maxon, given what could have been generated) , I’m equally appalled at the flakeyness of the hair system, it doesn’t take much for it to break.

[Steve Bentley]

Ya I’m only displaying 1 percent (and that’s 1 percent of 10,000 hairs, 60 segments) so its not a crazy amount of hairs. To be fair i’ve got 6 hair objects going (with the same or lesser amounts) but still, on a 128gb system, if it can’t handle that then that’s lousy coding .
I’ve tried cache in the editor on and off (I wish there was a flush button like there is for other features in C4D). It just seems to go bad after a while of working with it and massaging the settings.
I can work with just guides on (only about 6 guides per hair object) but then I never know when the hair fails as the guides are always solid. If I go too far after the failure, that failure sticks and then corrupts the hair object in question forever and grays out the hair count in the attributes. I often don’t catch the failure right away and continue working, but caught in time, a save, quit and restart will make the file as right as rain.
Hair is tedious enough to get right without this restart delay vexing me every 20 min or so.
Oddly, if I render the failed hair object, it renders just the guides.

[Steve Bentley]

Thanks Sam I’ll give that whirl.
While I’m on the subject, I’m having a devil of a time with what I assume is faults in the hair caches. I’m not using dynamics (its turned off in the hair tags) but as I’m getting closer to refining the hair, it will fail and I’ll have hairs shooting places where guides are not (both in viewport and in a render). I know its caches because if I save, quit, restart (and yes restart is required) its back to where it should be. Is there a way to flush these hair caches while in the app? This restart thing is just wasting soo much time.
R19 win7

[Steve Bentley]

If they can be just 2D planes of imagery on flats then we usually hide the spot where that image plane meets the ground plane with some debris just in front of the plants. So some true 3D rocks scattered about or some 3D grasses (hair or mograph). If you really want to go crazy you can use the image as a deformation map in the material and that way the bushes will have a bit of outward geometry (not true of course but that far back it should work).

Its all about breaking up the alpha of the plants where they touch the ground.

Make sure to layer your shrubbery (“with a nice little path..Neee!”) so some is in front and some behind and that way they parallax when the camera moves. You can also use a target tag to make sure they always face camera so you don’t ever see they are truly flat. This only works for subtle camera moves – too much and you will realize they are rotating in relationship to everything else.