From: [Re: Preview - Sketchup Floating Camera [Update 2011-03-19]]](http://forums.sketchucation.com/posting.php?mode)

@tspco said:

A short video using Floating Camera and Camera Recorder
http://youtu.be/9mDYQBtYC04

Thanks for the example Ryan

I see a couple of things to add/fix in the next release. The first is analog support. In your video its quite noticable that you jump between the forward and left directions. I'm guessing that this is probably not ideal and that analog/gamepad support would solve this.

The other issue is a combination of Floating Camera and Camera Recorder. The poor frame rate could be hardware related. What I mean is that the combination of running Camera Recorder and Floating Camera at the same time is too taxing on your cpu + gpu that Camera Recorder isn't recording even steps between frames (ie. one frame would represent 0.1667 seconds, the other 0.24, another 0.18). This is probably whats causing the uneven jumps between frames. I'll look into some interpolation features to resolve this.

thanks again

-niall

@bertier said:

is your plugin compatible with 3Dconnexion controller from logitech ?

this is a great analog controller for SU8

If you're refering to the SpaceNavigator, the short answer is no. There are a couple of bodges that would make SpaceNavigator compatible with Floating Camera (ie. using ControllerMate/XPadder to re-jig the controls to keyboard output) but I'm getting increasingly unhappy with these. My main concern for the next release is controller integration and there's a raft of things that I'm unsure about so I can't confirm either way that the SpaceNavigator will be compatible with Floating Camera.

Out of curiousity, what kind of problems are you having or what kind of features are you lacking with the existing SpaceNavigator & Sketchup support?

@tspco said:

I think I missed something, I tried a test "float" everything was great and working real well until I ended up underneath my model, I could see that was going to happen. I see there is a toggle to maintain camera height, but I can't find a place to enter camera height. So far I like this plugin.

Hi Ryan, I'm working on user input for camera height and field of view for the next version. In your case this would be an issue since camera height works by checking if there is any geometry below the camera position. Since you're underneath your model, there's no geometry, so there's no camera height, so you'll need to move the camera up until you're above the model. The default keys to move the camera up and down are shift and control respectively.

Also, you can modify or find out the keys for specific movement in Floating Camera by loading the controls dialog (click the icon in the toolbar that looks like a c-key).

Hope this helps.

-niall

@unknownuser said:

Any news on a release date?

Hi Phil, you can try out the public beta at Floating Camera Public Beta 1.x Thread. I've updated the main post with a link to this too.

@unknownuser said:

Hi,

Very nice plugin!

Thanks Yoni

@unknownuser said:

1. Works really well the minute you get the speed right! around 400-500 km\h max works good for me. I'm working on a model that is in cm. for some reason I don't believe I am traveling at 500 km\h. It must be a bug in the units or something.

It is an error on my part, my unit conversion isn't working like it should for any model units other than millimeters. In the next release (which should be available in about 3 weeks) this is fixed. There's a raft of other changes and some unrelated work that's delaying the release.

@unknownuser said:

2. I tried recording the movement with 'camera recorder' and it works pretty well!
   Are there any other good ways to record the movement? Are you thinking of integrating something like that?

Camera recorder is probably the best thing available for recording the camera movements, but it does have some issues as you've probably noticed. This is because Camera recorder was based on Sketchup's walk tool. Floating Camera added features that are outside the scope of the walk tool. To get a good recorded camera path from Floating Camera you'd need a script that can smoothly interpolate camera positions, that can store camera data (like roll, interval, fov, etc) as attributes or definitions, and that can provide a good suite of editing tools to edit all of this data. It's quite a mean feat of coding so no promises, but I am looking into this.

@unknownuser said:

3. For maximum control, I would suggest to add the option for controlling 'pitch'(up and down) and 'yaw'(left and right) with the keyboard and not only with the mouse.

I'm probably more of a fan of the mouse than you are. In sketchup the mouse represents the only analog input, so it gives you a smooth gradation of control over pitch and yaw.

The problem with keyboard inputs is that they're either all or none. This is probably ok with PC games like 'Descent II' as you're using these keys in an early video game environment (you sort of overlook/accept the violent way that you control the game). From a video presentation perspective, its really really bad.

The way I see it is that Floating Camera is designed for two purposes: 1. to provide a simple interactive navigation in Sketchup, 2. to produce smooth camera paths for export to video. For both of these purposes the keyboard + mouse combo isn't really ideal. I'm looking at 5th/6th generation console controller integration for the next release, as these provide the best of both worlds (IMO). They're an easy to use navigation controller, and they provide very, very smooth control. The only problem is what I mentioned before, the mouse is the only analog input to sketchup through ruby. I'm working around this by using the keyboard as a binary system, which is probably not the best idea, but it'll provide smoother camera control without the need to write a huge C++ script to get gamepad inputs into sketchup.

I'm currently working with:
PS3 Sixaxis controller (usb input) (cheapest option)
XBOX 360 Wireless controller with a wireless gaming receiver
XBOX Kinect (lots of setup required, but almost no troubleshooting)

I'm currently ignoring with prejudice
Wii remote (interesting, but not enough analog inputs)
PS3 Move (?)

If you've got any suggestions I'd love to hear them

@unknownuser said:

5. Holding down Shift was used for Run/Walk mode - would be nice too!

Hopefully using more analog inputs will negate the need for this, but I guess it would be nice to have to save a few seconds between camera setup.

@bentleykfrog said:

Just to double-check my logic: on outer loops edge.reversed_in? will return true if the start and end vertex of the edge is running clockwise (if your looking against the normal of the face [the negative face normal vector is the vector for determining clockwise or anti-clockwise]). On inner loops (face.loops - face.outer_loop) edge.reversed_in will return true if the start and end vertex of the edge is running counter-clockwise?

I'm probably getting a bit off topic here, so to sum up, when you're looking against the normal of the face edge.reversed_in? returns true when the face is on the left hand side of the edge, and false when on the right hand side of the face (irrespective of inner and outer loops, so disregard my previous assumption).

@mac1 said:

Once one determines the angle value the inverse trig functions calculate the principal value. Therefore to determine the actual angle logic must be use either in the method or in the program its self to determine the correct quadrant. Give one can get the cos from the dot product, sine from the cross and even tangent from tan( theta) = |V1xV2|/ (V1 dot V2) then it is possible to establish the quadrant??

I agree, the problem I had in Sketchup (I think) is determining a consistent cross and dot product vectors. Once you've established consistent methods for determining these, you should be good to go.

In my case I'm trying to define a 2d manifold. What's important in a 2d manifold is the angle between two faces (complex polygons) at a common edge. Given this angle, we can establish 2d manifold errors (like an edge sharing 3 or more faces).

To establish this angle we need three vectors: 'the edge vector normal on the first face', 'the face normal' & the 'the edge vector normal on the second face'. edge.reversed_in? seems to be a very consistent way to get the right edge vector normals. Also, to eliminate errors with faces that are reversed, we need to define a 'dominant' face. This dominant face is the origin of the 2d manifold, so all other connected faces should be oriented in the same direction as the dominant face (ie. all looking into the 2d manifold, or all looking out of the 2d manifold), if not, their normal vector is reversed (not the face itself) so the angle between two faces remains consistent. In my code, the dominant face is the face the user hovers over with their cursor.

@thomthom said:

Aye. Loop and EdgeUse objects can be very useful.

Normalize Toolkit Work In Progress 2

@oneguy said:

Ok, lets see,

I can look around with the left mouse button.
I'm using windows 7 ultimate.
It's kinda hard to measure because the speed keeps going up and down very fast but I believe somewhere between 7-8kmph
And finally, here's the key tool from the ruby console:

Key Tool Activated.
onKeyDown: Key code: 38 ( VK_UP )
onKeyUp : Key code: 38 ( VK_UP )
onKeyDown: Key code: 37 ( VK_LEFT )
onKeyUp : Key code: 37 ( VK_LEFT )
onKeyDown: Key code: 40 ( VK_DOWN )
onKeyUp : Key code: 40 ( VK_DOWN )
onKeyDown: Key code: 39 ( VK_RIGHT )
onKeyUp : Key code: 39 ( VK_RIGHT )
Key Tool Deactivated.

Thank you for the quick response and for your work.

Thanks for your response Oneguy. It looks like its not a problem with the keyboard. I've found a bug in the plugin that could be related to what you're experiencing. Changing the model units greatly affects the speed of the camera. I'll fix this in the next release. For now, see if changing the model units solves your problem.

Instructions
Load up your sketchup model and select the menu 'Window' and select 'Model Info'
select 'units' and change the Format: to 'Decimal' and 'Millimeters'.

For now you'll need to change the units for each model that you open thats not in millimeters.

Thanks again Oneguy, and let me know how this goes

-niall

wow, major oversight! I should probably be using edge.reversed_in? to reliably find the edge normal direction relative to the face.

Just to double-check my logic: on outer loops edge.reversed_in? will return true if the start and end vertex of the edge is running clockwise (if your looking against the normal of the face [the negative face normal vector is the vector for determining clockwise or anti-clockwise]). On inner loops (face.loops - face.outer_loop) edge.reversed_in will return true if the start and end vertex of the edge is running counter-clockwise?

I ran into this issue today, reported it to google but thought I'd post it here for reference as there's an easy workaround.

If you're using the view.draw_text method in your ruby plugin or tool there's an issue when you switch the face style to X-Ray or Hidden Line. view.draw_text will only work under X-Ray or Hidden Line if you invoke some other view.draw* method. Here's my testable example

def draw(view)
	##comment out the following line to produce the view.draw_text bug
	status = view.draw2d GL_LINES, [Geom;;Point3d.new(13,10,0),Geom;;Point3d.new(13,10,0)]
	pt = Geom;;Point3d.new 13,10,0
	status = view.draw_text pt, "view.draw_text working!"
end #def

When you've attached this to a tool you can reproduce the error by running the tool with the line status = view.draw2d... commented out.

status = view.draw2d GL_LINES, [Geom::Point3d.new(13,10,0),Geom::Point3d.new(13,10,0)] tries to draw a line between two points that are in the same position (and hopefully fails to draw anything on the screen).

Tested on:
Windows 7 Ultimate
Sketchup Pro 8.0.4811
ATI Radeon HD 5770 (Driver Version: 8.881-110728a-124445C-ATI)

just for context, attached is the wip with a few modifications to the previous post to reduce the load significantly if we're dealing with convex polygons.

normalize toolkit work in progress