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

@bentleykfrog said:

I've been working on this problem quite alot lately

I've finally got my 2d manifold detection working (albeit quite slowly as I have to calculate an infinite line [planar normal of an edge] intersecting a complex polygon [face] for each edge to determine the side of the edge its associated face is on). Anyway I thought I'd post the code here for some feedback and optimization advice. Here's the code snippet: feel free to chop/change/reuse if you like.

		def intersect_line_line_segment_2d(line,segment)
			x1	= line[0].x
			y1	= line[0].y
			x2	= line[1].x
			y2	= line[1].y
			x3	= segment[0].x
			y3	= segment[0].y
			x4	= segment[1].x
			y4	= segment[1].y
			
			u_line_n = ((x4 - x3)*(y1 - y3)) - ((y4 - y3)*(x1 - x3))	#line equation numerator
			denom	 = ((y4 - y3)*(x2 - x1)) - ((x4 - x3)*(y2 - y1))	#line  & segment equation denominator
			
			u_segment_n	= ((x2 - x1)*(y1 - y3)) - ((y2 - y1)*(x1 - x3))	#segmnet equation numerator
			
			if denom == 0
				#line and segment are parallel
				return false
			end #if
			
			u_segment = u_segment_n.quo(denom)
			
			if u_segment >= 0 || u_segment <=1
				#return [x1 + (u_segment*(x2-x1)),y1 + (u_segment*(y2-y1)),1]	#use to return the point of intersection
				u_line = u_line_n.quo(denom)									#use to return a relative distance value for ordering
				return u_line													#intersections on a complex polygon
			else
				#intersection is outside the line segment
				return false
			end
		end #def
		
		def find_manifold_face(origin_face_id,fold_edge_id,possible_face_ids,check_orientation=false,correct_orientation=false)		
			origin_face		= @@face_objects[origin_face_id]
			origin_edges	= @@faces_to_edges[origin_face_id]
			manifold_face	= false
			
			#	PT1; ORIGIN FACE->FOLD EDGE ORIENTATION
			#	we need to find on which side of the edge the face is, and then
			#	determine the direction of rotation. This is more difficult than
			#	it appears. The most error-free way to do it is to create a line
			#	that represents the planar normal for the edge (ie perpendicular
			#	to the fold edge and on the plane of the origin face) and find the
			#	line segments that intersect with the face using an Intersect Segment
			#	with Polygon algorithm. [see; http://softsurfer.com/Archive/algorithm_0111/algorithm_0111.htm]
			#	A COUPLE OF NOTES FIRST;
			# 1;We only need a 2d coordinate system for this so we can use the UVHelper
			#	to generate this and hopefully make the code more efficient
			# 2;We only need to find the first intersected line segment that shares
			#	one of its points with the fold edge
			fold_verts 		= @@edges_to_verts[fold_edge_id]					#construct points on the fold edge that will help with
			fold_arr		= fold_verts.values									#orientation; pt1; start, pt2; middle, pt3; end
			fold_pt1		= fold_arr[0].position
			fold_pt3		= fold_arr[1].position
			fold_pt2		= fold_pt1 + Geom;;Vector3d.new((fold_pt3.x-fold_pt1.x).quo(2),(fold_pt3.y-fold_pt1.y).quo(2),(fold_pt3.z-fold_pt1.z).quo(2))
			fold_vec		= fold_pt1.vector_to fold_pt3
			trans 			= Geom;;Transformation.rotation fold_pt2, origin_face.normal, -90.degrees
			o_vec1 			= fold_vec.transform trans
			
			origin_uvhelp 	= origin_face.get_UVHelper true, false, @@tw		#UVHelper can give us 2d coordinates for a 3d face ;)
			fold_uv_pt1		= origin_uvhelp.get_front_UVQ(fold_pt1)				#construct the corresponding uv points that are uv
			fold_uv_pt2		= origin_uvhelp.get_front_UVQ(fold_pt2)				#representations of the 3d coordinates
			fold_uv_pt3		= origin_uvhelp.get_front_UVQ(fold_pt3)
			fold_uv_vec		= fold_uv_pt1.vector_to fold_uv_pt3
			
			trans_uv_vec	= Geom;;Vector3d.new(fold_uv_vec[1],-fold_uv_vec[0],1)		#construct a fold edge normal line to
			trans_uv_pt		= fold_uv_pt2 + trans_uv_vec								#calculate the line segments of intersection
			trans_uv_line	= [fold_uv_pt2, trans_uv_pt]
			
			intersection_array = Array[0]
			origin_edges.each {|edgeID|
				next if fold_edge_id == edgeID
				edge_uv_pt1	= origin_uvhelp.get_front_UVQ(@@edge_objects[edgeID].start.position)
				edge_uv_pt2 = origin_uvhelp.get_front_UVQ(@@edge_objects[edgeID].end.position)
				edge_uv_segment = [edge_uv_pt1, edge_uv_pt2]
				
				intersection_u = self.intersect_line_line_segment_2d(trans_uv_line,edge_uv_segment)
				next if !intersection_u
				intersection_array << intersection_u
			}
			if intersection_array.length <= 1
				msg = "Critical Error; Normalize Toolkit encountered an illegal face (a face with only two vertices).\nYour model probably has errors?"
				msg += "To check, select the menu item 'Window' -> Model Info, then select 'Statictics' and click on 'Fix Problems'."
				self.alert_error(msg,true)
				Sketchup.send_action CMD_SELECT
				return false			
			end #if
			
			intersection_array.sort!									#ok lets find if the vector is pointing the right way
			reverse = (intersection_array.index(0) % 2) ? 1 ; -1
			o_vec1.reverse! if reverse == -1
			o_pt1 = fold_pt2 + o_vec1
			o_vec2 	= origin_face.normal								#make the origin face's normal an orientation vector
																		#we need two vectors at right angles to get around the
																		#angle_between not greater than 180 degrees problem.
			smallest_angle 	= 360.degrees
			possible_face_ids.each {|faceID|
				next if !@@faces_to_verts.has_key?(faceID)
				next if faceID == origin_face_id
				
				#logically, the p_vec1 should be found by rotating the fold_vec in the opposite direction
				#as o_vec1 was. The only issue here is that if the normal is reversed, we wont get a correctly
				#facing vector. Fortunately, we can determine this by comparing the clockwise angle from o_vec1
				#to p_vec1 and from o_vec1 to @@face_objects[faceID].normal.
				#If o_vec1 to p_vec1 is smaller than o_vec1 to @@face_objects[faceID].normal, we've got a reversed
				#normal!! cool
				trans 			= Geom;;Transformation.rotation fold_pt2, @@face_objects[faceID].normal, reverse * 90.degrees
				p_vec1 			= fold_vec.transform trans
				
				t_ang1a			= o_vec1.angle_between @@face_objects[faceID].normal
				t_ang1b			= o_vec2.angle_between @@face_objects[faceID].normal
				t_ang2a			= o_vec1.angle_between p_vec1
				t_ang2b			= o_vec2.angle_between p_vec1
				
				t_ang1 = (t_ang1b <= 90.degrees) ? t_ang1a ; 180.degrees + (180.degrees - t_ang1a)
				t_ang2 = (t_ang2b <= 90.degrees) ? t_ang2a ; 180.degrees + (180.degrees - t_ang2a)
				
				#another problem here is that the difference between t_ang1 & t_ang2 should be roughly plus or minus 90 degrees
				#if its greater, then the possible face is on such an obtuse angle and reversed that its normal is closer to
				#o_vec1 than p_vec1 is
				p_vec1.reverse! if ((t_ang1 > t_ang2) || ((t_ang2 - t_ang1) > 180.degrees))
				
				o_ang1 = o_vec1.angle_between p_vec1
				o_ang2 = o_vec2.angle_between p_vec1
				
				manifold_angle = (o_ang2 <= 90.degrees) ? o_ang1 ; 180.degrees + (180.degrees - o_ang1)

				if manifold_angle < smallest_angle
					smallest_angle = manifold_angle
					manifold_face = @@face_objects[faceID]
				end
			}
			if !manifold_face
				return false
			end
			
			if check_orientation
				direction = self.get_rotation_direction(fold_vec,fold_pt2,origin_face.normal,o_pt1)				#work out whether the vector is pointing in the right direction
				trans 	= Geom;;Transformation.rotation fold_pt2, fold_vec, (smallest_angle * direction)		#rotate the origin normal so its aligned with
				m_normal 	= o_vec2.transform trans															#the manifold's normal. This should give a vector
				m_ang1		= m_normal.angle_between manifold_face.normal										#that angles 180 degrees from the manifold's normal
				oriented = (m_ang1 > 90.degrees) ? true ; false													#if its less than 90 degrees, reverse the face.
				return Hash[
					"manifold_face" => manifold_face,
					"oriented"	=> oriented
				]
			end #if
			
			return manifold_face
		end #def

@oneguy said:

Hmm, a bit of a problem here,
Firstly, thanks for this plugin, I really need something like this for some reason, the camera is stuck. When i press one of the arrow buttons, the speed goes up but the camera just shake in the same place, any ideas?
Im using SU 8.0.4811 pro

Thanks

Hrmm, i'm not sure about this one, its very weird behaviour. It could be a problem with the key assignments. Can you hold down the left mouse button to look around? If so, the plugin should be working and I'm 99% sure its a problem with the keyboard. To check this can you download this tool: sites.google.com/site/jimfoltz/sketchup/my-sketchup-plugins/key-code-tool

Instructions:
copy jf_KeyTool.tb to the Sketchup Plugins folder
start up Sketchup and select the menu 'Window' then select 'Ruby Console' (The ruby console window should open, leave it open)
now select the menu 'Plugins' then select 'Key Codes'
click inside the sketchup window and press the up arrow, down arrow, left arrow and right arrow, then press the space bar
copy the text from the ruby console inbetween the line 'Key Tool Activated' and 'Key Tool Deactivated' then put this text in a reply message on this forum so I can have a peek.

Also, can you tell me your operating system and version?
ohhh and finally, when you say that the speed goes up, what is the highest it goes to?

Thanks for reporting this Oneguy, hopefully I can find out whats causing the problem for you.

-niall

I've been working on this problem quite alot lately, and I've realised the code I posted is wildly incorrect, as you say ThomThom:
@thomthom said:

it seem to be 50/50 chance that the cross vector points in opposite directions.

so we should probably compare the cross vector against something relatively static, like one of the model axes?

@unknownuser said:

Note that if you work in the horizontal plane, the you can take Z_AXIS as your reference rotation vector (and then Bill'sformula works).

could this work if we reverse the cross vector based on its angle to the Z_AXIS (ie. greater than 90 degrees then reverse cross vector).

In pb 1.4 I've fixed framerate issue with collision or eye height enabled by removing the sane distance test. Jumping off large distances still sends you though the ground though, so a bit more tweaking is required.

Sorry for the quick updates for those that downloaded 1.3.

@bentleykfrog said:

Also, I've noticed that the framerate for sketchup animations is direly slow when compared to the frame rate of the orbit tool. This seems to suggest that faster frame rates are possible and that running an animation is doing something different to the orbit tool that's slowing down the frame rate. I've tested both animation & UI.start_timer; view.show_frame, view.invalidate & view.refresh to little to no effect on the frame rate. Has anyone got any suggestions or know of any undocumented techniques that might help with this?

Ahah!, figured out my mistake. I wrongly thought that having Sketchup.active_model.start_operation() then a Sketchup.active_model.abort_operation would improve performance. I've removed both of these and the frame rate has more than doubled! Lucky this is a beta. Updated the main post with the fixed beta (v1.3).

I've posted a small update that fixes a bug that crashed Floatng Camera when enabling collision detection in Sketchup 7. See the main post for the updated plugin.

A few ideas for the next release:

I'm working on some MotionInJoy/XPadder game controller profiles for the PC, and some ControllerMate game controller profiles for the Mac for the next release. These will allow you to use the PS3 Sixaxis & XBOX 360 controllers with Floating Camera.

Hrmm, there might be a good reason for having different speeds on up and down movement, compared with forward, back, left & right. The idea being that since these movements are controlled by keyboard inputs, there's only an on/off input, its not really analog. This can lead to very jumpy movements as you start to change direction, or you want to change direction gradually.

AFAIK, sketchup only has one analog input available: mouse movement, and this can only be used for two-dimensional movement. I know that they've got the spacenavigator working in sketchup which suggests its possible to have more than one analog input. Is there a workaround for analog input in C++?

Also, I've noticed that the framerate for sketchup animations is direly slow when compared to the frame rate of the orbit tool. This seems to suggest that faster frame rates are possible and that running an animation is doing something different to the orbit tool that's slowing down the frame rate. I've tested both animation & UI.start_timer; view.show_frame, view.invalidate & view.refresh to little to no effect on the frame rate. Has anyone got any suggestions or know of any undocumented techniques that might help with this?

The physics controlling camera height when eye height is enabled needs some tweaking too. The problem is that when you 'jump' off a very high surface in Sketchup we've got to stop the camera from going through the ground, so the up & down acceleration when eye height is enabled is alot more rigid as you've probably noticed! We've also got to stop harmonics so the camera will eventually level out at the desired eye height rather than bouncing up and down all the time.

Hopefully all these problems will be ironed out soon.

thanks

-niall

@pixero said:

First impression is great.
So far the only suggestion I have is some control over pan speed/sensitivity.
Great work!

hrmm, do you mean something like rotational friction? I'm probably brutalising the use of certain words here. You can change the pan speed by changing the degrees value in the settings dialog. Hrmm maybe a scale like the Inertia (Friction) scale would be useful here?

This plugin allows you to navigate through your Sketchup model as you would normally do in a 3d video game environment.

I thought I might release a public beta of Floating Camera just to test the waters before an end-of-year official release. Feel free to try this plugin out, all instructions are included in the User's Guide pdf. If there are any issues or if you've got any suggestions, post it to this forum. I'll keep an eye on it. Enjoy!!

Ohh, just a quick note, if you experience significant frame rate issues, try setting the face style to wireframe. The intersect and camera eye height features will still work, and hopefully you'll notice an improvement in performance.

-niall

Known Issues

• Unit conversion is working incorrectly. This will be fixed in the next release. As a workaround for 1.4, switch your model units to millimeters:
  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'.

EDIT: Beta 1.4x made compatible with SUp >= v2014 [TIG 20150606]

Beta 1.4 Update
Fixed framerate issue with collision or eye height enabled by removing the sane distance test. Sorry for the quick updates.

Beta 1.3 Update
Removed some very bad scripting that has more than doubled the framerate. Significantly bad framerate was caused by the presence of .start_operation() & .abort_operation.

Beta 1.2 Update
There's an issue in Sketchup 7 when enabling collision detection that causes Floating Camera to crash. This issue isn't present in Sketchup 8 or later. This update fixes this issue.

GET THE LATEST VERSION FROM THE 'PLUGINSTORE' http://sketchucation.com/pluginstore?pln=FloatingCamera

Floating Camera 1.0 public beta 1.4
This is suitable for <=v2013 only - this IS NOT >=v2014 compatible - get the RBZ of v1.4x_beta from the PluginStore for newer SUp versions...

@unknownuser said:

TIG recently developed a very similar ruby

http://forums.sketchucation.com/viewtopic.php?p=346754#p346754

-Brodie

Thanks brodie, I initally wrote v1.0 in 30 minutes that simply flattened vertices to z=0, posted it to the forum, then noticed TIG's drop vertices. With v1.1 I thought I'd take the development in a different direction with Flatten to mean normal, which works similar to TIG's scripts but my focus is on replacing the Z vector with the average normal of all the faces selected. I don't want to butt heads with TIG as he's quite a deal more talented than I.

In the next version I'm working on ways to preserve the edge conditions, so the script doesn't destroy four or more sided faces. The method I'm thinking of using considers edge conditions as 2 dimensional manifolds (so rotate along the border edge away from the border face's normal until you find a face that isn't in the selection). The normal determines the direction of rotation to avoid the angle_between not greater than 180 degrees issue. We rotate away from the normal to find the next face because there may be more than two faces sharing a border edge. This (hopefully) will remove interference by more than two faces sharing the same edge. This method also shows some promise for applications like correctly orienting faces and removing internal geometry on non-solid geometry, but more grey matter is required on my part. Hopefully all's not lost

Flatten Vertices will move all vertices in the selection so they all have a z position of 0. Just select your edges you want to flatten and go Plugins->Flatten Vertices->To Z=0.

In this update I've included a method to flatten vertices based on the average normal of all the selected faces. Select your faces you want to flatten and go Plugins->Flatten Vertices->To Mean Normal.

Known Issues:
Currently the script doesn't preserve the edge conditions (ie, if outside the edge of your selection there's a non-triangular surface the surface will most likely be removed when you run this script. Try triangulating surfaces with TIG's triangulateFaces.rb first then run Flatten Vertices).

Flatten Vertices v1.1
Just copy to the plugins folder