Without seeing, it is hard to say, but maybe your surfaces have an opaque back colour.

Each face in Sketchup can have two colours/materials - one for the front face, and one for the back face.
When you paint individual faces using the brush tool, by default it will only paint the front face, leaving the reverse face with the default material. If you paint a transparent colour only on one side, it will behave like a "one way mirror", leaving you able to see the inner surfaces through the outer ones.

If this is the case, there are two solutions with the stock tools...

1. Select all faces of the object - context menu -> reverse faces. This switches the front and back faces, so you can now paint the other side. (Remember to reverse them back again if you intend to render - many renderers only recognise 'front' faces, and the 'fronts' must be the outer surface.
2. Don't paint your object face by face. Instead, leave it unpainted, then make the whole object into a group or component, then paint the whole part with one click - this will paint all of the surfaces, 'back' and 'front', with the same material.

Thanks everyone for your replies - and especially to ThomThom for going the extra mile to highlight the different vertex behaviour of the methods.
Having thought a little about your suggestions, things are much clearer - adding a face directly will be more efficient because SU doesn't have to parse through all the edges looking for co-planar ones to make a face. Seems obvious now that I've been pointed in the right direction - I was thinking too much in terms of how I would draw using the mouse.

Hi All,
Just playing for the first time with creating geometry using Ruby, and I'm a little confused by what seems to be an anomaly in the way that the find_faces method works.

First I created some 'test points' to connect with edges and use to make a face...

points = [[-1,-1,0],[1,-1,0],[1,1,0],[-1,1,0]]
points << points.first  # Close the loop
points.map!{|pt| Geom;;Point3d.new(pt)}

(explicit conversion to Point3d doesn't seem necessary most of the time, but I was being strict!)

I can then use these to create all the edges in one hit using...

temp_group.entities.add_edges(points)

Where 'temp_group' is an empty group used to stop the new entities from sticking to other geometry.

When I view the group contents, I can clearly see that the new group now contains my four edges (and nothing else); so I then try to close the face...

temp_group.entities[0].find_faces

But no face will form - even if I iterate over every edge entity. Manually overdrawing any of the four lines creates a face as expected.

However, if I create the edges 'longhand' using a loop to add one edge at a time...

(1...points.size).each do |index|
temp_group.entities.add_line(points[index-1],points[index])
end

...find_faces has no trouble making the face, even though the group contents are essentially the same.

I realise that, for this trivial example, I could just use add_face to make the face and lines in one hit - but I am keen to understand what's going on here, as 'add-face' might not be appropriate in every circumstance, and I would imagine 'add_lines' to be more efficient than creating edges with an explicit loop. I get the feeling that maybe I'm missing something to do with group/component editing context - but I can't see how that would affect one method of adding the edges, but not the other.

Thanks in advance for any explanations/tips - this has me thoroughly baffled!

(PS - is there some good reason that the forum search engine removes underscores from search terms (even when "quoted")? - it makes searching for 'underscored' Ruby methods a bit tricky!)

Not sure precisely what settings would work better for your machine - but one thing that is very important is that the driver allows Sketchup to tune the settings.
You should find that within the NVidia 'performance and quality' menu, there will be an 'OpenGL' settings section; and within that section an option something like "Allow my application to control these features"
It's important that this option is selected, otherwise any changes that you make inside the SU OpenGL menus may not take effect.

Once that is done, I usually rely on trial and error, testing each SU option in turn - there are so many different cards and drivers that it's very hard to advise which options will work best for you.

A mobius building - ingenious!
But we might need to invent some new architectural terms when the technology catches up with the concept - is that surface a floor or a roof? Maybe a "Floof"?

Hi Bob,
Take care to check the specifications well - especially the capabilities of the driver software to assign the pen controls as you would like them, and in particular, how it will emulate the middle mouse button and scroll wheel controls. If it cannot do those things well, it may frustrate your workflow, as you can end up having to switch tools to navigate and zoom.
I tried SU with my (very old now) Wacom tablet, but gave up very quickly because navigation just wasn't ergonomic enough. More modern tablets may well be better in this respect, but I wouldn't have too high expectations of a model in that price range.

@unknownuser said:

Unity in mm enable
On PC we have just ~1439.90mm even maxi precision decimal asked!

Seems to be more complex than that...

Precision of arcs entity info does not seem to change when edited in "model info" - lines etc. are OK, precision changes immediately, but for arcs you need to close and re-open the file. So maybe 0.00 precision is what is loaded into your default template - and gets 'stuck' until the file is saved.
This seems a very consistent and repeatable bug - I can easily make the opposite effect of arcs showing more precision than other entities by changing/saving/loading.

@alan fraser said:

If you draw a default arc then chop a little off each end segment, it's still obviously a 12 segment arc...but with two of those segments shorter than the others. Now use Entity Info to change the resolution to...say...24 segments, then back again to 12.
You find that what you have now is a redrawn 12 segment arc with all its segments now all the same length

...but neither end point actually at the stated radius, only the middle ones.

You can play with this to get some interesting insights into the way that SU deals with curves. Afraid I'm not on my work machine, so no pics - but here's a little run-down of an experiment you might like to try.

• Draw an arc with a nice grand curve - a half circle, say, with 12 segments.
• Bisect one of the segments near the middle - chop it right in half at the point where the 'radius' is smallest.
• Select one half of the chopped arc, and choose a small number of segments
• And a large number for the other half.
• Erase the stumps of the line that you used to chop the arc.
• You now have a single arc with very uneven segments.
• Look closely at the bit where the two sections join - eeek.
• See how far you can shrink it with the offset tool before it gets, err, odd.

Similarly, you can show that if you change the segment count to even up the segment length after chopping a curve mid-segment, you'll still have 'off-radius' end points - and if you explode the arc and measure, you'll find that the end segment is not quite the same length as all the others

Just a rather contrived illustration that the lines are being offset, not the arc's 'parameters', of course - I offer it more as a curiosity than a judgement of SU.

I do think, though, that Jeff made a good point about this being a problem of expectations. We may know that it is the lines that get offset, but once you decide to call something an 'arc' or a 'circle', it is not surprising that users expect them to exhibit the behaviour associated with those categories of objects.

The "line offset" tool is a very good, and accurate, "line offset" tool - what is really being requested is a different tool, not a more accurate one.

I use Sketchup at work almost exclusively for creating designs for our laser cutter.

Balsa should be no problem - you'll get the charring that other folks talked about, but I've never seen balsa, ply or MDF ever go up in flames!

You must, be careful with certain composites (pliy, MDF etc.), though. You need to look for a local supplier that supplies these materials certified as suitable for laser cutting.
That's because of the glues and resins used to hold the composites together - some will release rather toxic fumes when you cut them.
Most suppliers of laser machines will also supply suitable materials, as using the right materials makes their machines more tempting. They will be able to, say, choose a suitable wood for nice embossed "nranded" effect engraving.

On our 60W machine, I can successfully cut acrylic to about 12mm thick, and maybe a little less for MDF - knock off maybe a millimetre or two for a 40W machine But the power isn't always the limiting factor here - the beam has to be focused by lenses in the cutting head, so the kerf is actually a very narrow cone. So if you need tight fitting joints, you can run into problems with the cut edges not being quite square on thicker materials.

And if you're getting a machine of your own, don't forget to allow for some good fume extraction. Any wood product is going to make a hell of a lot of smoke when it is cut!!

Without knowing what you want to model (or the the other folks who posted), it's hard to know how useful such a list will be - it depends so much on the style of modelling and final application. Also, "most used" is not always the same as "most useful" - a plugin that only gets used once a year can be "essential" if it saves several hours of manual modelling on a particularly urgent job.
Pretty much all those listed so far are installed here, but here's a handful of my essentials not yet mentioned (used for designing mechanical parts for manufacture)

Export face to SVG - saves me loads of dwg/dxf 'cleanup' time when exporting CAD for our laser cutting machine.
Pen Tools+ - very handy for directly drawing construction lines and points.
Hatch Faces - great for making hatched cross section drawings.
Joint Push Pull - instant "thickness" for curved parts.
Curvizard - for gluing lines into 'one-click-select' curves.

Fascinating - I thought I might watch a couple of minutes, "for a laugh", and ended up watching the whole thing right through.
It shows well the coolest thing about Sketchup - 'brainstorming' the idea you can see in your head, and seeing how it can be turned into geometry that can become something practical (or not, and try another way!).

Very neat design too - a real 21st century treehouse. And I guess from the part at the end, kind of 'folding' and modular, so quick and easy to move trees. I will sure buy one if you ever get them manufactured!

Ooops - apologies to the two people who loaded v1.1 - a typo in the code was stopping the previous settings from loading properly.
v1.1a uploaded with the variable names spelled right!

NB) Adding the options dialogue has changed the file format slightly. If you have problems loading the plugin (Read past end of file error), it could be because of a file left over from installing version 1.0.
Inside your plugins folder, look for the "Trog_Renders" folder, go inside, and delete the file "Trog_Renders.dump" - this will reset everything to the factory default settings and enable the plugin to initialise properly. I'll try and add a routine to catch this error ASAP.

@pbacot said:

Thanks for the plugin! A couple thoughts on the subject...

Thanks.
Your thoughts are interesting - my main reason for this plugin was just to speed up my modelling workflow using shortcut keys, so the whole subject of rendering layers for post-production is a complete mystery to me. I'll certainly consider any ideas that could make the plugin more useful to a wider range of users.

Version 1.1 is now available in the top post, which includes the ideas suggested by srx...

• Automatic exporting of a folder of images, one for each render 'favourite'. They are placed in a sub-folder of the current model's directory named "<model name> Renders". Each file is also named after the model, suffixed with the 'favourites' index and name.
• A new options panel to set up the export settings, and also to set the shadow/fog sections to either load the complete parameter set, only the on/off status, or none at all. All settings are remembered between sessions.
• Ability to save and load the entire set of 'favourites' together with the options - default file extension '.rend'. Currently defaults to the plugin's own 'home' folder, but maybe the current model folder would be better?

Thanks, srx, glad you like it.
I read back your request post from earlier - I had missed that one, so it is an interesting coincidence that this works for your application, which is a very different style of work to mine.

Thanks for the suggestions too, I think they could be very useful to enhance the plugin.
I have been reading some more of the Ruby API, as already I was wishing to add some options for the user to select which properties should be recalled. If I can do this, I'll certainly take up your idea of an 'on/off only' option for the subsections - your shadows/fog example shows well how this would be useful.
Cycling through the stored 'favourites' would also be relatively simple to do - the Ruby script methods are designed to handle any arbitrary number of stored 'favourites' by simply editing the MAX_RENDERS constant - at the moment the maximum is 8, simply to ensure that the toolbox icon files can be found. An 'auto export' dialogue should be simple , as it would only need to know the start and end indexes and a folder path.

Following on from my previous Styles Favourites plugin, here's a new one that comes a little closer to what I originally intended to do.
It creates a toolbox and 'View' sub-menu (which can have shortcut keys assigned) that allow all the parameters of a model appearance to be quickly stored and recalled.
Unlike Styles and Scenes, this also includes things like the 'Hide rest of model' and 'Hide similar components' settings, fog settings, as well as all of the regular colours, shadows, x-ray, textures, default face colours etc.

V1.1 - 09 Dec 2012
Added features...

• Ability to automatically export a folder of images, one for each 'favourite'
• New options dialogue for export settings and fog/shadown recall settings
• Save/load complete 'favourites' sets and settings.
  V1.1a - about 10mins after 1.1!
• Bugfix - loading previous settings stalled the plugin at startup (silly typo!)

DOWNLOAD: Trog Render Favourites 1_1a.rbz
Installation:
Download the .rbz file and then use the 'Plugins->Install->RBZ Package' menu item to navigate to the download file and let SU take care of everything.
--OR--
If you use an older version of SU without this feature...
Rename the download file by changing the extension from .rbz to .zip. You can now unzip the archive. Copy the 'Trog_Renders.rb' and 'Trog_Renders' folder directly into your Sketchup plugins folder.

Basic Usage:

1. Set up your model with all of the style, shadow, hide options etc. that you would like to store.
2. Click one of the 'Store Favourite' button on the toolbar (red), or choose a 'Render Favourites...->Store Favourite' item from the View menu.
3. A pop-up will ask you for a name for the stored settings - this will appear as a reminder of the settings in the status bar or tooltips. You can also click the cancel button to abort the store operation.
4. Set up favourite settings for as many of the 8 'slots' as you like.
5. Now just click the 'Recall' buttons (green) or menu items to get the model looking just as you set it up previously.

Export images. The export item will create a sub-folder within the current model's directory called "<model name> Renders", and will then recall each 'favourite' in turn and export a bitmap image (empty 'slots' are skipped over). Image files are named after the model, suffixed with the favourite's index and name.

Set options. Select this to open an options input dialogue. This is where you set up the file-type, resolution etc. for exported files. You can also choose to export only a sub-set of the current favourites. There are also special options for the shadows and fog settings that allow only the on/off status to be recalled so that carefully set-up sun positions etc. are not disturbed.

Save/Load settings. With these you can keep HDD 'presets. The files will store a complete set of all current favourites, export settings and other options. Default file extension is ".rend".

Show current renders
Opens a pop-up box showing a list of currently stored 'favourites', and a complete list of all the currently visible rendering options.

About...
Shows a few details about the plugin and a 'Quick Start' user guide.

All of these operations can be assigned to shortcut keys for quick zipping between different view options. Unlike the earlier plugin it does not rely on you having specific Styles present in the current model.

Disclaimer
I've done my best, with the wonderful assistance of the forum Ruby gurus, to make this a reliable, bug-free plugin. But I'm still very new to making plugins.
You may use it free of charge any way you like, so long as the copyright notices remain intact, but I offer no warranty - it is provided 'as is' and with no guarantees!
Note also that this is untested on a Mac! I avoided using any PC specific API commands, so it should be OK, but I cannot say for sure.

Why?
When I made the previous 'Styles Chooser' plugin, several folks asked why, when we have Styles and Scenes, anyone would want such a plugin.
I think this has to do with my way of working - I don't do smart photo-realistic renders, or animations - I just need to make engineering designs as quickly as possible.
Styles and scenes are still useful to me, but...

• They cannot be assigned to shortcut keys - using the buttons and tabs just means less screenspace and more mousing!
• They do not change some of the settings in the way I like. For example when I go into X-Ray mode, I nearly always also want to hide 'rest of model' and 'other instances' so I don't get distracted by items in the background.
• Scenes, I prefer to think of only as 'Viewpoints' - very handy for storing a useful viewing angle, but I get easily confused when i start mixing up scenes that alter different sub-sets of parameters.
• Having an API to make the software work just the way I like is great, and I really wanted to get some practice with the API, but keep that separate from the scary geometry and maths needed for the tools that I'd like to make one day.

Many thanks to all the Ruby gurus who post here - this wouldn't have been possible without them. Particular thanks to TIG, who took the time to go through my previous code and put me straight on a few 'best practices'.

Indeed, a sad loss.
In a way it's a shame that Take 5 became such a signature tune for him - on the radio here that's about the only tune of his that has been played as a tribute. It would have been nice to hear more from his many decades of composition.

Re: 5/4 time signature.
I can't help thinking of the Mission Impossible theme tune. The original was in 5/4 time, yet when they did the recent 'next generation' films it was 'dumbed down' into 4/4 - couldn't decide whether it was considered too 'avant-guard' for radio airplay or whether the producer just couldn't find the 'time signature' setting in his music software!

Beautiful, chedda. Both the renders, and the superb modelling of those gorgeous curves.
I'm too young to recall its record breaking exploits, but I too remember seeing it at Beaulieu as a lad.

@chedda said:

in fact it's hardly a car especially with the tail fin, it's more of a stunted jet aircraft.

I some senses it was the last of the true 'cars' that held the LSR. The turboshaft engine, while in principle a 'jet engine', did actually drive the wheels - and CN7 was the last such vehicle to hold the absolute world record prior to the rules being changed to allow jet/rocket propulsion.
The North American Eagle, which hopes to set a new record sometime soon, really is more of a 'stunted jet aircraft' - starting out life as a F-104 Starfighter, once flown by Chuck Yeager, the first man to break Mach 1 in flight.

Hi Renderiza,
Yes, I'm another amateur musician.
Went through pretty much the same process as you - a bit of formal education at school, trombone in the school band etc. that just made me bored and frustrated. I think that's often the case, even for people with far more talent than me - too much concentration on the 'orchestral' style, and too much emphasis on formal 'rules' - not exactly inspiring if you are a youngster wanting to take the first steps to emulating the music that you like on your mp3 player!

Then I discovered "DIY punk", bought a bass the same day my mate got his first guitar, and never looked back. In many languages, we talk about 'playing' music, not 'operating' it or 'constructing' it, and I think that the element of 'play' is exactly what can open doors for people to start exploring music - without feeling self-conscious about their 'skill level'.
And the technology available cheaply now means that this can be in any style of music that floats your boat, or even 'sound design' - a also have a little hobby building VST plugins to make my own sounds to play with.

I don't play for an audience any more like I used to - but it is a shame to only concentrate on what we can present to other people publicly. After a crappy day at work, and too long in front of a PC, there's nothing to beat sticking on a pair of headphones, and disappearing into that "other world" for an hour.
I'm a great believer in Joe Meek's old adage; "If it sounds right, it IS right" - so long as what comes out is communicating a little of what you feel inside, then 'technical perfection' is just one option among many, but not essential. Being able to play 300 perfectly pitched notes a second is no guarantee that the tune will move people emotionally (I love loud guitars, but 10min "shredding" solo's bore me stupid!)

Your YouTube snippets sound pretty good to my ears - way different to my own 'style', but each one definitely has a 'theme' that captures a certain mood. They would fit very nicely as the kind of music used in film, TV and games to set the context of the action.

Many thanks for your guide, Rich.
Ironically, it has been most enlightening for some issues I've been having when using the current SU API, as I've been using Ruby 1.9.3 elsewhere for a while.

@unknownuser said:

Thanks for sharing this great idea and of course to the people that helped you make it better as well!

Thankyou for your kind words and feedback.

I'm just investigating the "add_style" method now, which allows the selection of a style from a standard style definition file from a HDD library - to get around the limitation that the 'favourites' must be resident in the current model.
I wonder if that could be useful too for your sky system - allowing a folder of styles with indexed names to be installed alongside your plugin, so that all the necessary visual settings are automatically available. AFAIK, this is something that can't be done with scenes, as they are specific to a particular model.