Rendering the character with a ViewportFrame

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.

Thanks!

34 Likes

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.

1 Like

Are you sure? I saw in Ripull’s game Rovive that he had a live render of the player that was moving around and had all of the player’s armor on.

2 Likes

Here it is, https://gyazo.com/c57ac71862a7122dbd7eb5901f83fb08

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.

Do you have any suggestions on how to replicate something like this?

No. I’ve never made a system like this, nor have I had a need to.

Ah alright, Thanks for your help then! I’ll continue to see what I can do to find something similar.

Perhaps I’m an idiot, but what on earth do you mean “I’m willing to assume that the motion here was hard coded or hacked together.”

Are you suggesting that he somehow used hundreds of image labels to make that animation? I don’t understand.

I meant that statement almost literally.

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 position it in front of your ViewportFrame.CurrentCamera.

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.
MV14Mf9KtX
(This is a simple concept where the part is moving backwards in the ViewportFrame)

7 Likes

I’ll try this out tommorow, as it’s late for me. Thanks for the help, if it works ill mark it as a solution.

Try just have the viewport frames camera focus infront of the player? May work.

How exactly would I do this?

Couldn’t you create a new camera then get the position of the player’s HumanoidRootPart then offset it by a few studs?

Then you would set Camera.CFrame to the new CFrame.

Of course you then need to set the viewportFrame’s camera to the new camera and then you need to clone the character and put it in the viewportframe

1 Like

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.

2 Likes

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.

Not for me.
It’s a lot of work for no reason.

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.