As a roblox developer, it’s currently impossible to have two camera objects displaying their input on the screen at once. I think it would be cool to introduce a UI Element that receives the input of a camera in the workspace.
This might require making a type of Camera that’s not local, due to multiple scripts needing access to the same camera (security cameras, spectating, etc.)
Basically, my idea is to take a Frame object, and put the input from a camera object on it so a player can see out of
A) Their main camera
B) The other camera
This would be useful for making things like:
sercurity camera footage that’s in the corner of your screen
A top-down minimap
A way to add mirrors/reflective surfaces to look around corners
Newsstands that stream newscasts being put on by players in a studio onto a TV
I could probably think of a lot more but I’ll leave that to the comments.
I think Roblox lacks easy ways to make this stuff happen, and by adding a “Viewport” UI object, it would improve the User Interface and allow for a lot more possibility.
As a side note - adding Orthographic cameras would be very useful too to help with the minimap idea
Thanks!
-big
I like this idea of the cameras.
I think this idea is cool, but a waste of time.
I don’t like this idea.
This idea is cool, but not necessary to development.
This was done as a hack week project very recently, but I want to point out a few reasons we haven’t done this yet:
It will be very, very easy to over-use these viewports and ruin mobile performance. Minimaps are a particularly wasteful example because it’d be far more performance efficient to just make a top-down render of your map and upload it as a decal.
This is not an ideal way to implement mirrors.
TVs streaming these viewports are an example of abuse that will destroy mobile performance.
There are tradeoffs involved like whether to render to a texture or not.
The LOD system will have to take multiple viewports into consideration.
There are many other usecases for controlling where and how 3D objects render which aren’t covered by this idea:
Objects that aren’t in the workspace, so that you don’t have to hide things under the map or whatever
3D objects placed over top of 2D UI. These need to have an orthographic view and very specific lighting.
This may end up happening anyway, but it definitely comes with strings attached.
In terms of mobiles, developers should think about their usage of this sort of stuff and the impact of proformnance.
In terms of general proformnance, maybe have streaming options per say that could be controlled by the player and/or developer, it is all about those options for how you want to do something.
Most of the games being developed will never be released on mobile; I think that when inserting something like a Viewport or a Surface Projection, there should be a warning show up, and mention to the developer that the instance might not work well on mobile; the developer can choose whether they want to take the risk or not. The game engine isn’t the only thing that optimizes games. Developers who plan out their games usually take measures to ensure that it runs smoothly on target devices.
As for orthographic cameras, I think they should definitely be a thing. That’s because they would open up a whole new window of opportunity - top down games. Top-down games could be really useful. Think Pokémon, and you’ll get what I’m saying.
I think the hard part for developers comes when they insert a free model from the library. We’ve got no idea how many triangles a mesh has, or what kind of performance a model’s going to give us. I think a nice thing to have (though I don’t really want to make an entirely separate thread for it) would be a performance statistic at the bottom of the model when it’s listed, so we don’t even have to insert it to know how it’ll do.
Roblox has something to lose when you say that. A good chunk of the playerbase is on mobile. Granted, they are 9 year olds on iPads waiting for a doctor’s appointment, but they buy Robux regardless. Mobile has to be of some concern when pushing features like this.
This is essentially part of the concept of RT Cameras / in-game screens, which have been requested before if you want to hear older feedback on the topic. As Tiffblocks stated, complex uses such as mirrors and realtime minimaps may not be feasible, but I’d love to have a viewport object just for screens and a few optical effects. I can attest that we already have a lot of mobile-unfriendly things anyway and devs still make popular games with them. Really hope Roblox might consider this feature beyond its outstanding issues someday.
@Tiffblocks is there a place to view that hackweek project by chance?
I have more use cases in case we need better reasons that can only be done with this feature request: live video / surveillance system, portal / loading zone illusion, defraction effect (mirrors are easier this way / realistic reflective textures) and don’t forget a second half of the screen camera for 2player online team or puzzle games / storyline games.
I think it’s important to not underestimate how far you can get without using UI viewport objects. Other than the case of split screen play, for most of these use cases you don’t even need viewport objects to get the desired visual feel.
Even AAA titles often use tricks to avoid needing such objects. I think it’s important to consider that a large portion of the games that have ever been published commercially have had no need for viewports like this. Even when they do require the use of viewports, they either use them as minimally as possible, or stop using them on lower graphics settings, because of how much of a performance impact they have. For example, in Portal 2 you can never have more than 4 viewport objects present on the screen at a time, and there is a configurable option in the settings for how many times they should “recurse” (i.e. how many layers of portals you can see through).
As an example, you can do a surveillance system pretty convincingly without viewports.
For the in-world model of the security console, make each CRT be a surface gui that each has a single decal scanning back and forth. If you look at many older AAA titles you’ll notice this is exactly what they do. For example, most TVs in Half Life 2 are either combinations of simple moving/tiling textures, or a few seconds long video clip. If you do it this way, it will require more work in building assets, but it will have much less of a performance impact on your players while still giving a convincing feel to your world.
When you approach the console, you’re provided the option to interact with it and begin examining individual cameras (an option that you would want regardless - having to manually wrangle the camera to look at a specific screen would be poor UX). This option makes you enter a mode with a decal overlaid on the screen which is a CRT with a cutout where the screen should go. You may even wish to add a ColorCorrectionEffect effect in order to make it display in black and white and otherwise look like a bottom of the barrel security camera from 1985. Then you position the real world camera to where the security camera is supposed to go. Then you have some sort of buttons to switch cameras or exit the camera viewing mode.
Most games I’ve played which have security camera systems do this. There are a few exceptions, though. Deus Ex: Mankind Divided (2016) has a completely static prop (a laptop computer) which you interact with, opening a fullscreen GUI that presents you with the cameras. You have one “main” view, and then several live updating thumbnails that are something like 100x60 pixels across.
This is true but largely because of the fine for importing audio.
@HadenTheCreeper@Tiffblocks
Anyways, to stay on topic, I see your point in that viewports won’t be needed for small things like a prop security TV, but what about the fact that roblox still doesn’t have video support? Also, the sounds picked up by a viewport camera in the workspace would have to be imported for a price. To be honest, I don’t know my video formats, but if there’s a format fast enough to contain compressed video up to a minute or something, that would be very ideal. Also, preferably video and sound assets could be loaded separately at no additional cost? An idea would be that the “Movie” asset contains an input for “gif” and “sound” assets and plays them at the same time.
That reminded me of a feature I’ve been wanting for a very long time now: the ability to take screenshots (with a script) and use them in-game on a decal or SurfaceGui.
Half Life 2 actually features real-time output from a camera outside of the playzone, and is displayed on the screen, at no cost to performance. Portal and Portal 2 also duplicate the chambers multiple times over (depending on the setting you put the game to) and then cuts a hole where a portal is placed, which could be why Portal and Portal 2’s performance takes a dip when you max out the portal setting.
I’m pretty sure that if you were to take the GMan TV in HL2 and dupe it many times over in Hammer, it wouldn’t affect performance any (taking into account that the surface the TV is displaying on is curved.) But that could just be the way Source is programmed and optimized.
Overall, I feel that extra viewport cameras wouldn’t be that much of a performance hit, as a lot of games do use them, at least Source-Engine games do. There’s also an Android port of HL2 that has the camera system still, and it still runs perfectly fine (albeit on hardware that’s about 4-5 years old.) Not to mention HL2 runs perfectly fine on older hardware, that by today’s standards, would be considered mediocre.
Creating extra assets to create the “illusion” of a security system or live feed of any kind wouldn’t be sufficient, and quite expensive, depending on how many assets you need to upload.
Yea I saw the new object but I kinda want to just make sure it’s actually the right thing before I mark a solution - I couldn’t get the viewportFrame object to work yet so I think I’m gonna wait
An idea would be that the “Movie” asset contains an input for “gif” and “sound” assets and plays them at the same time.