I’m trying to render the player in a ViewportFrame, to make it so that while the player is in their inventory they can still see what their player looks like as they put armor on/take armor off.
The issue that is any current methods I have tried render a motionless version of the player’s character, and in a weird way so that it isn’t seen properly.
I’ve tried cloning the player’s character and using that to render, but no luck with it.
Any help is appreciated, links to resources, concepts to set me in the right direction, anything.
I suggest that you use ViewportFrames only for displaying characters. If you need to modify them in any way, take them out of the ViewportFrame or edit an external model, then swap the current model in the ViewportFrame for the one that was modified externally.
If you experience any yielding, you can remove the character and display some text like “Rendering…” across the frame. Once the modifications are done, make that text invisible and place the modified character inside of the ViewportFrame.
As for motion, ViewportFrames don’t support animations or anything physics-related at this current given time. A motionless character is the best you’re going to get as far as rendering characters inside ViewportFrames goes.
I’m willing to assume that the motion here was hard coded or hacked together. Physics don’t work inside of ViewportFrames - that’s motion, welding, whatever.
The character, as expected, is placed inside the ViewportFrame to get the character rendered in that space at all. As far as how to achieve the motion inside the ViewportFrame despite ViewportFrames not supporting physics updates, that’s where I jump in with “hard coded or hacked”.
Hard coded - The model in the ViewportFrame is having various properties of it modified to match the character in the 3D View (Workspace). Hacked - Use of an unintended feature (whatever that is) or creating something not expected by “vanilla API” to achieve motion. Most likely not the case, but I didn’t want to rule anything out since I myself don’t know how the motion was accomplished.
I didn’t say anything about ImageLabels, nor is that a right assumption to make. The character is quite clearly comprised of a 3D model rendered to the frame and characters can’t be rendered inside ImageLabels. That also wouldn’t explain how everything else is happening (how the character updates each time something in the world view happens). That simply wouldn’t be possible.
Ok so to render a character you can just clone the character when they spawn in (or you know - actually use the methods that are meant to grab the player’s character and import it but that’s actually effort and we don’t want that).
Next you want to place it in workspace. Workspace has special properties where it will mash together all of the accessories and stuff and will fix the orientation of different parts. This isn’t required but I just like it because I’m lazy and would rather the game do the work for me.
Next you want to do some maintenance on the model. Remove scripts, remove the Humanoid’s name and health probably, etc Add your armor, tools, etc to the clone.
Next you want to put the model into the ViewportFrame.
And hazzah! Your character should appear on the ViewportFrame! (Btw do all this on the client so the server isn’t crowded with clones)
Now I did see you mention Ripull’s character GUI in Rovive.
This is correct. Physics do not work in ViewportFrames. However, the motion wasn’t really just hacked together. The way this was done was via scripts. LocalScripts can edit the model in the ViewportFrame and can do all of their normal things.
(This is a simple concept where the part is moving backwards in the ViewportFrame)
If it isn’t too much, could you give a code example of this? I’ve tried something very similar with very little results. If not, thanks for the help anyway!
game.Players.LocalPlayer.CharacterAdded:Connect(function(char)
local ViewportFrame = script.Parent.ViewportFrame
local Root = char:WaitForChild("HumanoidRootPart")
local newCam = Instance.new("Camera")
newCam.CFrame = CFrame.new(Root.Position+Vector3.new(10,0,0), Root.Position) --Not sure if this is right I hate CFrame but this is the basic premise.
newCam.CameraType = "Scriptable"
ViewportFrame.CurrentCamera = newCam
---Load the character here...
end)
I don’t think this method is good. it’s sloppy and long.
I would use a pre-existing camera on a localized point somewhere in the world and move the player’s clone to just in front of the camera you have set.
Do you think this idea is even still worth doing? It seems no matter what there are some let downs, be it too resource intesive, no physical capabilities, or just sloppy methods in general.
Yes, it will work, and it will even actually let you do things like display nearby objects. I just don’t see why you would go through the trouble when you can use a prepositioned camera and a clone placed in front of it in so many less lines!
What do you mean exactly by prepositioned camera? I think I’ve tried that, as I’ve cloned the character into the viewportFrame and made the new camera, but the clone is unresponsive even when trying to play animations into it, let alone it updating with armor and other updates to the character.