More Instance stuff - adding noise to a sphere

Okay, next step with all my instancing particle field/grid work:

So I am continuing to develop some COMPs for making large instanced sets of point sprites and affecting their shape, color and scale with different methods, all based mainly on using small Ramp and Noise TOPs. RIght now I’m trying to figure out an efficient way to add some controllable distortion to a sphere made out of instanced geometry.

I am attaching a stripped down component so people can see what I’m working with. You can see there are a few things going on to affect the scale, shape and color of the instances, using various methods I have put together, many of which I have gratefully been helped with through my previous board posts! For now, I’m concerned with the Shape component inside the main geo COMP.

Currently, I am working with a spheroid shape that I’ve derived from revolving a circle SOP. One of my requirements is that I be able to open and close the sphere by adjusting the rotate arcs of the circle and revolve SOPs involved, hence, the base geometry should be treated as non-static.

Basically, I want to be able to take a TOP, translate it into usable position or distance values and augment the base positions of the sphere points by adding or scaling in the direction of their vector to center of the sphere. I have this working in the attached .tox, but it is not very optimized. I am using an expression CHOP that vectorizes the sphere postions and then scales them by the TOP data and outputs the xyz components back out to the instancing geo.

I know one of the main inefficiencies right now is that I am computing the same vector in order to get each of its components, when I should just be doing it once for each point and grabbing the components after it is stored. I’m still not sure this would go all the way towards optimizing, because when I crank the ‘gridIndex’ (you will see this inside the .tox) and increase the number of instances, the expression CHOP shows that it is taking upwards of 50 ms to cook on my machine, so even if the computation is reduced by 3, its hard to see it being fast enough ( i know that logic doesn’t work exactly, but I think it has some merit).

So I am wondering what thoughts people have on getting this to run faster. I’ve been thinking about how to abstract GLSL to help out either at the shape generation stage, or as a deform material on the instanced geometry COMP. I’m not sure how GLSL deforms work with instances, especially when I am mimicking point sprites the way I am, and want to avoid distorting the rectangles.

Perhaps I can somehow apply a GLSL shader to do the vector work inside of my shape comp? The problem I see here, is using the original shape data as a uniform array, the limits of the array size may not allow the number of points I want to use, so I’d have to somehow convert to some form of usable TOP right?

Anyways, feel free to have a look at my .tox, I think there may be some useful things in there for some of you. I’m all ears for suggestions to my problem or demonstrations of a solution! Thanks!
Point_Sprite_Noisey_Sphere_PS_002.tox (6.17 KB)

Anyone? I guess that post was too long winded for a forum… ah well, I’ll try and narrow down the focus of my problem and see if anyone has some ideas. I haven’t gotten back to this issue since I posted, so maybe I’ll play around some more and have a better idea of what I’m asking. Unless anyone wants to read my essay again… :wink:

Cheers
Peter

Hi Peter.
One big optimization is to change to do the following in shape component:

Replace express2 with a math CHOP with
“Combine CHOPs” set to “Multiply”

The new math CHOP takes 0.1 msec, as compared to the current express
CHOP which takes 35 msec (on my machine).

The output is identical. (I tested by subtracting the two sets of channels with another Math CHOP to be sure).

You can also get rid of the rename2
Maybe you can also get rid of sizer2 by using the scaling functions of the new math CHOP.

Ultimately though, I agree, I think a GLSL deformation shader is the right way to do it.

Cheers
Rob.

Thanks Rob,
Those things sound pretty reasonable and I’ll work them in before delving into GLSL deform stuff.