As others have commented, it depends on what you're doing with those virtual cores.

Hyperthreading gives each of those virtual cores their own flow control, but they share (for example) floating point processing resources. (ie there is physically 1 unit in the chip that actually does floating point, but its shared between HT cores).

So if your software has a mix of logic statements and floating point crunching, you get a win. If, as is the case with pretty much anything 3d, you're crunching lots of floating point, you'll get less of a win. All the tests I've ever done in the past showed it to be a marginal win but basically it shows it for what it is, which was a sop to the DB guys that Intel was courting at the time.

So wrt graphics, keep in mind these cores are virtual. If your floating point units are maxed out doing dot-products, no amount of switching virtual cores will help. Yer need more dilithium crystals, Captain.

Adam

Looks cool but you've stopped any possibility of doing this on non-Windows platforms.
No?

Oh, just looking at the files in the OSX SU8 package I see Google dropped support for PowerPC Macs...

Oh well

No, its uses the Ruby that is specified in the Framework of the SU8 Package.

On OSX using SU8, I too get 1.8.5

Well if you know the fixed tolerance, an alternative approach is to scale up your model and then allow SU to do its coplanar stuff, then scale back down.

Adam

Yes, LightUp lives in the Tools folder because right from the start I've always felt there is semantic distinction between a Plugin and a Tool.

So for me, a Tool is an additional icon in the Toolbar that can be selected by the user, and through a GUI, does "Stuff". A Plugin is something that extends the underlying data - typically with attributes. It 'decorates' the SketchUp model with metadata.

So in a perfect world, you have a bunch of Plugins that extend the underlying objects, and a Tool that operates on that data.

The idea that Google plugins are called Tools and our plugins are called Plugins strikes me as kinda silly.

Just my 2 of your Earth cents worth...

OMG. Classy design..

Thanks TIG

Hiya,

I can't seem to find where SketchUp stores the flag "Include in animation" that you can checkbox in Scene Manager.
I can't see it any where in an individual Page.. Help!

Adam

All fixed. Download again.

There you go.

http://forums.sketchucation.com/viewtopic.php?f=180&t=30694&p=269864#p269864

This ruby fragment creates arbitrarily tessellated sphere geometry by projecting a subdivided cube to a sphere.

Usage: Primitives::sphere(radius_you_want, amount_of_subdivision)

So Primitives::sphere(100, 4) will create a highly tessellated sphere of radius 100

Enjoy

EDIT: Whoops. All fixed now.

sphere.rb

Its pretty common to subdivide a cube and then project onto a sphere.

If you want evenly distributed but not a regular mesh, you could use a Hammersley point set.

@tfdesign said:

@mrwip said:

Actually, when someone says on the forum “we should add this function”, I'm really sad to see that there is always someone to respond “no, no, keep sketchup simple”... that classical answer clearly shows that there’s no innovative research in term of interface going on.

What a load of arrogant nonsense! It is precisely SketchUp's innovative interface that makes SU so easy to use. My 6 year-old daughter was building houses within 20 minutes of first using SU's innovative interface. How many other titles out there can claim this? Blender? 3DS Max? Cinema 4D? Heck! I can't even figure these apps out straight away, yet alone a 6 year old child! Drown SU in multifaceted buttons and devices, and the interface bombs.

Look at any design which has lasted. Take the humble transistor FM radio. An on/off button. A volume control, and a tuning dial. Simple as anything, but it works, and is reliable. You can turn it on and be listening to the radio straight away. Anything with menus and a over complicated interface, and you're ready to throw the damn thing out of the window (DAB for eg).

But if SketchUp was the Jeep of CAD. ie Totally bullet proof, totally stable, whatever you throw at it, it keeps on coming back for more, and did just what it said on the can and no more, I'd agree with you.

But while we all love SketchUp, its by no means bullet proof.. so it slightly falls between 2 camps: Neither the tough workhorse, nor the fancy higher order surfaces design tool.

Adam

@unknownuser said:

Just one more thing before I get back to work.

Taking the path of 'add all this stuff for ME' doesn't seem too productive and/or likely. Put yourself in the developers shoes and try to understand their vision. Personally, I would love to bloat the he'll out of sketchup as long as it was tailored to my personal needs. If i try consider everybody, which I think google does (ranging from beginners to advanced modelers) then, while I may understand some of the demands of the expert users- in all likelihood I'm not going to cater to them when they are such a small part of the user base. That balance is important to understand when making demands and I personally feel it's better to discuss ideas that include all users. Sketchup is going to remain simple wether you like it or not but it'd would be nice if the individual user could complicate it to their liking.

(sorry about the choppy typing etc. I'm on a phone)

+1 from me.

While its all showing willing of the Google guys to have this laundry list of stuff people would like, you cannot get away from the fact that everything has a cost and there is finite resource with which to deliver.

Over many years in software development I've always found that if you ask people to bang out wishlists with no 'price' to them, you kinda get junk.

Having said that, this brick bat session over the last few days does seem to have crystallized around a small number of key areas/features that seem to have broad appeal. I hope we can get some transparency and a publicly available, "live" roadmap document from the Boulder guys.

Pretty please!

Adam

@pixero said:

@adamb said:

I don't understand. 10000 pixel * 10000 pixel * RGBA is 400MBytes. You're doing images larger than this?

This is not possible on Windows as far as I know. My PC have 4GB ram and I can't export larger than some 4000px.
And THAT is not enough.

Confirmed. I just attached some instrumentation to SU7, and for a 8000x5000 pixel jpeg export (NO ANTIALIASING) memory increases temporarily to 550MB (roughly what you'd expect).

However, WITH ANTIALIASING, it gets to 3.0GB allocated and counting and my Mac starts choking..

My guess its likely that Google are doing a simple supersampling to get antialiasing. eg you ask for 8000 pixels, and it actually renders internally at 8000 x 4=32000 and then filters back down to 8000 hence the insane memory requirements.

So I'd say this is a straight forward bug that you should file with Google.

Its a trivial fix for SU to render in strips so they use less memory at any 1 time.

Adam

@thomthom said:

@adamb said:

Like Jeff Hammond, I struggle to understand what workflow using SU requires 2 GB of memory. I'd say your workflow needs looking at.

When you export really large 2d exports that memory usage easily run up to that point - nothing to do with the workflow. But that's about the only area where SU itself run into the memory issue. Mostly it's when using render engines that run inside SU's process.

I don't understand. 10000 pixel * 10000 pixel * RGBA is 400MBytes. You're doing images larger than this? Mad.

EDIT: OK perhaps not Mad. But surprising.

I do find this obsession with 64bit depressing.

64 bit general code can often run SLOWER than 32 bit because it has to pick up twice the amount of data so hurts your i-cache.

A lot of math in 32 bit applications is performed using 128 bit operands already (SSE / Altivec). No idea where people get the idea that 64 bit is 'faster' somehow - its a misunderstanding how stuff works I guess.

Like Jeff Hammond, I struggle to understand what workflow using SU requires 2 GB of memory. I'd say your workflow needs looking at.

And lastly, you're wrong to dismiss John Bacus's comment about 64 bit. He's simply nudging you to really engage about what you hope to achieve with 64 bit because from the comments above, most SU users don't understand what 64 bit actually means. They have wholly unrealistic expectations.

The big problem - I've seen this often in the past - is where people fall into the trap when asked for feature requests, by being proscriptive about their preferred solution. We should focus on things we'd like SketchUp to be able to do and not tell the Developers how they should be realised.

Having said all that, The Google SketchUp team are rubbish at providing any visibility of future roadmaps for SketchUp to help us understand where they think its going - and take us with them.

Adam

Yes, I can confirm its a repeatable bug on Mac OSX SketchUp 8.

I've logged a very grumpy bug report with Google.

Useful to know you can stop the crash by saving before exiting, but I am disappointed a bug like this could be missed. I know software has bugs in it etc, but this seems like any basic regression testing / smoke testing would flush this one out.

Just beware that it appears that SketchUp 8 has had some work done on Observers that has introduced a nasty bug.

Drag a Component into your model and leave it selected . Open the Ruby console and type:

Sketchup.active_model.selection[0].add_observer(Sketchup::InstanceObserver.new)

ie Add a 'do nothing' Instance observer and now try quitting SketchUp. It crashes in some STL deep inside SketchUp.

Bit of a show stopper as any significant plugin for SketchUp uses Observers. I guess we just wait until Google deliver a fix..

Adam

LightUp processes the SketchUp::Image objects and marks their material with some internal flags which changes how they're handled to ensure you don't get z-fighting. Basically uses the machinery in LightUp that is there anyway to handle transparency etc.