[Plugin] Component Spray update
-
Cool plugin, Didier. I really believe these kind of 'smart' tools are the way forward.
Jackson: The "bunching" in the middle is caused by the way the random positions are calculated.
Just as an experiment I added some 'clash detection' to the plugin. The idea being before it adds the instance it checks there is space for it. It really reduces the overlap of Component instances (obviously) but also helps the "bunching" in the middle because it avoids adding too many near the middle.
[I didn't want to make big changes to Didier's baby, so it only catches most clashes - with more work it could be made to never add overlapping Components]
Adam
PS Didier, I'll send you my changes. Ignore / use / abuse or whatever as you see fit.
-
That's interesting. I thought it was some code in there that deliberately clustered the components, simulating the effect of a forest. There are times when I want that effect and there are times when I don't. Having an extra option for this would be really nice.
-
@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 boundaryAnother 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.
-
@unknownuser said:
PS Didier, I'll send you my changes. Ignore / use / abuse or whatever as you see fit.
Cool
Thanks Adam.
But I have no time now to work on my freebies, or update the depot, etc;
-
@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!
-
@jackson said:
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 boundaryIts a bit involved but since you ask...
If you use a random number generator that is normally distributed and use it in an orthogonal linear space you're all set. So compo_spray along a Line works great with no bunching. But for the Spray mode, the script calculates a random radius and a random angle around the center. However, the circumference of a circle close to the center is smaller than at the outside edge of the spray so using a normally distributed random number for the radius effectively biases position generation to the center point of the spray.
Adding "clash-detection" means you can set a "N per unit area" threshold so although it tries to add more near the center of the spray, they get rejected hence you don't get that bunching.
Phew....Fascinating, huh?
-
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.
-
fascinating indeed. now everything makes sense.
-
@jackson said:
It'd be great to be able to scatter trees randomly, but at an average of say 1 instance per 10m². [/quote]
I'm looking for a way to randomly place people in a room: Jackson's suggestion would really do that job.
Didier: Looking forward to your having enough time to re-address this Ruby.
-
I really appreciate the generosity with which you supply this community so many innovative tools. the dialogue that comes with your scripts is essential to improving SketchUp and how people interact with it.
Thank you. -
this looks like an amazingly useful plugin. thanks!
-
-
Latest version is here: http://rhin.crai.archi.fr/RubyLibraryDepot/plugin_details.php?id=76
-
@didier bur said:
Latest version is here: http://rhin.crai.archi.fr/RubyLibraryDepot/plugin_details.php?id=76
thank you very much !
-
Dear Farmer,
Finally I have an occasion, and finally I straighten my install and finally I harvest a moment of your efforts.
Thank you, Farmer. You help make living in this valley a pleasure.
-
EDIT: This error may just be mine: perhaps having enabled 'hide everything else while editing group'.
There may be a limit on how far the routine likes to be 'buried'? That is, when I run it on a simple group, no sweat, but when I try to run it in group within a component, it seems to fail. Please see image. Top success within the group copied out of the component. Lower failure on the same group residing in the component. Perhaps I missed some advice in the use instructions. (Not an issue of overshadowing entities.)
I tried the same test in the naked group in the same location as the failing component and it worked fine, so it does appear to be that the routine wants to breathe a bit.
-
When spraying grass components onto a large area and I want to keep the numbers down the lowest available setting of 1% is still very much too high, so I make a request for percentages below 1.
My work-round for this is to include within the component a large triangle so the spray density is thus limited and then edit this out of the component later. This works fine.
-
Having a hard time now. Rarely is anything being sprayed, no matter the setting. No groups or components on the receiving end.
FloatDomainError?
Advertisement