I made an image to illustrate what I’m trying to do. Basically, I have a ray that starts from this point. I’m trying to make it so that as the particle Index increase, the Radius output decreases. I’m stuck on the math side of things. Oddly enough, It was very simple to do the opposite (mostly because the distance and Index increases). I tried a few different methods but they weren’t successful. Any help is super appreciated 
Assuming you need the Radius to decrease linearly, you need to do two things - Normalize the Index value, and Subtract the result from 1.0.
Normalizing means dividing the Index value by the largest Index value expected. The result would be 0.0 when Index is 0, and 1.0 when Index == MaxIndex.
In other words, if you have 1000 particles, dividing 0 by 1000 produces 0, dividing 500 by 1000 produces 0.5 (in the the middle of the row), and dividing 1000 by 1000 produces 1.0! If you would use that value as Radius, you would get an INCREASING radius from 0.0 to 1.0. Obviously, you must convert the values to Floats since division of Integers will produce only Integers 0 for all particles except for the last one where you would get 1.
Once you have the normalized Radius, you just need to subtract it from 1.0. So when it is 0.0 in the first particle, you will get 1.0 as output, and when you reach the last particle with a value of 1.0, 1.0-1.0 will give you 0.0.
Finally, you can multiply this value by a Float to scale the Radius. For example, if you want your radius to decrease from 10.0 to 0.0, you multiply the result of the previous calculations by 10.0. You can also make the particles decrease until reaching a non-zero value. For example, if you want the value to decrease from 10.0 to 3.0, you can multiply by 7.0 and add 3.0 to the result. Thus, the gradient from 1.0 to 0.0 will first be scaled to 7.0 to 0.0 range, then 3.0 will be added, giving you 10.0 to 3.0…
The main issue in this setup is knowing the divisor in the normalization step - if you have more particles, you would have to enter the max. index value somewhere as we have no automated way to acquire that yet.
Thanks Bobo. Admittedly, the second I hit submit I continued to mess around with it and finally figured it out. I exactly what you said. The problem I was having was I kept doing the method for increasing values. I actually have another question regarding distance.
This was initially just for vector practice and still is, but I’m curious about piping the Distance into a perpetual updating float. Coincidentally, in my setup, I made the distance and particle count 1000 to keep things tidy. If you look at the image you can see the gradient ramp that I’m using to control the noise magnitude (I have a noise texture map multiplied by a gradient ramp so it’s smooth at the ends). The problem I’m having is that I have to manually type in the max distance (1000) and if that distance changes, it does not update in the gradient ramp’s U magnitude. Albeit, right now this is all from a PRT Maker so maybe that has something to do with it?
I might be overlooking something. But as of right now when I plug the distance into a float and then into the Dividend (the immediate connection in my image), the line goes flat. I’m essentially just trying to make sure that the texture is always spanning the width of the line. I attached an image that shows what happens if I plug the distance in. Again, as of right now, the distance is 1000 and the particle count is 1000.
As a sidenote, I must say, the amount of work I’ve had to do to get this setup has been very minimal compared to TP or Pflow. This same thing in TP was a lot more work.
I don’t see why you need to use the Index at all.
You could place another helper object in the scene at the left side of the system and measure the distance to the sphere by reading the Sphere’s and Helper’s positions, subtracting them and getting the magnitude of the result. Then divide the Distance returned by the NearestPoint by that value and you have your normalized value, updating dynamically as the distance changes (as long as the Sphere moves relative to the new Helper), and completely independent from the number of particles…
Or am I missing something?
Ah you’re right. I think I just got hooked on the Index because I was thinking in terms of arbitrary numbers. Since I’m making the count, I it’s sort of pointless. Thanks for the help, Bobo 
I just ran into this roadblock as well. On the initial Ray setup of the PRT Maker, I’m trying to add the position of an object so that the ray is between 2 objects at any given position in the scene. Whenever I tried adding the 2 vectors together, every particle snaps to the Origin. At this point, I’m 99% sure I am probably doing something out of order, but I know it should be as simple as vec1 + vec2; Or even just the object position in WS.
Bobo, I want to thank you for all the help you’ve given. Between you and Chris, you both are great.
First, the Sphere Position taken from PropertyQuery is ALREADY in World Space. No need to transform it again ToWorld because you would probably get a double-transform.
The 0,0,0 ToWorld Lookup Point would use the pivot of the PRT Maker.
But you will have to also subtract that from the Sphere Position to produce a vector that points from the PRT Maker’s pivot at the Sphere’s Position.
Whenever you see your particles go to the World Origin, it means that the IntersectRay did not hit anything (IsValid would output FALSE/0).
Please let me know if this helps…
I was able to switch the direction of the Ray. So it’s pointing from the Sphere down to the Origin. But I can’t seem to get the the Ray to point from the Sphere to another position besides the origin. Actually, to be blunt, that’s what I’m trying to do. Get the Ray to move from the Origin to another point(In my case, it’s just a teapot). I attached my base file for reference.
rayIntersect.max (244 KB)
Here is the modified version.
Basically you take the Sphere Pos and Teapot Pos and Subtract the latter from the former. This is your Ray Direction (from Teapot shooting at the Sphere). The Ray Origin is the Teapot Position.
The resulting Position of the IntersectRay is in World Space, too. Subtract from it the WS Position of the Teapot and you have your vector you want to scale from 0.0 to 1.0. But since Vectors have no start position, only a direction and length, we must add to it the Teapot Position again to shift it in space to the line between Teapot and Sphere.
At this point, the particles will look ok as long as the PRT Maker is at the World Origin (its Object Space coincides with World Space). But if you move the PRT Maker, the particles will also move. So the right thing to do is to convert the result FromWorld before outputting it to the (Object Space) Position Output node of the PRT Maker. At this point, you can move your PRT Maker anywhere you want, and the particles will still stick between the Teapot and the Sphere no matter what!
Hope this helps.
rayIntersect_BoboModified_v001.max (260 KB)
Awesome, thanks Bobo. It makes total sense now. The only other problem I ran into, and I tried 100 different ways today(hence the long response time) is now introducing the gradient into the mix. I gave up for the day once I couldn’t figure it out. The thing that I noticed is that it looks like when I turn on the Magma Flow that controls the U coordinate of the texture, is that it’s still obeying the vector from the origin to the sphere.
The way I went about it was wrong. But in general I was trying to take the new magnitude of the sphere to the teapot and transpose that to the texture coordinate. I would list the ways in which I tried it, but I must’ve tried 50 different things. A few times I thought I had it working, but then I realize the teapot was at the origin. Once I moved it to another coordinate, the gradient began to scale up and down.
I attached my base file again with the gradient on it. I can say for sure that I will be brushing up on my trig knowledge asap. 
rayIntersect2.max (284 KB)
You were probably over-complicating things. 
The calculations for the UVs were mostly done in the original Genome already.
All you needed was taking the Magnitude of the vector from the Teapot Position to the IntersectRay Position as the Max. Distance, then calculating the Magnitude of the vector from Teapot to the current World Space Position calculated for the current particle, dividing the two and you would get your normalized value from 0.0 (at the Teapot’s position) to 1.0 (at the hit point on the Sphere).
Convert to vector and output as TextureCoord and you are done. No need for a second Genome IMHO.
See if the attached version makes sense.
rayIntersect2_BoboModified_v001.max (312 KB)
haha, you are definitely correct. The setup I had was over complicating it. Typically when working out a problem with Magma I like to do each “step” in it’s own modifier and then reduce it down - hence so many of them. 
But, I appreciate the help throughout the week on this. It kind of started off as just making a general line and then I wanted to take it further. Once I have it consolidated I’ll post the preset 
Thanks Bobo!