Taken as abstract 'tokens' representing 'value', I'm not sure that the form makes a huge amount of difference per se. Whatever form it takes, there will be (as always), a self-selecting few who will influence that value much more than the rest of us.
However, looking around me, I do wonder that the more we make money "abstract", the easier it is for us to spend money we don't have. I just think that maybe our brains aren't quite wired to truly make the connection between pure numbers and "value" - "how many bits and bytes are worth a loaf of bread?".

And I really feel for those people who for whatever reason, are excluded from participating. For example, a friend of mine had a stroke a couple of years ago. His recovery has been made that much more difficult because he lost his memory of every single PIN number, can't write his own signature, and for a long time was unable to make himself understood over the telephone. The more we push financial services towards password protected computer systems and remote access, the more people there are going to be who find accessing their cash very difficult if they have a disability that makes the "user interface" impossible for them to negociate.

Something that's rarely spoken of is that huge amounts of financial services are run on computer systems running some form of COBOL code. If you never heard of COBOL, that's not suprising - it's a computer language from decades past that virtually no-one is taught any more, isn't at all cool and trendy, and is god-awful to write. The number of COBOL programmers needed to maintain things properly is dwindling, and no-one wants to wholesale move to another platform because of the consequences if that were to go wrong.
IMHO, sooner or later, this utter reliance on software that is too complex to ever be 100% bug-free, written before the maintenance guy was even born, is going to have some big consequences for the world economy!

Most important: Don't try to learn them all at once!

My method (for any bit of software) is something like...

• Recce the software, play with it for a few days, to get a feel for which things I most want quick access to. For example, with Sketchup, it quickly became clear that the navigation shortcuts and axis locking were going to be indispensable.

• Are there any of those commands that I already have a 'muscle memory' for? If so, assign accordingly. For example, I use the single quote for turning guides on and off because I use other graphics software where that key shows/hides the snapping grid - so I just found my fingers going there without even thinking about it, because the function is analogous. Don't fight the reflexes you already have, work with them!

• Each session, pick a particular operation that this project is going to need a lot of, and try to learn just one or two new keys. For me, that's the key (pun intended!) - I learn the shortcuts on an actual job that needs doing - having a "dummy" session purely to learn new shortcuts rarely work well for me.

• Make sure the shortcuts are backed up somewhere! Stick that file on a memory stick that I always carry, so that I can make the software work how I like with just a quick file load, or restore settings if something goes wrong with a new install.

More importantly, the switch will only do anything for code which is already written to be multithreaded. It's just allowing some tinkering with how those threads get allocated to the different cores.

As a sometimes C++ coder, believe me, there are millions of programmers out there who would give their right arm for a "magic bullet" that transformed single-threaded into multi-threaded code automatically and safely - it's one of the toughest problems in programming!!

@slbaumgartner said:

I'd like a built-in user-configurable tabbed window for tool sets.

Ideally - arrange all windows, dialogues, toolbars, visibility settings, snap settings - give this a name - assign to shortcut key. And now (for example)...
Shortcut 1 - I want to make a new component without any distractions.
Shortcut 2 - Now I want to paint/texture things with the prettiest view possible.
Shortcut 3 - I'd like to manage all my custom materials and components.
Shortcut 4 - Show the boss/customer what I'm up to right now.

Much as I love SU, the user experience (especially once you have a few plugins installed) is too much like trying to keep your kitchenware, DIY tools, stationery, clothes, toiletries, car spares etc. etc. all in one drawer that you have to rummage through every time the task at hand changes. Nor do we put all "sharp pointy things" in one category (cutlery for the dinner table, lawnmower, surgical instruments) or all "red things" in another (tomato, stop sign, blood sample).

Of course, SU is not alone in this respect - way too much software is "tool oriented" rather than "task oriented". SU's customisable toolbars are a promising step, but different tasks not only require different toolbars - often they require a different arrangement of the windows, different camera and style settings, different use of inferencing and snapping, maybe a different component/material folder visible...etc...

PS: And please can we sort DC's out!? I want to be able to say - "stick an M4 bolt here, it should be 20mm long, with a countersunk head" - at no point am I thinking "can I please have yet another duplicate component definition that no longer relates to all the other instances of this generic thing that should only need describing once!!".

Sadly, burkhard's expreience sums up our own. We got one in at work for our software development team to look into - after a few hours playing with the provided examples, it went into a drawer, never to be seen again, without so much as a line of 'integration code' being written.
Even in the videos, you can see how slowly everyone does everything. It looks like it ought to be intuitive, but everyone's opinion here was the same - you seem to need to develop some kind of special motor skills that don't come very naturally (hopefully before your arms drop off from fatigue!). The idea is really sweet, but the actual experience of every single one of us was "gimme my mouse back!".
One has to wonder wonder just just how much practice the demonstrator's had, and how many takes it took to make their marketing videos!

As you say "pushing the boundaries", and surely the technology will improve.
However, consider this...
'Gestural' technology is not as new as all that. The Theremin (wave your hands in the air musical instrument) is getting on for a century old. Moog had a good stab at popularising it, it was used by many composers (lots of cool sci-fi movie soundtracks especially!), and they're cheap as chips to make. Yet, theremin players are rare as hen's teeth - and ones that can play in tune and expressively rarer still!

@piratebrian
How I wish I had noticed your guide before! I've spent the last few months commissioning a new CNC router at work, and have really struggled piecing together a work-flow for migrating our existing CAD. Your time and energy spent putting together such a clear guide are much appreciated. Thankyou very much indeed!

IIRC, it's not so much using a proxy variable that makes it work - it's the use of the 'current()' function.

As an example, consider you made a DC where the equations only allowed a component to be an exact number of feet long - very common for models of kitchen units, building supplies etc. When you resize it, things happen something like this...

• You resize your component by whatever method - which changes, say, LenX. We didn't bother snapping to anything because we know the component only allows valid sizes.
• The calculations are done by sub-components inside the DC to calculate their sizes - this causes a new value of LenX to be calculated, conforming to the 'whole units' constraint.
• But if LenX just got calculated to a new value, different than the one supplied by the scale tool, that means that the DC just got resized again.
• If SU were allowed to see that change as another re-scaling, it could set all the calculations running again - and with a very complex DC, this might just go on and on forever, with every calculation triggering yet another re-scale.

The 'current()' function is used to resolve this problem - it's guaranteed to read the value either before the calculations start, or after they have all finished (which one, or both, I can't quite remember). It ensures that you receive a nice stable value, and that the maths has a proper beginning, middle and end, with each resize only calculated once.

PS) Technically, that's probably nothing like what really happens! But I found that keeping that idea in my mind really helped me get my first few DCs working.

Ah, Mr. Faust, your work seems strangely familiar...

...come on, own up!...

...you work for Bradford Metropolitan District Council's department for planning and development, don't you? That housing estate opposite my house is more cramped than the Victorian 'slums' that were there 150 years ago - you should be ashamed of yourself!

@dale said:

The thrust of opposition has quite often been the "What should happen if these new GMO species run amok"

Naturally, it is right to be concerned about this, but I must admit, I feel that the over-emphasis on the 'zombie mutant take-over' probably suits the big corporations rather nicely. There is actually very little independent evidence either way on that one, and being able to produce more food with less resources is a wish as old as agriculture itself. Nor is there any particular reason to assume that GMO foodstuffs should be harmful - at least, no more harmful than the fat and sugar soaked diet that the food industry seems to prefer that we eat already. Caution is wise, of course - but I feel that, sadly, the only opposition to GMO that gets heard (shhh, you can hear it if you're very quiet) is always of the "zombie apocalypse" kind - making it very easy for the corporations to shoot down; "just a bunch of luddite tree-hugger loonies".

Meanwhile some very real issues about the state of global food production go unmentioned. The science itself is neither good nor evil - as ever, it is who is is control of it and what they use it for that are the problem.
Whether GMO is safe or not, it is clear that the likes of Monsanto are very keen on cartels and (preferably) monopolies. This is not good economically, nor scientifically - in both senses we could be looking at essentially a mono-culture. Once every farmer is growing one of the same few varieties of crops, what happens if a new pest or plague evolves that can defeat the GMO "firewall" - that's it, the whole lot goes, and we'll have reduced biodiversity such that finding new replacement varieties will be all the harder.
And once all the other sources of seed and feedstock are driven out of business, what reason it there for the few that are left to keep the price reasonable?
Well, you could always breed your own, I suppose - except that every seed and every grain of pollen contains patented DNA fragments - and the folks from the "not a legal entity" mentioned by Roundup will be calling to round you up and get very legal indeed.

I would not deny the Roundup team their opportunity to speak, it's a valuable part of democracy, after all. And of course, the same should be true for those who hold alternative opinions on the subject...
The case against Glyphosate.

@nyal mellor said:

Thanks. I think some of the 3D exports will export faces and this information could be reused

This is certainly possible - I have done something similar here, exporting as OBJ, then using a custom Ruby script to parse out the vertices and faces.

I think that whatever file type you export from SU, you're going to need to do some processing on the output. You may find the free mesh editor 'MeshLab' useful - this can read and write a huge range of 3D files - many of them are simple text data if you look at them in Notepad, so you can choose whichever gives you the least work to do.

Assuming that you may need to do the editing by hand, the '3D triangulated surface (.GTS)' format looks like a good candidate. This is a simple text format containing lists of numbers - first the vertices (three numbers per line), then edges (indexes of the end vertices), then triangles (three vertex indexes). A line at the file start declares how many of each there are. The vertex index is not explicitly written at the start of each line - they are assumed to be in whatever order they are listed in the file (this is pretty common in all 'text' 3D files). If you can manage without the explicit numbering, then the editing is simple - simply replace space characters with commas in a text editor, and delete the 'edges' section that you don't need.

@numerobis said:

it seems that the problem or the slow part is not the storage hardware but the way sketchup is handling the data

Yes, that is almost certainly correct. In fact, it is hard to say exactly how much the tests really reflect the true HDD access times...

What is being measured here is how long it takes Sketchup to complete the task of requesting that the file be saved. Unless Windows has been twiddled with, it will be using 'write-behind-caching' (presumably MacOS does the same). That means that the operating system can decide to hold any or all of the data in memory, and perform the actual HDD writing some time later (when it decides that it's got a spare moment or two!). In principle, you could save a file, close Sketchup, watch funny cat videos for a couple of hours, and still have some of the file in memory that doesn't get saved until you shut down the machine (rather unlikely though!).

This is further complicated because if there isn't enough RAM to hold all of what you want to save, much of the data may have been shuffled to the page file, which may or may not be on the same HDD as the eventual destination of your file.

And then there's RAID, which complicates things even more. A RAID can be used in several modes, many of which duplicate all or part of the data across different drives - the idea being that, in the event of a HDD failure, the data can be reconstructed from the other drives in the array. Alternatively a RAID can be used to increase speed by splitting files and saving only part to each drive so that they can be accessed in parallel.
Hence the advice not to mix SSD and HDD in the same RAID - more than one drive will be accessed whenever something is saved, so the speed is, to a greater or lesser extent, limited by the slowest of the drives in the array. It also means that the RAID controller might not work optimally, as it may assume that it is working with a set of drives that have similar performance.

When trying to decide whether a group or components is most appropriate, I always ask myself the following questions...

1. Would this 'object' make sense if I were to save it as a separate file to be used in a 'library' of parts? (I may not actually want to save it in my 'library', just that it would make sense if I did).

2. Do I need multiple instances that will inherit any edits that I make?

3. Is the 'object' something that I would want included in a report? (e.g. to show how many instances there are for costing or producing a bill of materials)

4. Is the 'object' something that I might need to 'find and replace' at some point? (e.g. I might want to swap all my pan-head screws for countersunk ones, or to use low-poly 'proxy' objects to save CPU that I will later replace with a more detailed version before export)

If you answered 'yes' or 'maybe' to any of the above, then make the object a component, as having a shared definition is the easy way to make all of those things possible. If there is any doubt, consider...

• Component instance -> New component definition -> EASY (make unique)
• Component instance -> Group -> EASY (Explode then group)
• Single group -> new component -> EASY (Make component)
• All component A instances -> instances of component B -> EASY (Replace All)
• Multiple groups -> instances of same Component -> HARD WORK!!

Note how the only tricky one there is replacing multiple groups with instances of the same component - you will have to find all of the groups first, probably replace them one at a time, and placing them right could be tricky if the groups don't use the X, Y, Z axes consistently. OTOH - all of the other cases are simple 'automated' tasks.
So, if you are unsure if a component or group is the right choice, the pragmatic answer is to err on the side of using a component, as it is less work to sort out later if the choice turned out to be wrong.

OTOH - if you know for sure that the only reason for grouping is to treat the geometry as an 'atomic unit' that won't interact with 'loose' geometry, or that it will only ever be used in one place, using a group makes more sense - you won't be 'polluting' your component browser with unnecessary objects.

@pauly7 said:

Ok great, thanks... maybe i am trying to be too organised, thanks.

Better that than not being organised enough!!

Maybe your 'folder' analogy fits better than you think...
A HDD folder may contain any combination of:

• Files of any type (analogy: faces, edges, construction lines, components...etc...)
• Sub-folders nested to any depth (analogy: nested groups)
  Note how, in this view, a component is seen as a unique object (akin to a file), rather than as a 'container' (akin to a folder). This is generally how I view the difference between groups and components; a component as a single 'indivisible' unit, just like a line or a face, and a group as a 'collection of parts'.

But, of course, other users have very different views on this, and are just as successful with SU. I would say that, much more important than any of this 'semantics', or which 'analogy' you use, is that you decide on a usage that make sense to you (or works best for the kind of things you model) - then apply it consistently in every model you make. Being consistent reduces the chance that you'll find yourself scratching your head later on - when you open a file from six months ago to make some edits, and have to waste time trying to understand its structure.

Similar here -
We use an SU plugin from 'Flight of Ideas' that lets you export the outline of any individual planar face as an SVG file - then import the SVGs into a vector graphics program to arrange the individual outlines into a single file ready for machining.
If you don't already have a 2D vector drawing program, a very good free-ware option is InkScape.

I agree with you, Mike - even if the process is only some small part as beneficial as he claims, he and his investors deserve some reward for their innovation. And I bear him no malice for a bit of exaggeration and hyperbole - he has to do his work within the same economic constraints as any other business.

Institutions like investment via stocks, limited liability companies etc. were set up to provide a framework for encouraging risky ventures just like these - I think that where things have gone wrong is that they have become an end in themselves rather than the means.

An individual or business wishing to see themselves and their families provided for as return on their investment I have no problem with. But for humanity as a whole not to secure its future viability because there's "no money in it" is a different matter - we have to find a way to make these things happen when the exchange economy cannot provide the solution.

It should NOT require a profit-motive for the human race to protect its own life-support systems! Does any of us have to be paid to cross the road carefully? 'Incentivised' not to eat rotten food?

If it requires a profit-motive before we will take care of the planet that supports us, then bending over backwards to create such incentives is not the answer - we need to fix our societies so that the sociopaths who know the cost of everything and the value of nothing do not get to call all the shots!

Reading a little more into the report, it seems that it is methane rather than CO2 that the enzymes convert to plastic. Now that I think about it, that makes sense, as methane would be a much more viable monomer for turning into plastics.

On the face of it, that's quite good. Volume for volume, methane is a worse greenhouse gas than CO2 - e.g. cattle farts from intensive beef production are a seriously big contributor to climate change, as I understand it.

However, methane has a lot of potential as a relatively clean energy source, certainly compared to the likes of oil and coal. You would still output CO2 from the combustion, but at least you are turning a very bad greenhouse gas into a slightly less damaging one, and without the problems associated with particulates, acid-rain, oil spills and preventable accidents/illness caused by coal-mining.

So in that sense, this could be a case of 'robbing Peter to pay Paul' - the energy from the methane could probably be put to better use to power a recycling plant for existing plastic than to make more of the stuff.

Trouble is, the $$$$ mean we don't get an independent analysis - it IS promising, but I never quite trust these sensationalist reports. I'd want to know...

• 1.8tn pound emissions from "the plastics industry". Is that just to refine raw plastics, or does it include manufacturing too (which would not be saved by this process). He's gonna want to make that number look as big as possible, after all.

• There are 1000s of types of plastic. What proportion of that can be replaced by the miracle substance? What chance that the process is adaptable to other materials?(especially if the process is kept secret).

• "Carbon emissions are captured from..." - that isn't quite "thin air" then is it?!

• Is it biodegradable? recyclable? carcinogenic? mutagenic? Best scenario - it's unharmful and biodegradable, in which case the CO2 will be re-released as it breaks down, so only carbon-neutral. Otherwise, it's still a pollutant.

• How much energy does the process require? Where does it come from?

• What are the other raw materials used? And what waste products are there?

• How does the "harvested" CO2 get to the plastics plant? Some clever new means that requires no energy? What happens to all the stuff that isn't CO2?

@jql said:

...pdf has missing lines. Submited to trimble...

Could be Adobe need a kick up the rear too. I see this problem on a regular basis when exporting PDFs containing images from plenty of other applications too - e.g. CorelDraw, MS Publisher, MS Word, etc... It's real PITA - PDF is our standard format for all of our 'customer-facing' documents, and we have hundreds of them to try and keep up to date.

Given that even Adobe's own PDF viewers come up with "this document may not be displayed correctly" more often than not, makes me think it's about time for a new "universal" document standard - something under the control of a proper international standards agency rather than a single company who can change the spec' on a whim whenever they feel like it.

@archidave said:

it seems quite a fundamental flaw

"Fundamental" - that is the key word. The problem is just inherent in any numeric system with a finite amount of precision. Without hugely complex (i.e. slow) assessment of the "rules of mathematics", programs will always work this way. When we do maths using our brains as the computer, we implicitly use all those extra rules without even realising we are doing it - so the quirks of floating point maths come as a nasty surprise to most programmers at some point in their career.

If we add the width of an atom to the diameter of the solar system, logic tells us that we must have made the original number larger - but to a CPU, all it sees is that the pattern of bits in a register probably didn't get changed, and that makes the end result "equal" to the start value despite what the semantics of the equation tell us.

This can be overcome with special processing that does interpret the "meaning" of the maths. For example, if you were to do the same maths as your example using Ruby's "Rational" class of numbers, you would get exactly the expected answer - but the cost in extra CPU load is huge and would likely outweigh the advantages in most cases.

@archidave said:

It doesn't seem practical to re-order potential calculation

I do a fair bit of Audio DSP programming, where equations are often used within feedback loops at high sample rates, and it is incredible the difference that a simple swap of instructions can make - beautiful smooth filtering one way, blown speakers/eardrums another! How do I know which to use? - if I'm lucky, Google will find me the most stable algorithm, otherwise it's mostly just good old trial and error!

It's an area of computer science that fills volumes of textbooks and research papers every year - and sadly, there are very few 'shortcuts' that us mere mortals can rely on. But to make the most of the available precision, this kind of code re-factoring is indeed the most "practical" solution.

There are a few 'rules of thumb', though. For example, when adding and subtracting, the result is usually most reliable when the two values are similar in magnitude - but, of course, some algorithms just don't have an easy way to arrange that!