Flipping X and Y (object position) does give you the reflection.
You can mirror their position but not their shape without causing weird things to happen. Assume that the semi-transparent red plane is the mirror. Here’s the hand with only its position reflected.
This is obviously wrong. Here’s the hand with its rotation also flipped.
This is still wrong (notice that the thumbs should be in the same side in a real mirror.) Here’s the hand scaled negatively in the x-axis:
This is more correct, but notice how weirdly the mirrored hand is shaded. Here’s a close-up. The original hand is on the left, the the inverted one is on the right:
The weird shading is because the faces of the mesh are also flipped. Faces that were pointing outwards are now pointing inwards. Basically, the mesh is inside-out. This is very obvious on certain meshes. Again, original on the left, inverted one on the right:
6 Likes
This can be beneficial for many players.
I will try and incorporate it in.
1 Like
How is the performance for ViewportFrames? Would they be suitable for a grid of a few hundred items?
3 Likes
Exactly. The same thing will happen if you give the camera a CFrame with a negative determinant, the whole world flips inside out.
If they don’t change, then the image doesn’t get re-rendered.
I haven’t tried it in my game yet because I’m waiting for particle emitter support so that an inventory of items I have can be shown as they would appear in the game. Is there an ETA for this by the way?
1 Like
I’m thinking that:
- Load Mesh ID
- Load Mesh Texture
- Create the viewport
x300
Would take more performance than
- Load Static Image
x300
3 Likes
This is definitely something that will be useful in the future for a more immersive gaming experience! What a nice addition!
You’ll probably be loading the mesh & texture eventually anyways. Using an ImageLabel actually just increases download size in that case.
1 Like
Something to be aware of wrt ViewportFrame is that even though the image doesn’t get re-rendered unless it needs to be, it has to be stored in memory and the memory impact is larger than that of static images on mobile, because for static images we’re able to use efficient texture compression.
For example, a 128x128 frame on mobile will take ~64KB as a ViewportFrame and ~20KB as a static image, assuming it has alpha. If you have 300 images like this, you’re looking at 19MB → 6MB reduction, which is helpful for low-end devices.
17 Likes
This would work well with inventory systems. But, I can’t script the part / model to spin which is annoying. (Well I’m positive that’s the case)
It’s faster to spin the camera itself anyway. This works especially well when you want to make multiple, similarly-sized items spin since you can make it so that they share the same camera. Try doing that, instead.
1 Like
I find it weird that ViewportFrames can only render stuff that is placed inside them. Instead, they should have a Subject value, which is set to itself by default. This would allow us to render objects already present in the workspace without having to clone them every time.
21 Likes
This would make a lot more sense and would certainly improve performance, and may also allow much quicker creation of TV screens & the like, like the BreenCast in Half Life 2.
4 Likes
Currently I have to clone things to them and then update the cframes every frame, so a subject option would be much much better lol
3 Likes
I have a mirror module. It works alright for intermediate sized maps with 5 mirrors, but anything beyond is just a horror to witness (below 30FPS without other scripts).
1 Like
This also means that you’d need to have every single object you want to render as a single model since this subject value can only hold one instance. This would over complicate things. Right now it works like a isolated workspace which is really good IMO. Why complicate things?
1 Like
Then a userdata of some sort? The current implementation limits this extremely useful feature to nothing but minimaps and model previews. The “Viewport” in the name itself implies that it’s supposed to project a 3D space onto a 2D rectangle, basically acting as a second camera, which it practically can’t do without extremely memory and performance expensive hacks.
Also, you saying that a “Subject” property would limit the usability to objects that have the same parent, but the way it is right now we can’t even have that without copying the thing for each ViewportFrame.
4 Likes
In that case what you’re asking for is Render Texture. Not a Viewport Frame. Either way tho, the more cameras you add in a game engine the higher the cost will be for performance.
Especially when they’re trying to maintain the current workflow of development especially when it comes to the API. Having objects inside of the Viewport Frame itself keeps the objects from being rendered in the world.
I mean they could’ve just had the subject property like you wanted, and you simply put the objects off screen in some obscure location away from the origin so the player can never find it. And then have that show up on the viewport.
But they opted for an isolated workspace (not the game.workspace, but I’m refereing to an actual workspace where you work.). Personally If they ever decide to instance the smooth terrain I can see us eventually being able to add a terrain instance to the viewport frame in order to get a rather low poly view of terrain on the Viewport Frame.
Anywho. The Viewport Frame does have its pros and cons. But at the end of the day it was built to solve a specific problem. It’s not perfect. It could be better. But you can’t really complain about something not working the way you wanted it to when what you’re wanting to do is beyond the use case this feature was built to cater to. Mirrors for instance… is one of those.
Personally I’m still hoping for render texture.
3 Likes