fitting randomly scaled particles neighbor to neighbor

[druitre]

Argh, I tried but I need a pointer to get me started at least! Here's the challenge: I want to randomize scale on a bunch of boxes emitted along a curve, but I don't want gaps inbetween the result (the boxes need to touch perfectly - think houses on a street, each one differently sized yet always touching their neighbors).

How would I tackle this?? I was thinking scale every odd particle randomly, then have the even ones look at that and adjust accordingly. I've tried this in a number of ways without succes. And maybe I'm not looking in the right direction.

Any and all suggestions welcome!

Jasper

[rray]

Just an idea, it might be easier to not randomize the scale and then calculate matching positions on the curve, but instead to randomize point positions on the curve, and then compute houses that fit between these... But no idea yet of how to go about that either.

[druitre]

Hi Reinhardt, funny, that's just what I was thinking too after posting. But if you have an idea of how to go about it, don't hesitate

I was trying to calculate difference between original pos and after offsetting randomly now. And use that to drive scale.

[julca]

Hello,
I have not the direct solution, but maybe this that I've done before can point you in the right direction :

[Mathaeus]

And me too
Fast method is midpoint. First you have an 'sampling array' distributed along curve, from 0 to 1. Next step is array of cubes, having a size (count of cubes) of first array -1. Finally, for each cube, you're looking for two positions in 'sampling array'. Something like ID of each cube, and ID of each cube +1. Midpoint (linear interpolate node with weight of 0.5) is center, distance between two is scale (or half, or twice of scale, not sure right now). Point is, in case of randomizing, only 'sampling array' is randomized, so there are *two* points to determine the center and scale. Also you need to be careful with randomizing, to avoid overlaps in 'sampling array'.
The way you mentioned is possible too, but I think is more complicated, as it is asking for ratio (scale * size, divided by something) to be calculated.
Slow but more versatile method ( allows to randomize by members of final array, that is, your cubes), is iteration, repeat node an all that.
Have some working compounds based on 'midpoint', will post some cleanup here, this evening.

P.S. - regarding all post that appeared when I writing this, it seems there is no need to post anything

[druitre]

@ Julien: thanks, your idea points me to the solution to another problem i'm going to have to tackle, but for this one I think it doesn't apply. I have to take an even distribution along curve as a starting point (I'm populating an entire city and the curves are extracted from an open street map, it would be near impossible to go in manually due to the amount of curves) and I think your solution is more about distributing after calculating scale. But if I'm wrong, let me know!

@Mathaeus: interesting, I think I follow quite a bit of what you're saying, although still a lot that I don't know how to implement, not straightaway at least. By your PS, do you mean your idea is similar to Julca's?

[druitre]

Oh, and the midpoint stuff would still be welcome!

[Mathaeus]

@Mathaeus: interesting, I think I follow quite a bit of what you're saying, although still a lot that I don't know how to implement, not straightaway at least. By your PS, do you mean your idea is similar to Julca's?

It's what RRay suggested - will post something this evening (now it's around 4 PM here). There are already some compounds flowing around, based on that, but they are really not enough clean for explanation.

[Mathaeus]

Here is setup without any array, I've placed all parameters on side of ICE tree, should be easy to create compound. Pic shows the method of 'houses', where each particle is finally placed in middle of two initial positions.

[julca]

@ Julien: thanks, your idea points me to the solution to another problem i'm going to have to tackle, but for this one I think it doesn't apply. I have to take an even distribution along curve as a starting point (I'm populating an entire city and the curves are extracted from an open street map, it would be near impossible to go in manually due to the amount of curves) and I think your solution is more about distributing after calculating scale. But if I'm wrong, let me know!

Yes, your right my method requires that you set scale for each different object to instanciate/duplicate and only after they are distributed.
Sorry not to be more help but I already see a lot of good solutions here ;) !

[druitre]

Matthaeus, fantastic!

I have to do this on a curve that consists of many many subcurves though, and the UV to Location that you use reads only one subcurve. I'm modifying, but it's growing over my head again - setting pos before and after random offset, calculating distance between, using that to drive scale, is what I'm trying. The 'distance between' that I store as a custom attribute, when i plug it into a set scale, it returns zero - do i have to do something to get the value i see?

Or: is there a way to get all subcurves UV?

https://www.dropbox.com/s/cptkot54diemr ... 2.rar?dl=0

[Mathaeus]

I think I won't be able to read your file with my ancient XSI. Anyway, here is version that works with sub-curves. Now there's 'initial size' instead of count, because count needs to fit to length of particular curve. Added an option for orientation in case of buildings or trees on elevated terrain, always point at Y up, but still aligned to curve. Just for info, there's scale limitation with this 'randomized even distribution' method, for now, scale shouldn't go more than close to twice of initial even distribution - if this is a problem, I'd try to add additional sorting, or you can put some continuous noise (turbulence node) instead of 'random' node.

[druitre]

Brilliant, Mathaeus! Many thanks! I'm so close now - the last thing to tackle is even distribution. My subcurves are totally uneven but the starting point (houses along streets) dictates particles evenly placed along the curves.

I'm using NNois 'Generate on Curve' for this, so if I could use the pointpositions from that I'm good. Or if there's a way to even out the pointpositions generated by your setup. It seems your setup generates the particles way faster?

By the way, twice of original scale is more than enough for me, I have to be within a small range or it will be very visible my houses are stretched or squashed.

Cheers and thanks a lot so far!
Jasper

[Mathaeus]

Curve > Reparametrize > Chord Length (from modeling panel) should create as much uniform UV distribution. Works better if you fit the curve to more of small subdivisions - same panel, Curve > Fit - from my understanding, chord length means length between knots, so a lot of smaller distances is better result. Works in case of sub-curves, too.

There is no any user created loop in setup (no 'repeat' node), for now, so ICE is free to run its own arsenal of optimizations. By the way, form some tests I did recently, in such cases (no user created loops) ICE seems to be still fastest engine of this kind, around 1.5 times faster than anything else....

P.S. beside point positions, there are few other parameters to get, like first and last ID on particular sub-curve, maybe a few more, so you'll need to re-create these things, if positions are generated by something else.

[druitre]

Ah, you're right, that works too, the 'reparametrize' function. I'm off to incorporate your stuff into a compound now, tweaking around. Thank you so much!

-Jasper