Loading...
> >

Bryce 7 shaky camera Tutorial

Francis TaylorFrancis Taylor Posts: 84
edited February 2013 in Bryce Discussion

Ok. Sorry for the delay as i didn't expect such a backlash. Anyways lets get started.

The first thing you want to do is create a Path preferably Water Rafting. You can straighten the path with its control points if you want to tone down the "shakiness", or if you want to change the direction your camera points, it's up to you. I encourage you to experiment with different paths for different results. As long as the principle of the technique remains, any path can be used to achieve the desired shot.

path.jpg
1920 x 1080 - 366K
Post edited by Francis Taylor on

Comments

  • Francis TaylorFrancis Taylor Posts: 84
    edited February 2013

    The second step would be to create a primitive sphere. Go into the attributes and mark the sphere hidden. I name mine birdie.

    path-11.jpg
    350 x 463 - 58K
    path-3.jpg
    1920 x 1080 - 345K
    Post edited by Francis Taylor on
  • Francis TaylorFrancis Taylor Posts: 84
    edited February 2013

    The next step is to parent the path with the sphere and constrain the sphere to the path.

    path-6.jpg
    387 x 475 - 51K
    path-5.jpg
    381 x 457 - 55K
    Post edited by Francis Taylor on
  • Francis TaylorFrancis Taylor Posts: 84
    edited February 2013

    The next step is to have your camera track the sphere that is constrained to the path.

    path-10.jpg
    327 x 431 - 34K
    Post edited by Francis Taylor on
  • Francis TaylorFrancis Taylor Posts: 84
    edited February 2013

    And finally the last step is to scrub the timeline as desired and move the sphere along the path. This how we get the smooth movement variation as opposed to the jerky variation seen in most bryce animations. A lot simpler than many thought it would be.

    path-9.jpg
    1920 x 1080 - 306K
    Post edited by Francis Taylor on
  • Francis TaylorFrancis Taylor Posts: 84
    edited February 2013

    The final results according to this tutorial should look like this. I placed a cube in the vicinity of the path & sphere so you can see the spatial relationship between the camera & objects.

    http://www.youtube.com/watch?v=yYuErqzJaa0

    Post edited by Francis Taylor on
  • OroborosOroboros Posts: 326
    edited December 1969

    Great stuff, Thanks fran :)

    I've been meaning to do a sequel to a fly-bounce tutorial I put up ages ago as an advanced tutorial ('advanced' doesn't mean much for Bryce animation as the tools are relatively simple) but I'm in the process of re-modelling this thing:

    http://www.youtube.com/watch?v=jqPnGeAK_dY

    (Yeah, sorry for trotting it out yet again)

    So when the ship and textures get re-crafted I'll use it to illustrate my animation process.

  • LordHardDrivenLordHardDriven Posts: 937
    edited December 1969

    So I guess then that means that the paths in Bryce aren't quite as unusable as has been previously suggested (not by you fran444). They just can't be effectively used as is?

  • OroborosOroboros Posts: 326
    edited February 2013

    @LHD: You'll note two things:

    1) Mr Taylor neither created nor modified the path selected.

    2) Mr Taylor used a sphere for tracking, which will still flip over at the 50% point of the path, but as it's hidden and the orientation is irrelevant for tracking in this specific application, and no-one will notice if a sphere is upside-down or not.

    Paths are still an unreliable, dodgy, broken feature in Bryce. But (especially for the Mac) like Families, Instancing and some other features, if you are persistent and have a high tolerance for working around the flaws, and most importantly DON'T ALTER THINGS you can achieve great results.

    Post edited by Oroboros on
  • LordHardDrivenLordHardDriven Posts: 937
    edited December 1969

    Oroboros said:
    @LHD: You'll note two things:

    1) Mr Taylor neither created nor modified the path selected.

    2) Mr Taylor used a sphere for tracking, which will still flip over at the 50% point of the path, but as it's hidden and the orientation is irrelevant for tracking in this specific application, and no-one will notice if a sphere is upside-down or not.

    Paths are still an unreliable, dodgy, broken feature in Bryce. But (especially for the Mac) like Families, Instancing and some other features, if you are persistent and have a high tolerance for working around the flaws, and most importantly DON'T ALTER THINGS you can achieve great results.

    Ah okay, I guess I misunderstood, I thought when he said "And finally the last step is to scrub the timeline as desired and move the sphere along the path." that was in esscence, modifying the path? Being that it's part of an animation I would think modification could apply to any change to the timeline? Still in the discussion where it was said that the paths that came with Bryce are broken, I don't recall it being specified that the creation and or modification of a path had anything to do with the paths that come with Bryce being broken. The impression I got was that if you open Bryce and choose any of the premade paths that come with it, you'll find they don't work right. It looks to me like what Fran444 is instructing people to do, select one of the premade paths, specifically water rafting and use that. Based on what I understood from the other discussion this should mean the animation is broken.

    Now maybe it is because it's so simple and using a sphere you don't see the flip? Maybe it wasn't long enough to hit the flipping point? I mean given as much animation as Fran444 has obviously done and the quality of them, surely he's encountered this problem? So unless his instructions somehow fix that problem one would be inclined to think he would mention there is this problem inherent with the paths? Yet he did not. So I'm merely trying to determine if that's the case or did he forget to mention this problem? I mean doesn't scrubbing a timeline mean going thru it frame by frame making sure things are right and adding keyframes where you feel it's necessary?

  • OroborosOroboros Posts: 326
    edited February 2013

    LordHardDriven said:
    Oroboros said:
    But (especially for the Mac) like Families, Instancing and some other features, if you are persistent and have a high tolerance for working around the flaws, and most importantly DON'T ALTER THINGS you can achieve great results.

    Ah okay, I guess I misunderstood, I thought when he said "And finally the last step is to scrub the timeline as desired and move the sphere along the path." that was in esscence, modifying the path?

    No. That's altering the timeline. As an analogy, consider a car driving on a road. The location of the car at any point in time doesn't alter the road.

    This is the major structural difference between a path and a trajectory. A trajectory has time locations embedded within the shape of the curve. Keyframes not only define time points, they define shape points. Also, there's a funny 'easing' timeline built into a trajectory: time and space are intimately linked in a trajectory and affect acceleration in the curve of a trajectory. Your understanding is perfectly correct for a trajectory...

    ... Until you turn that trajectory into a path. Paths completely shed all preconceived notions of embedded time.

    For example: Say you created a complex trajectory that starts at time=0, and finishes at time=10 seconds. In that time there are curves, loops, corners and several other keyframe points. You then convert the trajectory into a path*. Now, your new path has no defined time component. It's just a snake-like shape. It could take 10 seconds to traverse it, or 50 minutes, or 6 frames. Your choice. You can even go BACKWARDS on the path as time marches on.

    Being that it's part of an animation I would think modification could apply to any change to the timeline?

    You can change the shape path over time*. The path still retains keyframe points, but now these points are strictly shape vectors and have nothing to do with time.

    Mr Taylor did not say anything about changing the path, or editing the shape of the path over time. However, you can*.


    Still in the discussion where it was said that the paths that came with Bryce are broken, I don't recall it being specified that the creation and or modification of a path had anything to do with the paths that come with Bryce being broken.

    The paths that come with Bryce aren't broken, as such. When I stated 'Don't use them. They are broken.' I meant the USE of paths is inconsistent, corruptive and overall, frustrating. My apologies for the confusion. My context was in a post from a very new user looking to learn what paths did. I told him: they're unreliable, don't use them. fran444 used them successfully: that's great. I'm wiling to bet he crashed his comp a couple of times when he tried to change the curvature of them, but when he found out you could just copy the library paths, bind an object to them and leave them the hell alone, he got results.

    This is not a workflow. This is a work-AROUND.

    Now maybe it is because it's so simple and using a sphere you don't see the flip? Maybe it wasn't long enough to hit the flipping point? I mean given as much animation as Fran444 has obviously done and the quality of them, surely he's encountered this problem?

    I dunno. I've already said: in his use of paths for camera work he didn't try to change the curvature, and this hidden object is used for tracking, not orientation. Whether the object flips, resizes or changes textures on the path is irrelevant for tracking: it's the object's location on the path that's important. He could've used an object of a plane or a DAZ figurine: tracking follows the object's origin location, not the object's orientation.

    Hope this helps :)


    * But not without suffering a blisteringly large number of hangs and crashes, in my experience.

    Post edited by Oroboros on
  • Francis TaylorFrancis Taylor Posts: 84
    edited February 2013

    I’m wiling to bet he crashed his comp a couple of times when he tried to change the curvature of them, but when he found out you could just copy the library paths, bind an object to them and leave them the hell alone, he got results.

    This is not a workflow. This is a work-AROUND.

    Well actually, I change the curvature of my tracking paths all the time. If i want to tone down the motion of the camera i straighten out the water rafting path with its control points. Similar to manipulating a Bézier curve. I've actually never encountered a problem with paths, my computer has never crashed using them. I use a Lenovo E31 Graphics workstation, so it's well equipped to handle extremely stressful graphical applications.

    I encourage you to experiment with different paths for different results. As long as the principle of the technique remains, any path can be used to achieve the desired shot.

    Post edited by Francis Taylor on
  • OroborosOroboros Posts: 326
    edited December 1969

    Thanks for the info fran.

    I'm afraid my experience differs greatly from yours. Often using the tension modifier on either trajectories or paths crashes me to the desktop on both Bryce 6 and 7. Scenes I've created using paths on the Mac somehow don't open on some PCs. Objects bound to paths often flip upside down at the halfway point, as if the object has an orientation set to the 50% point of a path: usually they flip upside down and STAY upside-down, no matter whether you re-position the object back to the beginning of your path or if you undo the operation that caused the flip.

    Since DAZ took Bryce from 5 to 5.5, new features in the Mac build have just increased its fragility, and inconsistencies in the PC build require computer power untelegraphed in DAZ's minimum requirements. This suspicion seems to be borne out if you have a dedicated graphics workstation on the Windows platform.

    I encourage you to experiment with different paths for different results. As long as the principle of the technique remains, any path can be used to achieve the desired shot.

    I'm afraid I personally won't oblige :) Honest: most of my work in Bryce is animation these days. I enjoyed using paths back in the day. But today I tend to stick with a series of work-arounds that avoid the numerous pitfalls I've encountered with paths. My Best Practice guide goes like this:

    • Limit scenes to about 3 - 5 keyframes per object trajectory - Multi-keyframe sequences become tedious to manage.
    • Don't use the Tension modifier to create negative tensions that result in loops - Easy to do accidentally, and often crashes Bryce.
    • Always use Autokey mode - Often, material animation keyframes don't register, even with a manual click, with it off.
    • Only set keyframes for the parameters you require - This is admin, and helps keep the teeny-tiny AML manageable
    • Use objects you don't model with for tracking - Using unique objects in your scene makes it easy to select with the Object select palette. So if you're using a lot of spheres, cylinders and cubes to model, track a hidden stone object.
    • Don't try to select with Families. (For PCs it's fine. For Macs, it's a crash zone. Be wary of this if you're in a collaborative group like I am.)
    • Use parenting rather than Boolean ops wherever possible. Boolean ops just for grouping objects together creates additional wireframe clutter, making it hard to see through your animation.

    Now... Some people will have no problems with any of the things listed above. Honestly, that's great, all power to you. But often I'm dealing with multiple object scenes composed of several boolean groups and sometimes, pretty intricate movement. these scenes take ages to compose. Any failing that causes me to lose hours of work is a dagger in my head. If it happens occasionally, that's enough for me to lose days.

    There's a tutorial I did on removing fly-bounce, and in it I described the use of the Tension modifier. While flippant in delivery, I was very careful not to create a reversed loop by dragging the tension way into a negative value, because Bryce crashed twice beforehand when I did this.

  • LordHardDrivenLordHardDriven Posts: 937
    edited December 1969

    Oroboros said:
    LordHardDriven said:
    Oroboros said:
    But (especially for the Mac) like Families, Instancing and some other features, if you are persistent and have a high tolerance for working around the flaws, and most importantly DON'T ALTER THINGS you can achieve great results.

    Ah okay, I guess I misunderstood, I thought when he said "And finally the last step is to scrub the timeline as desired and move the sphere along the path." that was in esscence, modifying the path?

    No. That's altering the timeline. As an analogy, consider a car driving on a road. The location of the car at any point in time doesn't alter the road.

    This is the major structural difference between a path and a trajectory. A trajectory has time locations embedded within the shape of the curve. Keyframes not only define time points, they define shape points. Also, there's a funny 'easing' timeline built into a trajectory: time and space are intimately linked in a trajectory and affect acceleration in the curve of a trajectory. Your understanding is perfectly correct for a trajectory...

    ... Until you turn that trajectory into a path. Paths completely shed all preconceived notions of embedded time.

    For example: Say you created a complex trajectory that starts at time=0, and finishes at time=10 seconds. In that time there are curves, loops, corners and several other keyframe points. You then convert the trajectory into a path*. Now, your new path has no defined time component. It's just a snake-like shape. It could take 10 seconds to traverse it, or 50 minutes, or 6 frames. Your choice. You can even go BACKWARDS on the path as time marches on.

    Being that it's part of an animation I would think modification could apply to any change to the timeline?

    You can change the shape path over time*. The path still retains keyframe points, but now these points are strictly shape vectors and have nothing to do with time.

    Mr Taylor did not say anything about changing the path, or editing the shape of the path over time. However, you can*.


    Still in the discussion where it was said that the paths that came with Bryce are broken, I don't recall it being specified that the creation and or modification of a path had anything to do with the paths that come with Bryce being broken.

    The paths that come with Bryce aren't broken, as such. When I stated 'Don't use them. They are broken.' I meant the USE of paths is inconsistent, corruptive and overall, frustrating. My apologies for the confusion. My context was in a post from a very new user looking to learn what paths did. I told him: they're unreliable, don't use them. fran444 used them successfully: that's great. I'm wiling to bet he crashed his comp a couple of times when he tried to change the curvature of them, but when he found out you could just copy the library paths, bind an object to them and leave them the hell alone, he got results.

    This is not a workflow. This is a work-AROUND.

    Now maybe it is because it's so simple and using a sphere you don't see the flip? Maybe it wasn't long enough to hit the flipping point? I mean given as much animation as Fran444 has obviously done and the quality of them, surely he's encountered this problem?

    I dunno. I've already said: in his use of paths for camera work he didn't try to change the curvature, and this hidden object is used for tracking, not orientation. Whether the object flips, resizes or changes textures on the path is irrelevant for tracking: it's the object's location on the path that's important. He could've used an object of a plane or a DAZ figurine: tracking follows the object's origin location, not the object's orientation.

    Hope this helps :)


    * But not without suffering a blisteringly large number of hangs and crashes, in my experience.

    Okay, thanks for going into more detail. I took your comment in the other thread as literal rather then something tailored to the experience level of the person you were replying to. Not that you've indicated your comment was influenced by his exerience level I understabd your meaning a bit better.

Sign In or Register to comment.