I want to zoom in on a single cell to reveal receptors on its surface membrane. I have created the cell using the displacement effector and noise. And I have created the membrane with animated receptors. I’d like to zoom down in one continuous movement. My expectation is it would take separate passes, swapping models of higher and higher resolution as the destination gets closer and closer.
The issue is how to scale and swap the models while maintaining camera control? If I literally zoom in to microscopic scale, the camera controls will be unworkable - so I sense the camera needs to scale also.
I googled to see if I could find someone struggling with the same issue, but very quickly realized I don’t even know what to call such a move, so my search terms bring up unrelated topics.
If you can point me in the right direction, I think I can figure it out from there.
In your example clip, it switches in certain intervals relatively visible. I guess that is not the target here.
The production year of 1977 certainly indicates a more analog base. There was no camera move at all, so far I can tell. Just images scaled and blended. I do not get that you asked for this since that leaves any perspective change out.
As with anything in that matter, the cinematography is the point. As any cinematographer will tell you, use a dolly over a zoom shot. Zoom shots are like scaling flat images, as the camera isn’t moving, no perspective change will happen, just scale. Which is a big no-no if we talk about a good audience experience. The perspective change created by a camera move helps to immerse the audience. https://www.cineversity.com/vidplaytut/cinematography_part_07
I guess that is your target, reading along, but using the video clip just for the scale demonstration.
I would split this in different but overlapping dolly moves as well. The camera motion has to be set to linear (vs. spline) while key-framing it. The camera doesn’t change the field of view, there is just pulling in or out. Linear comes close to the video example, but it is technically not perfect.
The camera move would start framing a cube (as reference) that is maybe a 1/10 or a 1/100 in size of the cube on end. The movement goes a little bit longer to allow for a good blend (head and tail). Each scene can use the Project settings to scale, but since I’m not aware of what objects (e.g., dynamics) you will use, this must be explored in detail.
As an example, you might have a head of 24 frames, then the main part (start to end) of 240 frames, then the tail with 24 frames. So you know you match-points. The movement before and after: Timeline. Function> Track [Before/After]
Since the movement needs to change over time, the suggested set up does this, as it goes to the scale times 10 each time (1, 10, 100, 1000, each time 240 frames). However, a constantly increasing speed would come closer to the effect that even a universe’s “image” moves as fast as an image in a microscope view.
The problem is I need to zoom in on a standard-size model to reveal on its surface another standard-size model. I don’t want to change the scale of the two models in relation to each other, because (my experience) the animation controls often break in the scaling. So in this instance I opted to scale the camera path.
I set up the “macro-scale” move as a standard align-to-spline camera move. I set up reference objects to provide targets for scaling. I then packaged all that into a Null object called SplineCAM 1. I duplicated this Null and scaled it up by eye until I got large enough to frame the desired scene in the ending model. This is the “micro-scale” move. As you can see in the included MOV file, the two landing zones matched exactly - which was my goal. Hurrah!
The downside is that this approach is very time-consuming to set up, and is very twitchy to modify. The “MicroCAM” for example, is barely a dot in the scene as the wireframe reference didn’t scale. I’d like to add a couple of camera morphs so I can move around in the micro scene, but I’m scared to touch the microCAM lest it shoot off into the abyss.
It would be brilliant in the extreme if it turns out that Cinema as a click box called “scale camera” that would let me duplicate the first spline move to a new scale, with Xpresso controls to boot. Ha!
If the manual approach is the only option, I suppose I can work with it. But it isn’t the usual elegant solution Cinema is so famous for.
Thanks for the information, mford610, that was really supportive.
Initially, my understanding was that you would like to travel from 10^-20 to 10^+20, hence my suggestions to split it up in steps. With the split, one can set the project scale differently and move so the units from nanometers to kilometers, (or miles to inches). In the old days with single precision, my suggestion was to keep the parameters three digits before and three after the period (comma). I wouldn’t go only larger on the left side from the period these days either. By switching the scale, the numbers stay in that range more easily.
You like to have it in one scene file, which needs then another solution.
Scene file 01 sets up the “rig” and file 02 shows how it is workings. In a nutshell, the adjustments in the MoSpline delivers the large move, and the Align to Spline works then on the macro level (…when the MoSpline is reduced to the needed length for the details.)
As a side note, I would introduce a lot of intermediate points, as it allows for a more stable definition. The same for the MoSpline, it has adjustments as well for that.
Please test this, even I think I understand your set up, but you know of course better what is important.
P.S.: I explored a few options, like scaling the project back and fore, based on the focus point for that particular moment.
After a few different setups, here is my current best suggestion for this project. The main target was to keep the camera animation intuitive and straightforward.
The smallest part should follow the Project settings closely. So a single small object perhaps 20 cm ( Project Settings 1cm) and the large object, here as a cube as well 20,000cm. Which is the scale you have roughly 1:1,000.
The cameras, as you mentioned Camera Morph, have a few cameras towards the smaller objects, to provide a slower move. I supported this change of speed with a square curve in the Camera Morph.
Each single position camera can be moved very naturally, and you have here a large model as well as the small model in one shot.
Again, the video gave me the wrong impression, the one of a super long, near infinity, dolly move. Your scene file was vital to get the solution above. I hope it works for you.
Each scene might require different handling and set up, hence why I ask for a file each time; It just makes more sense.
Fantastic! Exactly the right approach. Project Scale is the magic button (I knew there was one)! Scaling the camera was a novice, desperate move (even though it seemed to work). However, changing the project scale on the destination model before importing it into the composition very simply and accurately solved the problem. Elegant! My confidence in Cinema is restored!
Also, your demonstration of controlling the Camera Morph helps lift the veil on the inner workings. That will be the approach going forward.
One last question re: project scale - I changed the scale on the destination model from 1 cm to 1 mm before I imported it, which turns out to fit the composition exactly right. However, clicking on any of the component parts of the imported model reveals they are all still at default scale (i.e. 78.74 inches), even though the composition displays them ten times smaller. I have no argument with that - I assume that will make it easier to make adjustments. But it seems odd. I would have expected the project scale parameter to be applied throughout the model dimensions. Perhaps project scale is just an envelope to contain the full-size model; sort of like the Genie’s lamp? (unlimited cosmic power - itty, bitty living space)?
Your last question is not clear to me, where do you change the units from cm to mm? In Cinema 4D. Which format?
I could think of a few combinations, so I can’t really reproduce what you have done. Two scene files would be needed to clear that: The original source file and the c4d file with the import.
Or, export one cube out with 100cm (in size for x, y, and z) and export it in your mainly used format in cm. Then import it in a new scene, if settings in the import dialog are available: as cm as well. This allows for a clear understanding of what the Project Scale/Units does.
In the old days, the numbers were the absolute units, and the differentiation in cm, mm, or inch was just a label. With Dynamics and other requirements for real-world scale, this has been changed. But I assume, it needs some exploration to get an idea about it. If the Import scale is not in agreement with the Project scale, the size will change.
“CV_p1 Receptor Group 1 Scaled x1000” is the receptor model with the scale set to 1 mm in the Project Settings.
“CV_p2 ScaleCAM Demo” is the composition project into which I imported “CV_p1 Receptor Group 1 Scaled x1000” and is contained within the Receptor Group 1 Null. As you can see, the objects in the imported Null have been scaled down to fit on the tip of one of the cell projections (even though the coordinates manager shows them to be full size).
It was this that prompted me to shout Eureka!
However, after your response I went back and tried to repeat the feat to demonstrate how I did it, but this time the so-called “Scaled x1000” model comes in at full size, not scaled down as before. Multiple repeats, same result.
So what could have happened that first time to make it scale? There is no doubt it is indeed scaled - it’s sitting right there. But I must have done something on the import to change it without knowing I did.
Sorry this has turned into such a chore. Please feel free to leave the discussion for another time - I’m able to carry on using the former technique of scaling the camera path. It’s more laborious, but at least I understand it.
This clears much more what you were doing. I was not clear before if you a format other than ‘.c4d’ and have then during import the scale question (units) as well, nor was it clear if you set up the models in a 3rd party app.
It is all inside of Cinema4D, which eliminates so many points for cases of “lost in translation”, speaking of scale.
I get your point that you like to focus on the method you feel comfortable with. I also understand that you want to move the discussion to a later point.
If that time is there to explore the scale, perhaps try this, set up a cube with 100 cm. Save it. Then open up a new scene and load the cube file with XRef. Set a Torus object around the Cube to have a reference.
Go back to the cube-file and change the project settings from cm to mm or meter. Save it. Back in the Xref containing file, go to XRef> Attribute Manager> Object> Reload. Can you see what happens?
There are three different options, how the units are shows, is in the Preferences: Units
What the numbers mean that one puts into the parameters fields: Project Scale.
The button with the Project scale that moves the real size up and down.
As mentioned, the more you go to the right side after the period, the less you feel comfortable so the second option might be the best here. Again, explore it until you feel well with it.
Well, a fourth option is often given while importing or exporting.
The main scale of the object is not included in my list, as it is only in a limited way a general option.
XRef is the magic button! It works perfectly (and repeatably). And it avoids the concern I had about tweaking the animation in scale. I see this has been around since R13 so it’s undoubtedly quite robust. Could I have somehow enabled the XRef functionality accidentally? However, it happened, I’m relieved to see it’s so easy.
Thank you for your patience! This has been a long way around the barn (an American idiom for inefficiency). As is often the situation, I don’t know enough of the nomenclature to accurately define the problem I’m trying to solve (hence the detour around Powers of Ten). And that’s a big handicap for the expert trying to help. But now all is clear and I can see where success is hiding.
The XRef for direct use is undoubtedly stable, but in some instances, things might not work. Since you mentioned R13, where a better approach was implemented, I assume you have read the manual, for anyone following along here: https://help.maxon.net/us/#OXREF
It helps to get the most out of it.
Thanks for mentioning the Power of Ten source. Yes, what you know and see in something, might not result what others see in the same material. The main problem-solving issues via a forum is undoubtedly the limited interaction while doing so. When everything is working, someone else might question why it took so long (ignoring that a given solution creates a different perspective on the case of course. Besides that, I know that at least 3/4 of all questions here are based on the point where someone got stuck. Whereby I like to see the origin of the problem and solve from there. Otherwise, we end up with a patch, of a patch, of a patch. In other words: a mess.
Thanks for the idiom definition. When I moved to L.A., CA, nearly one and a half decades ago, I bought a whole book about idiom and some other sources. It was valuable, as your refresher. Thanks for that, especially since we have people here from around the world.