Rombout,
Make a vertical grouped plane next to the apple which is exactly the same height (a simple method is to pushpull a grouped box so that it is fits around the apple, then move it to one side). Import your image, scale it to the same height as the plane, explode it and then apply the map using UVTool. The same principle applies for applying an exact sized texture to any geometry.
Adam,
Thanks for that detailed, but very clear explanation, it hadn't occurred to me that the random scattering was calculated along the circumferences of concentric circles. That actually is fascinating!
Sounds like your tweak is a useful addition. 
@didier bur said:
But I have no time now to work on my freebies, or update the depot, etc;
Your generosity with this amazing script and the ruby depot is already greatly appreciated!
Component Spray already has an excellent, intuitive UI and is among a small group of ruby scripts which really should be implemented as proper SU tools IMO. Great job!
@adamb said:
Jackson: The "bunching" in the middle is caused by the way the random positions are calculated.
So what factor affects the otherwise random positioning? It would seem to me the only factors which could cause this obviously non-random influence on random scattering must be either
a) proximity to the centre point
b) proximity from the boundary
Another great addition to this script would be that rather than the density parameter being input as a percentage it could be input as a "x number of components per square metre/foot/etc. As a percentage is only representative of a fraction of a whole it can't really be used to describe density in this sense as there's no way for the script to know how big each component is, and therefore how much of the total area they will actually cover. It'd be great to be able to scatter trees randomly, but at an average of say 1 instance per 10m². Just some ideas.
Can't remember the name, but back in the day (not that long ago- about 15 years ago) there was a BMX manufacturer who used a sprung cable instead of a downtube and they briefly branched into mountainbike frames. Thankfully they disappeared from the magazines about as quickly as they had appeared. To be fair they got decent reviews, but as we all know MTB magazines are extremely biased towards gadgets and fangled bits so in their excitement they probably overlooked "minor" points like torsional stiffness LOL. Re: the cabled bike in Chango's link I really wonder if there is an aerodynamic advantage of using several cables rather than standard diamond or monocoque carbon frame? It seems to me that the turbulance generated around several (vibrating) cables would cause more drag than that around a single large stiff tube or tubes.
While I'm being a bike nostalgia nerd- anyone remember Tioga Disk Drive Wheels?! I read not long ago that John Tomac was selling his old ones on ebay- crosswind terrors aside, the really funny part is that apparently after each ride his mechanic had to write exactly how many hours they'd been ridden on them in marker pen as they had a tendency to implode after about 50 hours' of use. To think these were the ultimate dream MTB component back in the early 90's and now looking at them they look like something someone fished out of a canal. 
Strangest thing, Component Spray (fantastic ruby BTW Didier!) stopped working for me a few minutes ago- I clicked to set the centre point of the spray shape, but when I clicked to set the radius it wouldn't "stick", the spray shape just moved with the cursor. I quickly searched SCF and found this update, overwrote it into my Plugins folder, but saw the same behaviour. So I went and made a cup of coffee, came back and now it works!
One thing I have always wished for in Component Spray would be the ability to scatter comps randomly within the spray area rather than weighting them towards the middle- or am I missing something really obvious? 
Rodentpete,
Sorry I didn't remember the name or correct author of the book which I read 20 years ago and immediately realise that that was the book you had referred to. 
I remember reading a hilarious book (perhaps co-authored by Michael Palin?) which took unusual names of place in Britain and used them as new words for previously undefined definitions.
The one that always stuck in my mind was along the lines of:
Ramsgate: noun. A door which opens in the opposite direction to that which you expect. All public buildings must by law have at least two ramsgates per storey.
I haven't noticed any general improvement in SU speed between SU6 and SU7 and I'm pretty sure Google never mentioned anything about a performance increase in SU7. I can only assume the better frame rate is the result of updated graphics drivers and maybe a cleaner system thanks to OS reinstall, but I'm suprised to see such an improvement.
@xrok1 said:
thanks for the response. this is still the long way of doing it and you have to texture each object individually.
I just made one large plane with the texture on it, drew the rectangles around each cobble (in your example you could just copy/array them), grouped the joints in between (as one large group), then pushpulled each cobble up and grouped them. Everything was textured from the start, the only actions were to make the geometry, so it only took about 10 minutes.
@xrok1 said:
if i make one cobble and project the texture on it, when i make a copy beside it the texture should be projected from that location just like if i moved the original should it not?
If it was just geometry and not a group or comp then that is exactly what would happen, but the fact that groups and comps "fix" their UV mapping on creation is essential to texturing in SU. Probably 90% of the groups and components I use have a texture which is mapped exactly to the geometry- e.g. if I have a png textured tree on a flat plane when I copy it to another location I don't want the UV mapping to move, I want it fixed locally.
@xrok1 said:
now if i wanted to lock the texture i could paint the group instead of the individual faces.
Painting groups is exactly what this ruby script is trying to avoid and what causes V-Ray problems via the ruby API. Besides, when you paint a group you lose the ability to manually position UV maps on individual faces which makes rendering pretty much impossible. Nevertheless, being able to choose whether UV mapping is applied locally or globally would be a useful addition to SU- someone did suggest a toggle "lock/unlock global UV" for groups so when they're copied or scaled their UV mapping would stay global. The catch is that 2 instances of a component with different UV mapping are no longer identical, so they either have to become unique components (which is what ThomThom is requesting this ruby to automate) or just plain old groups. It would be neat to see this added to SU group attributes, but at the moment I just explode and regroup to get around this.
I just quickly made a better example, attached, where the cobble geometry actually follows the texture and each set of cobbles (and the moss joints between) is a component which tiles like a jigsaw puzzle. Come to think of it, it would actually be more useful for the sets to be groups rather than components as you can then delete extra cobbles without affecting all the other sets.
xrok1,
Maybe I'm not understanding your question, but you can easily make 36 unique textured cobbles in SU now. The repeated texture has only been created because you only made one textured cobble group/component and then copied it. If you copy the shape of the cobble first, apply the texture and then make each one into a group or component they will keep their UV mapping relatively rather than locally. If you make sure that this set of groups/components has the same repeat/tile dimensions as your tiled texture you can make a cobbled area as big as you want with a perfect tiling texture and tiling geometry.
Following the logic of applying an updated "Remove C-G" type script to what you're asking for, you would end up with thousands of components, one for every single cobble in your model.
Jakob,
The second of those 3 skp files isn't my cube test, it's the same as the first skp file.
I did a full OS reinstall a few weeks ago, so I thought I'd run the cube test again- I got 15.0 fps on the 3rd run, my 3-yr-old laptop specs below. That's actually a 2.9 fps improvement on when I ran the test a year and a half ago (hardware unchanged except for new bigger C:drive, but same speed). Either SU got faster (don't think so), updated graphics drivers really work or the full reinstall has really paid off! 
.... and half the polulation of Scotland bringing a class action against Apple for plagiarising the first part of their surnames.
p.s. I had a real Ronald McDonald for a boss for a few months. He was born well before the very first McDonalds opened, so maybe he's got a case against them?
This is hilarious. I suppose Steve Jobs is also planning to sue any software developers who use the term "application" to describe their products.
Just another case of Apple seeing someone else's brandname and thinking "Damn, why didn't we think of that first? Lawyers, go get 'em!"
@xrok1 said:
at would be really cool is if you could get this script to work on projected materials.
As projected materials can only be applied to geometry directly (as opposed to groups or comps) they aren't taken into account in Remove C-G.rb's calculations. If you're referring to the fact that VfSU can't read the UV mapping for perspective-skewed materials (i.e. photomatched or manually distorted) that's a whole different problem from what this little ruby was meant to solve. Nevertheless that would be one great VfSU super ruby!
Brodie,
I couldn't agree more with your original point. As much as some of the simplest ruby scripts have become an absolutely essential part of my SU tool set (Todd Birch's "Renumber Scenes", Matthieu Noblet's "Remove C-G Materials", PurgeAll.rb, cleanup_model.rb among others) I recently loaded almost all of the (free) ruby scripts from the "Must Have Ruby Plugins - Visual Index" thread and some of them are either so complicated, or difficult to get to work or are buggy that I just want rid of them asap. "soapskinbubble.rb" is a prime example- at it's core it's ingenious and ought to be useful to every SU user, but it's bogged down with very short time limits of just a few weeks and a really awful UI which never fails to baffle me on the rare occassion that I feel the need to use it. I've learned how to get it to work twice in the past and just discovered to my shame I've forgotten again! I am in awe of anyone who has the skills, but most of all the generosity to create these scripts for free, but when you need a crash course in programming to get a ruby script to work no wonder users aren't donating!) Other ruby scripts add more and more items to the context menu with submenus and obscure names e.g. "FFD>Make Patch".
As much as it's hard to be critical without naming names, I think in any case the real blame doesn't lie with individual ruby scripters- they are after all producing these amazing little tools for no reason other than to try to make other SU users day's a little easier. Google undoubtedly did a great thing when they built the ruby API into SU allowing end users the ability to customise SU, but I think once we all saw just how many excellent ruby scripts were actually being produced we thought this process would have some feedback built in. Sadly, so far this hasn't been the case. I struggle to think of even one ruby tool which was conceived and programmed by an "amateur" ruby scripter which has been implemented as a real (read: outwith the ruby API) SU tool. That is a very serious error on Google's part IMO, as, as far as end users can see they are no longer investing in the future of SU, but are simply allowing ruby scripters to drag it reluctantly and excrutiatingly slowly forwards while other software forges ahead.
Ahh, I see... so I can continue using the current ruby script, just as long as I don't have identical components with different materials applied to them.
One further suggestion for the next version though (I bet you wish you'd never started now!)- the Yes/No selection should be set to "Yes" as default or just set up as an "OK?" warning message as it was before, as it's rather irritating to have to change it every time you run the script (which in my case is many times daily). If the end user didn't want to apply the C-G materials to the geometry they wouldn't have chosen to run the script! I think the warning is sensible though so people know they are applying a permanent change to their entire skp file.