Currently viewportframes can misrender welded objects, this appears to be an issue where if you weld too many parts together at once and then immediately parent it to a viewportframe in the same frame, the displayed result will look like a complete mess.
This appears to be a sort of racing condition because sometimes it fails and sometimes it does not. It can also be fixed by adding some arbitrary waits before parenting into the viewportframe. The key factor seems to be waiting before parenting it outside of workspace, it seems like if you go too fast it interrupts some internal calculations and stores data incorrectly?
To quickly add, I’ve tried using simple task.defer and task.wait() to wait an extra frame or two at times, and it appears the time it needs can be more than 1 frame
This is very frustrating as this undefined behaviour makes it extremely difficult to automate viewportframe creations if I have a unknown amount of time I have to wait for all of the welds to settle.
Just for full clarity, here’s what I’m currently doing in my setup sequence:
- for loop each car and anchor all their parts
- parent all the cars to workspace at position 0,0,0 in workspace
- task.wait()
- for every car in workspace, find all their connected pieces using workspace:GetPartBoundsInBox and then weld them together
- parent back into replicated storage
- the gui now initializes and puts the car models in their respective Viewport Frames
Here’s a video showcasing the issue:
And here’s my cutting and pasting the same object back into the viewport frame just to show that it’s simply a render issue
Addendum:
After some testing this appears to be primarily be an issue in step 1, if a part was originally unanchored and I anchored it, it seems to cause this weird chain reaction. The solution is to anchor all the pieces, run task.wait(), then parent them to workspace. The wait in step 3 is no longer necessary
