I understand you must be new at this.
rotating vericis in a material is exactly the same rendered effect of rotating an object in game.
It costs less to perform simply because the calculations are happening on a GPU instead of happening on both the CPU and the GPU.
That said.
Your conveyor belt probably needs to function with some sort of localized action unless it’s powered - in which case it should probably be a mat, rather than a roller.
Normally, rollers like those you created are free to roll and only actually rotate as something slides over them…
That could indeed be a pain to achieve but it doesn’t have to be by using a proper material and a properly setup mesh.
first, you need to set up the mesh.
each roller needs to have a pivot point you can use to rotate the roller in the proper axis.
you can use Vertex Pain and simply paint each roller with the normalized value of its x/y/z (r/g/b) location of the pivot.
That makes it possible to isolate and rotate individual rollers via a material.
I would use the Alpha as a mask to apply/block the effect btw.
Next up, you need to axis in which the rollers roll. That’s mesh dependent so you need to cross object rotation with whatever the axis of the mesh (looks to be X, your red arrow points).
that produces a localized value of the axis which changes in real time.
Bring in a Rotate About Axis.
plug time into the rotation angle.
The axis from above as the axis. (Cross should already be normalized I think)
The solved pivots.
Vertex paint r/g/b x mesh size (because you normalized their value). transform vector -> local to world space.
and absolute world position ad the default.
That should get the rollers to all spin.
localizing this effect is a bit tougher.
you have to use some kind of a mask that triggers the behavior On and Off only when the pivot itself is marked to be activated.
I would suggest a material parameter collection with a location value of an object. But then you couldn’t support multiple objects.
So render targets become your best friends.
How you generate this matters for performance.
You have 2 options.
Draw to render target, or scene capture 2d.
drawing is usually for 1 object or a limited number.
scene capture 2d can handle almost anything (at a cost. You are rendering).
With either pathway, you have to localize a world aligned texture (converted to parameter to which you assign the RT result).
usually something like world position / 1/2 of texture size. There’s tons of ways to map it. Just need to use one that makes sense for all the objects or the whole room.
Then you need to sample from that RT. What is active and what isn’t.
Because you already have the pivot this become somewhat trivial.
take the pivot output, divide it by the texture size, and use the return value in a lerp (or IF) in which you either trigger the rolling effect on, or keep it off.
if it seems like a lot, it’s because it is.
But the cost of it is cheap as dirt, given I have at least 20 similar effects running across different things.
water interaction, flow maps, grass interaction, spiderwebs etc.
Any time you don’t need a collision response, you can leverage a material vertex offsets.
Should you really want to have actual collision on each roller…
may I suggest a skeletal mesh?
it would be a lot easier to have the rollers act independently via a PHAT asset. Obviously you will hit performance limits with too many meshes in the level. But at least they don’t all overload the CPU because the simulation is local.
mind you the physics will glitch like crazy and the objects on the belt are liable to fly out of the room.