You cant do it via Part.CF it has to be done using :SetPrimaryPartCFrame(), Its a little bit odd I know but it works. See my first soloution, it should work, as for tweening just tween the value and then set it.
Too bad I already have weldconstraints inside and they dont work.
And the primary part is anchored, and everything else isn’t?
just anchor the parts and the model will move as a whole when you do :SetPrimaryPartCFrame(), No physical connections are required
The Model is not rotating. The primary part is rotating fine. Rotating the primary part is not my issue here.
show me how you are rotating it, the exact line
I tried both anchored and not anchored. Alas, it did not work.
show me the line on the script where you set the cf
if your only intention is to get it to spin theres no need for a tween, just use while true do, tweens have more memory usage so using tweens for this purpose is a bit needless (and potentially more laggy). The script itself checks out, its probably the tween
I only want it to spin once. With specific factors like Enum.EasingStyle.Quad etc. It’s most definitely not the tween. If i were to use a while true do it would probably present the same results… The model not moving. ViewportFrame is just a different world.
Yea viewports do behave differently. Personally I dont touch tween cos it has its faults, but if its spinning that part and your using :SetPrimary I dont see any reason for it not to work.
Using WorldModel proved inefficient, it still performed the exact same results. It was an extremely good attempt I believe. Thanks.
Your issue is that viewport frames don’t have the same physics as the workspace itself. As such some methodology which would normally work in workspace will not work in the ViewportFrame.
The easiest method really would be to update the part based on a part within the workspace. This is how you can also achieve exact replicas of player movement in a viewport frame - you’d essentially in this method calculate its part relative to another and then use that to offset in your viewport frame. You can see a code which has the update method in a tutorial I made - this is a clean enough way of getting it to work:
As far as I’m aware, welds don’t have the same physics as in workspace - as such they’d never work. This is similarly reflected in the behavior around Humanoids and custom rigs (whereby if you name parts of your custom rig the same as the class rig it will override skin colors etc) - Roblox for some reason doesn’t specify how this behavior works.
I am aware of this, I’ve read several post about this already. But I could not wrap my head around how would the “Animation” occur to multiple players if they activate the animation at separate times.
For instance if one player clicked a button to activate this “Animation” and the model in workspace “animates” as it should. What if a second player clicked the button just after the first? The “Animation” would reset for the first player which is an extremely inefficient way of handling things as such.
It depends how the animation is being handled, if its being done locally then players would see their local side unaffected by the other players. If its being ran off a server script to activate the animation then each player would be able to reset the animation.
You have to remember the client-server barrier is a powerful tool at your disposal, you can make it seem like walls don’t exist for specific people for example which is really useful.
I did not consider the fact that these things can be performed with a Local Script. Perhaps I should Improve my narrow way of thinking. Thank you for this.
Just be aware, their is only a few exceptions to the client server boundary as illustrated here:
https://developer.roblox.com/en-us/articles/Roblox-Client-Server-Model
Hope this was the solution to your problem.
p.s. You don’t need to call it narrow - I’ve got experience which is what makes me capable of solving issues. You seek guidance, you’ve learnt something new, and now you can excel which is actually being open minded 
Well, I have good news and bad news.
The good news is that the ClassName = "Part"s are rotating now.
The bad news is that the rotation fires in ViewportFrame 60% of the time and union will not rotate. Every unions ClassName is specified as “UnionOperation” so that’s what I wrote as you can see below.
Any idea how to fix it?
EDIT: I referenced heavily on your code if you couldn’t tell.
You are using welds instead of Motor6Ds, try those.