@dan rathbun said:

Notice this console error:

pointonline = [10,10,10].project_to_line [0,0,0] %(#008000)[Error: #<ArgumentError: (eval):0:inproject_to_line': Cannot convert argument to Sketchup::Point3d>]`

What that tells you is that internally, the project_to_line() method, calls the constructor methods for you on Array arguments.
Like:
pt1 = Geom::Point3d.new(args[0]) if args[0].is_a?(Array) pt2 = Geom::Vector3d.new(args[1]) if args[1].is_a?(Array)
.. etc ...

• And the error message itself has a typo. The class is within the Geom module, not the Sketchup module. (This bug has been reported.)

What that tells me mostly, with all due respect, is that you cannot define a line with a single point as witness that from the ruby console:

[20,10,30].project_to_line [0,1,1], [5,1,1]
[25.5555555555556, 6.11111111111111, 6.11111111111111]
Doesn't generate an error (yes it takes the second array as a vector)

So I don't know whether it calls a constructor method or any such fine and advanced details, all I know is that I can define a line such as [0,1,1], [5,1,1] as in entities.add_line [0,1,1], [5,1,1] and it works, and takes the second array as being a point. Please note too that the line definition can interpret the second array as a point or a vector too, and it defaults to point apparently (but I have a method in array (vector_to) that allows me to easily specify such array as being a vector, not so for a point.
Yet when I use that line definition, which is accepted and stated as a line definition, into the line argument for the project_to_line method, it just doesn't take it as such.

I may still be wrong, but it still seems to me that it's not as originally intended, and stated. And that a statement of raised exception may help.

• And the typo is that it should be "cannot convert argument to line" I think, whatever a line is (it's not in the class list, but yet is used as valid object, and there is a geometric one (drawn), and a mathematical one.) I quote from the Geom module:

@unknownuser said:

The methods in this module take lines and planes as arguments. There is no special class for representing lines or planes. Arrays are used for both.
A line can be represented as either an Array of a point and a vector, or as an Array of two points.
NOTE: Lines and Planes are infinite.

and from the add_line method:

@unknownuser said:

The add_line method is used to add an edge to the collection of entities. This is not to be confused with the concept of a "line" from a geometric sense, which is an invisible object represented by an Array of a point and a vector. (See the Array class for more information on geometric lines in SketchUp.)

The
point3d.project_to_line line
method can take a line as an argument.
A line can be defined by a combination of two arrays , which are a point3d and a vector3d, or a point 3d and another point 3d.

if you do:
a = [[x[1], y[1], z[1]], [x[2], y[2], z[2]], [x[3], y[3], z[3]]]
pt1 = a[1]
pt2 = a[2]
pt3 = a[3]
entities.add_cline pt2, pt3
is perfectly understood as 2 points in this case of creating a construction line.
But pt4 = pt1.project_to_line [pt2,pt3]
takes pt3 to be a vector (even thought the API gives a choice)
If you define a line = [pt2,pt3]
and then pt4 = pt1.project_to_line line, same broken result
if you define:
pt3 = Geom::Point3d.new before pt3 = a[3]; same broken result

The only solution for the project_to_line method to recognize pt3 as a point is to do this:
pt3 = Geom::Point3d.new (a[3][0], a[3][1], a[3][2])
pt2 is always recognized as a point no matter which method is used (same declaration, declaring a new point before giving values, or just passing the array)

I don't know if this has been noted before or where, or if I missed something, but this is the result I observed.

@mitcorb said:

Perhaps that group developing Euclideon are thinking about finite elements and fluid dynamics?

I looked at that, very interesting. I doubt it though because of two reasons:
First they are focusing on detail and complexity displaying, not mechanical design issue.
Second because "voxelization" of a 3D world by comparison to polygonization is a much different conceptual direction. It increases the ability for level of detail/zoom level, but at the expense of reducing logical cohesion of the data. To be more clear:
A face is really a huge collection of points related to each other. Great when you want to see it small, or see all the individual particles of sand that constitute it, but not so good when what you want to know is just one face, with a normal vector (for which you can apply ONE coefficient of granularity if you really want to be picky for mathematical calculations).
I may be incorrect, but I believe that polygons modeling (or even a higher degree of surface integration and conceptualization if there were one) is better for already heavy non linear calculations such as FEA and CFD.

Furthermore, my discourse was not about create those software, they already exists, but to find a way to make them simple and accessible to more and more people ala SU philosophy for CAD. I wish I could and I've looked into it, but at this point it's beyond my resources and competence alone.

But I could be wrong. Thanks for the suggestion though, it was interesting and new to me.

Yes indeed as it is SU is kind of evolving away from simplicity as one adds on plugins after plugins.

Part of it is the implemented plugin management that is limited and has reached it. I think the creators thought of plugins as a great thing, they may not have envisioned how far it would blossom and expand.

Even me as a user if I had "kits" of plugin and toolbars, it would already be much simpler. I could use my archi kit when I work on buildings and house, my woodworking kit for that, my sketchy physics kit, any combination thereof and so on.
At one point I tried to work on "super toolbars", a similar idea, which would have greatly simplified the interface when one has many plugins, but the API is not powerful enough it seems to allow to do that in a ruby plugin (no control over interaction outside of the design window), or I'm not skilled enough in programming to manage it. All it means though is that it is possible for someone with higher access (creators) (I know Jim did it on PC, but still not workable on Macs and he still had issues, you have to create text files, it's not drag and drop for example)
There are plugins that are generic (useful almost always) and some more specific. Some that are either better implementation of existing tools (so they should replace (yet only if one wants to), not be extra) and some that could be regrouped as various options of one tool.

From a programming standpoint (and product design), making thing simple is a philosophy. It is not easy at all. It's not easy in design (figuring out what is more intuitive, what is the ranking of actions, all without hindering realm of possibilities, providing simple, good feedback) and certainly not easy in programming. A substantial effort is necessary. That is what made the original difference with SU.
Someone asked "where is the wisdom in making a tool complicated?" It's not that, it is that the tool is very complex, so the minimum interface is complicated. It requires tremendous effort in design and implementation to go the extra mile to make it simple. It's like musicians, the good one can play great, the great one can go beyond playing, they can fake mistakes to make them funny, they can fake mistakes to create something special, but to master mistakes requires a higher level of mastery than to not make any.
This is the same (and I know I'm guilty of it myself) you can write a plugin that does what you want, but then to make it do the same thing with less complexity, with more intuitive input, with more streamlined actions is more complicated in most cases than to just do it in the first place.
And that is what people that call SU a toy don't get. It looks like a toy, yet it's more advanced than stuff that looks like you need to be a rocket scientist to use. And to make it look like a toy was not only progress but a tremendous effort on top of it.
I'll take an example:
As an engineer, to design a box, I can think well I need to determine x, y, and z for the first corner (input 3 numbers), then three side lengths (another 3 numbers input, then vectors for the directions of the sides, etc.. Nice, I can a get a great CAD that can do plenty.
Or I can say wherever the mouse starts is the first point, and wherever it ends gives me all information I need (oh and maybe my feedback window can accept input to fix these lengths), then just push pull and there it is. Now if I need to fine tune (notice that the basic is done first, and then the advanced refinement later, vs all options given at first) then I can rotate, move, scale, etc..
Now guess what, when I create a sphere in the first instance I have to enter a ton of parameters again, figure out where the center will be and all). Some may start to recognize great and powerful CAD software at this point. /sarc off, no name given.
In the second instance I'd use the same tools (scale, move, etc..)
See how complex it is to be simple.
There are few products in the world that have been lucky to be made like that by design, SU is one of them.

As for creating plugin for the VW crowd, I think it's a matter of use. It is hard to create a plugin for something one either doesn't need or doesn't understand (see the simplicity issue above). Some can create plugin on demand, and it happens. But I think each group of user has to organically refine its own set of tools.
Granted ruby is not as "simple" to use as one may wish. I wish there was a simplicity rule applied to programming languages too, it has been tried many times too (and there are scripting languages too), but it is just a very very complex task. Ruby is very much going in the right direction, and is already quite an achievement, that is why I'd wish that in SU it didn't become replaced by C (C++, Java, etc..) or other more "technical" languages, even if arguably they are more powerful (or more widely used by programmers). Now they still could be a secondary option for the most advanced programmers, to do the most powerful features. Again a design issue.

I come from a mechanical engineering background, and today I use SU for many things, mostly as hobby purpose.

To me it's first key feature is that it's fun and easy to use to put ideas on the screen (3D or 2D). I use it all the time to design parts, to create graphics illustration of countless topics that have nothing to do with either design or CAD or the like. I even use it for pure fun sometimes, just like doodling on a piece of paper.
I have been a user of CAD, even a maker of, for years, this is no CAD software, it's a design gem. It's simple, intuitive, progressive (you can start with few tools, then get more, then plugins, then even program your own if they don't exist), that is priceless. I went back to programming after more years than I'd like to share here and learned ruby, just for the fun of programming plugins, some I haven't even really used, just enjoyed creating the plugins (a lot still in the works )just because I could and I had the idea.

It's second key feature (or maybe even the first) is that it is sufficiently simple, free on the ground access and widely distributed that anyone can get it. that creates a community of creators, from things (3D warehouse) to enhancements (plugins, other software) to use (sketchyphysics anyone?).
There is not a month that I'm not astonished as to what someone came up with using SU, both in technical terms (plugins) or design, or ideas. That is only possible with SU and how it was distributed. I don't see that in solidworks. Sure solidworks can do great things, if you're rich and a specialized engineer, but that's beside the point.
I wrote about it before, but I know there are kids out there that played with SU, and the mere fact that they could put the fruit of their imagination on the screen, is the stuff of greatness. It empowers them, it makes them want to create, to think, to discover. That too is priceless, it's a tool that creates the future.

All that is not happening with Atuodacd, is it?

So that is, part only, of what SU means to me. I have been pushing a lot of people around me, whether they are blacksmiths, machinists, physics teachers, kids, corporate businessmen and so on to open their mind to the empowerment that SU would give them, the ability to sharpen and solidify ideas, the ability to visualize and illustrate almost anything (static, 2D, 3D, animations, etc..)

To me SU is not CAD, it's a paradigm shift, like the transistor, the computer, the Macintosh (I couldn't resist), the Iphone, etc.. There is a before SU and an after SU. There was a time where design software was for professional experts, and now there is a time where anyone that can think, can create and show it. It's the first step, let it not be the last.

Could the paradigm (make it simple versus for technical specialists) be extended to FEA (Finite element analysis, ability to create structures and calculate their strength) and CFD (Computational Fluid Dynamics, the ability to design shapes based on fluid interaction (air, wind, temperature, etc..)? Now that would be step 2 and 3, and what the general community would come up with in return would be even more astounding.
Sketchy physics went in that direction, an awesome thing and thus look how it was received. The dream lives on!

So after learning of the Trimble deal in Catchup and being stunned. I read though this whole thread.

Some say it's useless. Well this is a forum so discussing is never useless, it's the purpose in fact. If nothing else it shows what people think, feel, wish, etc..
Now is it useless to the deal and the future, who knows? In any case it is pure speculation.
Having done many similar deals in the software arena, and with M&A, I personally am nonetheless very worried, (hence part of the "stunning") and yet that is more speculation anyway. We just don't know the future, period, and it could be anything.

So why stunned, since after all it is just a piece of software and it goes from a private company to another, and according to the posts here (as I just learned) Google was not super supportive to start with. Well I can put it this way. Outside of the specialized building community, which will find a solution to its needs regardless, and speaking for he hobbyists and masses, Google for all its flaws helped expand on the vision of making design easy and simple, yet modular, flexible and powerful accessible to a wide number of people. It helped create a repository of existing models and it helped (directly or not) to create a pool of talents to further the product (short arguably of doing it themselves). For that they can be commended. Google also has a track, even though they are private and for profit, to give people in general access to technology. Their business model being a derivation of that principle in most cases.So while they could have done better it seems, I believe that they contributed significantly. And that is done and acquired.
So that is what was good about Google and how it further helped the great original software that SU was.

Now we're here at a new fork in the road. Who knows what will happen. Trimble doesn't seem to have the mass benefit business model at its core, it doesn't seem particularly concerned with the visionary issues of simplicity and flexibility. Actually they rather are in a very narrow specific sector of the world of design . This said, could they further the global cause? Of course they could, it's possible but it would also represent some change and departure from where they seem to be. Will it? We hope. Are they saying they will, yes they are, so good.
This notwithstanding it may be too that the design focus narrows (more towards buildings, etc..) as the result of corporate and business decisions, and while that may still be good for our pro building designer friends here as they expressed it, it may change the focus nonetheless. thus the hobbyists, the woodworkers, the ironworkers, and all the other vast numbers of SU users may not benefit as much. It may also be that they retain or realize and even capitalize on the much broader audience that they now acquired. Time and actions will tell, and it seems the pressure from the team will certainly be there. Great!

In the mean time I think it is incumbent upon us, the community of user, to make sure they perfectly understand who we are, if they haven't already.
that was wisely started already with the poll of usage type.
As such I will start a thread where we can show what SU means to us. Hopefully it will also help them get a real picture. It will also be an homage to the SU team and give them standing points should they ever need it in the future.

It is kind of similar to new feature list in a sense but not quite. As for wish list I would say, keep it with a friendly interface at all cost, no specific, complicated, dedicated, esoteric solutions (autocad?). SU thrives on its simple and intuitive interface, it should be a priority for SU as well as us plugin developper. I know it's hard, for once the piece of code work, it's only half done, but I believe it is important. Also keep it widespread (multi platform not only compatible but identical, there are already gaps forming) and flexible (Ruby API is awesome, C, C++ or other is okay as long as it's an option, not a replacement (again simplicity, not regression, yes C might be more powerful, but for some of us, it's would just stop the creativity, as an extra option, great!)).

So I just learned the "news" and am stunned. Why? What the heck is wrong with me, this is just a software, that I don't even use that often. Anyway, more on that later. For now and this forum:

The part I quoted below is worth emphasizing. It is even beyond that however, because SU is beyond that. Forums are forums, but in the perspective of SU (pun intended) this forum is at least half if not more of SU intrinsic value. Think of where and what SU would be without it. without the community, without the plugins, without the collective creativity (sketchyphysics, specific plugins, the huge amount of various usage it represents etc..). the value of this collective thinking, creativity and ability to contribute and participate (through plugin development amongst others) is huge.
I don't know whose "fault" it is that this forum came about, whether it's the fundamental spirit of SU, whether it's Google serendipity, a combination thereof, whatever positive and negative forces that took it to where it is now. But the fact is NOW, that we are here, this forum and what it does and did is IMO more than half the value of SU, both on a practical level (as a tool with its possibilities) and a spiritual level (its community and how SU reached and empowered people). In 20 years, you'll have designers, engineers, who will say they did what they did, they are good at what they do, because SU and SCF existed and they came across it. It is a vector for inspiration, for imagination, for expression. That is both rare and difficult to achieve.
In a world where we desperately need more creativity, ideas development and making things rather than just services, how important is that?

@earthmover said:

Indeed. This forum is far more than just a "forum". It is a hub. It's a repository of supercharged techniques, upgrades and modifications to take sketchup from a basic, border line mediocre tool and turn it into a tailor made heavyweight contender. So much so that Sketchup users can be divided into two groups, those who SCF and those who don't. This forum is home to free thinkers, artists and altruists. A place where national borders melt away and common ground is found in the shared desired to be creative. I hope this place stays exactly as it is. Independent and largely uncensored.

Whatever the future is, whomever "owns" SU, make no mistake, even though you just legally purchased a piece of software (and its team and so on) it is not just a piece of software you have, not just a tool. Of course one is free to decide whatever one wants to do with what one owns, but make sure you realize what you'd lose if you did, it may not be worth it.
You may not own this community and its efforts, but herein lies the problem. It still came with it and it was part of the value you got. You probably paid for it too, even though you don't own it. Now it's yours whether you want it or not. It's yours to help, it's yours to enjoy, it's yours to fear, it's yours to ignore, it's yours to benefit from, it's even yours to squander. A tall order you got.
Anyone can buy an exceptional car and smash it to pieces, not everyone can buy it and make it even more exceptional.

Merci quand meme! Ca fait plaisir de discuter de toutes facons.

OK, It's still on! Pilou thought I was looking for plugins, not for coding methods.

@unknownuser said:

Pour récupérer les points il faut autre chose!

D'abord savoir leurs formats ? text, dxf, excel etc...
Par exemple celui-ci d'un nuage de points by Didier Bur

Oui je sais, mon probleme n'est pas de recuperer les points, ni d'en faire un profil dessine, ca je sais faire. Disons que j'ai des arrays ou des hash ou sets avec la liste de points du profil 1, et une autre avec la liste de points du profil 2.
Je peux dessiner mon profil 1 (curve, liste de points), de meme avec profil 2, et je peux dessiner des edges entre les points du profil 1 et 2 et creer les surfaces correspondantes. Jusque la je sais faire.
Mais la question est si il n'y a pas une methode pour envoyer tous les points en nuage, ensuite creer le mesh en polygon mesh (sans se taper chaque edge) et puis une fois tout fais en mesh (toutes les sections successives misent a la suite) creer la surface finale. Je peux faire comme prevu (chaque profil puis les triangles entre, puis les surfaces, puis la section d'apres, etc..) mais au vu des commentaires sur l'optimization je me demandais si il n'y avait pas une methode optimisee. Et ma methode ne se servirai pas des "polygonmesh", je fais un nuage de points et d'edges ensuite je rempli les surfaces.

Wow! J'ai regarde Curviloft, trop avance pour moi pour le moment, ca demenage, pas surprenant tu me dira.

I still need a script because I have curviloft, yet I don't need to draw from exiting shape, I need to draw the shapes first from data file.
And I looked at the curviloft script, way too powerful for me to even understand, yet pick some pieces, at this stage of my knowledge.

Oui un plugin, je sais je l'ai. Mais je ne veux pas un plugin car je n'ai pas les profils dessines, j'ai juste une liste de coordonnees en fichier texte et il faut que je les dessine.
Donc il me faut bien la routine qui fait un peu comme curviloft. Remarques il suffit que je regarde dans le plugin de Fredo. Mais j'essayais de faire mon truc quand meme et de comprendre les polygonmesh au passage.

Je vais regarder en attendant (et puis j'ai des autres problemes a resoudre aussi donc ca va j'ai du travail (ouvrir une liste de fichiers, et ne pas executer des trucs sur un cancel, que je ne comprends pas comment le programme les execute (il est branche ailleurs sur le cancel). On s'eclate!

Merci en attendant!

@unknownuser said:

@unknownuser said:

Creating a closed surface (tubular but not of circular shape)

You have not a little image of what you want?
It's very had to follow a technical text!

Non, c'est pour faire une aile a partir de profils successifs. Chaque profil est constitue de plusieurs points/segments en boucle. Et je veux creer le "tube" entre deux profils successifs. Ca t'eclaires ou pas?
je n'ai pas de dessin car justement c'est pour les faire

Mais bon si c'est trop complique je ferai un dessin quand meme.

Sorry for the French I thought it would be clearer for Pilou.
No drawing as it's to create one. There are parallel sections, each made of same number of points (and edges or not). I want to link two parallel sections by creating the outer "tube" like shape.

OK here is my challenge:

• Creating a closed surface (tubular but not of circular shape) by combining instances of cutouts if you will.
• I generate a list of point for each cutout, that I can link with edges, and/or make a curve object. And so I generate section after section. (that's what the data gives me, so short of generating everything and reordering, that is the generation process)

So my first thought was to generate one cutout, generate the next (they both have the same number of segments) and then link them point by point (pt1,1 to pt 2,1) and across one (pt1,1 to pt 2.2) to generate a triangular mesh, apply surfaces to it, and then move on to the next section.

I read in optimization that it's better to use polygon_mesh methods, like fill from mesh, etc..

So now I foresee two options:

• Stick with original way (create points, then edges section by section) but without creating faces, then create all the faces at the end.
• Create the cloud of points only, and from there create the mesh, and then fill it up. I don't know how to do that yet, but I am looking to figure it out. My first question with this would be how do I qualify the points in the cloud so that not every point connect to any other?

So what do the masters think? I don't need details, just brief comments, I can dig from there. Thanks

Or put another way, what is the algorithm, if any, of creating a mesh upon adding points to a polygonmesh object?

@tig said:

Are all of your methods wrapped inside a module and/or class ?
I'd be surprised that Fredo has a raw 'deactivate' method I suspect you do !
It might be an observer trapping your error into his own error reporting, assuming it's his tool's error...
The standard Tool deactivate method is
def deactivate(**view**)
...Try adding that inside a Tool class...
???
https://developers.google.com/sketchup/docs/ourdoc/tool#deactivate

YES! That did it!

Yes it was all within a class. Just adding "(view)" solved the problem. I didn't change anything else. The deactivate method was within the class and still is.

Yes indeed I strongly suspected that Fredo had nothing to do with this.

Thanks TIG and Dan.

So I'm writing a script, nothing too fancy.
It's not fully working yet, but functionally it is (some methods are puts instead)
The mystery is that every time the script ends, at the time I select the selection tool I get this message in the console:

@unknownuser said:

Error: #<ArgumentError: wrong number of arguments (1 for 0)>
/Library/Application Support/Google SketchUp 8/SketchUp/Plugins/LIBFREDO6_Dir_43/Lib6Traductor.rb:155:in `deactivate'

Needless to say I have the traductor and the LIBFREDO_Dir, bu I am in no way calling them within the script, nor sending ay instruction that should create this.

Also my script end is a standard deactivate method as follows:

@unknownuser said:

def deactivate
Sketchup::set_status_text("",SB_PROMPT)
Sketchup::set_status_text("",SB_VCB_LABEL)
Sketchup::set_status_text("",SB_VCB_VALUE)
end

I'm on a MAC

Anybody can help? Fredo?

@guanjin said:

Right-click to select the color, no response

It only works when you are in the color change mode (see status line at bottom, and change mode with command key).

Works all the time now (in version 1.3)

@jorge2011 said:

EXCELLENT PLUGIN.
a query.?
is possible convert smooth lines to construction lines?
is possible the option of adding construction points at the ends of the lines?
You can auto-detect lines with the mouse when I pass over a line?
thank you very much

Smooth line, well I assume that if you view hidden, you can pick them and convert, I'll try.
Cpoints, done already, use alt
auto detect, well that would be nice, I don't know how to do yet
I presume what you mean is highlighting the line as you go over, before clicking to pick it.

I'll look into it, but I'm working on 1.3 for much better integration too.

As for no color, I don't know I will look, but mine works, so not sure why.

Based on the original Xline tool from Rick Wilson

Copyright 2012 (c) EDGE LLC
All Rights Reserved.
THIS SOFTWARE IS PROVIDED "AS IS" AND WITHOUT ANY EXPRESS OR IMPLIED
WARRANTIES,INCLUDING,WITHOUT LIMITATION,THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

Unzip and then place Xlinem script and Xlinem folder into the plugin folder.

This tool is either contextual menu or toolbar activated.
It will work on preselected entities, as well as allow you to pick them after activation.
It will transform selected edges into construction lines (stipple can be chosen), and selected construction lines into edges (unless they are infinite) of a particular color (or black).
By using ALT (Mac) you can opt to also have construction points at the end of these lines.
To delete construction points, use the standard delete methods
By using Command (Mac) you can toggle the tool modes:
Default mode is change edges into construction lines, and vice versa
The second mode changes the construction line's stipple and the edges' color (it doesn't change their nature).
The stipple change also works on infinite construction lines.
In the color change mode it will allow you to change the color of any edge.
The color and stipple pattern is chosen by right clicking in empty space.
It will originally ask you if you want to display the edge with color by material (an option, without which you WILL NOT SEE the edge color change, yet it's there. If you choose entity info, you'll see that the color is properly applied, but to display it, you have to change that style option). Once you pick yes, that option is saved with the model. If you pick no it can always be changed later in the style menu box.
The color and stipple you choose remain throughout your entire session. They don't change if you change tool and come back, but it will revert back to black and standard stipple once you quit SU.

This script is tested on Mac, but it should work on PC. Let me know otherwise.

Version 1.0 - 3/30/2012
Version 1.1 - 3/30/2012 Added color changing
Version 1.3 - 3/31/2012 Simpler, more logical and much better integration

Xlinem 1.3.zip

I'll modify accordingly once you modify the camera stuff.

I'm thinking along these lines:
Arrows: pan left/right/backward/forward
Option/Command pans down/up
Control plus arrows orbits left right, up down
<,> changes field of view in and out (but needs a standard reset)
Right double click toggles high speed motion/slow speed

Also I would not come back to a standard view every time, I'd start with the current camera view, which means the mouse orbit,zoom and pan still work.

PMed the current code

Of course keys are not working on mac.

I already have the keys implemented (arrows keys only) and changed the up down movement to > and < and option/command.
I also used right double click for speed X10 (which I may reduce)

I am planning to use modifier plus arrows for rotating camera up down left right, but rotating around, not rotating the field of view. Working on it.