Experimental swooping camera path technique

Check it out. It has some limitations and possibly some issues (though I think I ironed out most of those), but on the other hand, the entire camera path took me 10 minutes or so, and I could do plenty more just as fast. Plus it doesn't involve entering numbers and is done 100% visually. The (optional) banking and rolling is part of the path. The only thing extra is 5 or 6 triggers at various points to tilt the camera up and down.

--Eric

 

Looks nice. How did you go about doing it? Is it a script on the camera that goes waypoint to waypoint, so you just set up the waypoints?

 

No waypoints. For a clue, try the arrow keys.... (The whole thing is done in Blender, except for a few triggers set up in Unity as mentioned, for a little extra control.)

--Eric

 

So, did you set up the "tunnel" in blender along with the cube? That is pretty clever. Works really well also.

 

Yep...3D paths are simple in Blender, and you can apply tilt at any point (for the banking). You can also make shapes using paths by applying a cross-section, so I made a square as the cross-section and converted it to a mesh, flipped the normals so they point inside, and voila. The "tram car" thing is a sphere and cube combo collider so it follows the path more or less precisely without getting stuck too much. (I was using just a sphere at first which worked fine, but you don't get any tilt info out of that, then I tried just a cube but that had a tendency to jam occasionally and unpredictably.) Even with no friction and no drag, it still slows down after a while, so it's got a tiny little script that gives it a boost every few seconds. I made a modified smooth camera script, but the tram car is still way too erratic for the smooth camera to follow, er, smoothly, so it has an intermediary empty that follows behind a certain number of fixed frames (I think I've got it set at 100), and averages out the motion for those frames, which takes care of the hiccups. That's what the camera's actually following.

--Eric

 

Would you mind going into a little more detail about how you created the path in blender, smoothed it, and converted it into a long square tunnel? You solution is amazingly close to a camera system I am trying to implement. Plus we're both using blender, and limited to no animations, etc... Thanks!

 

You want the project file? I just need some space to upload it...it's not that big, but I don't really have any space myself.

In Blender, you just do Add -> Curve -> Path to get a 3D path. Then you can extend it as much as you want (use the E key), and it's a vector, so it's 100% smooth at all times as long as it's a path and not converted to a mesh (worth keeping a copy of the vector path in case you ever want to change it). I usually do some overhead points, then a side view to get the height right for those points, then back to overhead, etc. until done.

Then you need a separate curve for the cross section. It can be anything, but for a square, just do Add -> Curve -> Bezier Circle, then hit V, which gives you straight vectors...instant square. Make that the bevel object ("BevOb" as it's loquaciously known in Blender). Presto, instant tunnel. You can change the default resolution to get more or less smoothing when converting to a mesh; the default is 6, and I think I used 5 for that tunnel. It ended up somewhere around 3000 polygons or so. After converting to a mesh, do a select all points and then W followed by 0 (zero) to quickly flip normals to inside. Done! T tilts any selected points, BTW.

There are some limitations to paths this way due to the way Blender handles what's "up"...check the docs for that. Basically, no loop-de-loops unless you want to join multiple paths.

By the way, I've found that it's better to import Blender meshes directly into Unity if you're getting at all complex. That is, not the parent object that corrects the rotation. I've been correcting the rotation myself in Blender before importing, because otherwise I was getting some slowness and crashiness. Since going the direct way, those problems went away completely.

--Eric

 

This looks really cool although I don't quite understand what it's purpose is beyond coolness.

 

The purpose is to have a path for the camera, like for level fly-bys or demos or cutscenes or whatever, and to do it in such a way that setting up each path takes a small amount of time and is easy to do. (Normally the path probably wouldn't be as long as that; that was just for demonstration purposes.)

--Eric

 

I've experimented with this a little bit, and I'm curious about the processing overhead for creating a camera path out of a mesh physics. After playing with this a bit today, I think I am going to stick with animations for camera movement for the immediate future. It's possible that this could provide a little more flexibility (it has already taught me new tricks in Blender!) but there are some hiccups in the workflow and I'm worried about performance loss. Maybe one of the kind OTEE gents can chime in with any performance information relevant to this system.

 

Well...that's one thing I'm not really concerned about. The stand-alone app gets between 680 and 940 fps here at 1280x960, mostly staying in the upper-700s. It's obvious from the framerate variation that drawing stuff on the screen accounts for most of the "performance hit," if you want to call it that. The method uses just a couple of colliders and one mesh, which is pretty trivial. In my ideal world, Unity would have the ability to read 3D paths directly, removing the mesh+physics thing entirely, but in the meantime I think I might end up using this method for when I need it. The main drawback seems to be the multiple levels of smoothing required to get anything usable, which means you can't really get much precision with the resulting camera movement. (On the other hand, I really like being able to visually see what the camera path approximately is.)

--Eric

 

We've used imported camera paths from maya - It is simply a question of Blender animations not exporting. When they get that fixed, you'll be fine.

Until then, this swooping camera path techinque seems pretty nice as you're using the same input method (blender path) as you'll be doing in the final

 

What's the performance cost of calculating collisions for high poly mesh colliders and rendering them, vs just performing the calculations?

 

Nice one Eric. I too would be keen to see a UnityPackage if poss. Provided its not huge you could post it on this thread, alternatively I have 5mb of webspace and could host it for a week or so, and then theres Jeff at Bluegill who I'm sure would be interested too. This is kinda how I'd like to try cinematics. Its great to see peoples work as it gives us all a bit more scope.
AC

 

Just thinking aloud on this idea .... would it not be possible to use the mesh interface to access the verteces in a blender-created mesh directly and avoid the collider technique altogether ?

Effectively you could treat the mesh a bit like a path then.

Paul

 

By taking the skybox out, I got it a little under 1 MB so I'm posting it here. You want to open the Assets/camassets/cameratest scene file. Note that the scale is pretty huge, so I increased the timescale by 2 or 3 to get through the path in a more reasonable time. You can of course apply more speed and tweak various parameters to get similar results in real time, but it's already going 10m/s so it's probably not "realistic" to go much faster in that sort of area.

I actually wondered about that myself, but I don't have the skillz....

--Eric