Forum rules - please read before posting.

Gameplay camera rendering to part of screen (camera viewport rect or render to texture?)

Hi

Older RPGs like Bards Tale showed the world view in a small window on the overall screen.

I would like to do the same with AC. I can think of two ways:

  1. Setting the viewport rect on the main camera dosent work as SetCameraRect() overwrites it. I could force the viewport rect in this method, but I dont know if thats safe/ok. The viewport rect of the attached camera is not copied afaict.
  2. Another option is to use render to texture and display a raw image on the canvas. However Im not sure how to set this up and still use ACs camera system and am worried about mouse clicks and such.

Which do you recommend or is their another option?

Notes:

  • Using a typical AC first person camera which is in the player prefab. Movement method is first person.
  • Settings -> Camera -> Aspect ratio is set to None Enforced.
  • Unity 6.1
  • Latest AC version

Thanks

Comments

  • I'd personally go with a RenderTexture. It wouldn't involve AC's camera system - it would render from a non-AC camera, and be displayed in a UI RawImage component within an AC menu.

    The other option is to use AC's Camera: Split-screen option Action's "Overlay" method, which allows you to render a GameCamera's contents over another. However, if you're using the first-person camera (which is set at runtime), and in need of additional UI elements (e.g. a border / labels around the world view) then I'd say the RenderTexture is the best approach.

  • edited July 13

    Thanks for the response. I already had renter to texture "working", so confirming its the better approach helps.

    I'm having issues with mouse interactions working in the smaller game/raw image window using render to texture.

    My current setup is

    1. Main Camera in Scene (tagged MainCamera, standard AC)
    2. Player Prefab has AC First Person camera off the root with a Unity child camera (more or less the AC default)
    3. Player Prefab has a Unity camera off the root that renders to texture.
    4. Main Scene has a Canvas with a raw image rendering the texture from #3.

    Issues:

    1. The Main Camera in the scene still renders the entire world (full screen). I can "fix" this by either: An opaque image on the UI to hide the background OR set the main camera in the scene's culling mask to Nothing (the culling mask is not copied from the FP camera, maybe intended, might be useful?). Neither of these are ideal but I guess they work. It bothers me that I could be rendering the world twice unless I cull.
    2. The mouse uses the Main Camera viewport for interactions (full screen) meaning the small window that shows the render texture can not use any mouse interactions. For example - a hotspot directly infront of the player (ie center of the screen) requires the mouse in the center of the screen to work. However the raw image is in the top left. Ie interactions use the wrong viewport This is what I mean by "worried about mouse clicks" above. Is there a way to override the viewport to use for raytraces, etc?

    Of these two issues, #2 is significant. Hopefully I'm missing something obvious.

  • I'm not quite clear on your intent. Are you looking to bypass the regular "full screen" in terms of both visuals and interactivity? Or do you want both the regular screen and the inset to be interactable?

    If you can share some mockups/screenshots that illustrate how the game is intended to be presented and played, that would help me understand a lot.

  • Sorry for the confusing terminology. And to be clear, I know exactly why this is happening. I just dont know the AC way to make it work :)

    Setup

    1. The PlayerPrefab has a AC first person camera off the root. This camera is attached to the AC Main Camera. I'm not aware of any difference here from a typical AC First Person setup. Lets call this the game world view.
      Plaeyr-Prefab
    2. I would like the game world view to appear in a smaller section of the screen. So I added added a second non AC camera component child to the first person camera in the player prefab. It is not disabled. It renders to a texture.
      rendertotexturecamera
    3. I added a Canvas with a small Raw Image in the top right that displays the render texture from #2. The rest of the UI is (for now) bricks.

    Here is that example:

    • The treasure chest has a hotspot.
    • The mouse cursor is over the chest but is not detected.
    • While not shown here, assume there will me UI buttons on the screen that need to be interacted with.

    Game-Layout-Render-To-Texture-Mouse-Over

    However if I move the mouse over, it is detected.

    Game-Layout-With-Render-To-Texture

    If I disable the canvas, its clear why the hotspot works in this location as the AC thinks the chest is there.

    Canvas-Disabled

    The above is completely expected. The main AC camera is rendering to a viewport rect of 0,0,1,1 - ie full screen. All the raycasts are done from this camera.
    My 2nd render to texture camera has nothing to do with AC. So its no surprise the hotspot dosent work with the mouse in the inset view - as thats not where the chest really is in screen -> world coords.

    What I would like: AC "world" interactions with the mouse (for things like hotspots) to use the render to texture camera (ie raycast into it).
    However the UI should be fullscreen and not use that camera (obviously the canvas would need to be screen space overlay)

    Notes: With the current setup I can get rid of world mouse interactions (for example making hotspots distance based). This will all work. But not being able to interact in the world with the mouse limits gameplay and I would prefer not to do it.

    Hopefully this all makes sense. :)

  • Also (for reference only) - if I get rid of the render to texture idea and instead modify the AC Main Cameras viewport rect in SetViewPortRect() to render to just the top left quadrant

    Rect newRect2 = new Rect(.025f,.46f,.55f,.48f); ;
    Camera.rect = newRect2;
    

    viewport

    And then draw my UI canvas overtop it "works".

    viewportandcanvas

    But messing with the main camera viewport is far from ideal for many reasons (aspect ratio code, and likely much more)

  • Thanks for the details - that's much clearer.

    Tricky one. You want to override behaviour but only for specific aspects.

    One thing that would be worth trying is to convert the mouse position from "canvas space" to "screen space", so that when the mouse is technically over the chest (in your Canvas), it treats it as being where it would need to be to be detected in screen-space.

    You can do with an input override script.

    See the Manual's "Input remapping" chapter for details, but something along the lines of this would do it (using Unity's legacy Input Manager):

    using UnityEngine;
    using AC;
    
    public class ConverMousePosition : MonoBehaviour
    {
    
        void Start()
        {
            KickStarter.playerInput.InputMousePositionDelegate = My_GetMousePosition;
        }
    
        Vector2 My_GetMousePosition(bool cursorIsLocked)
        {
            var truePosition = Input.mousePosition;
            Rect newRect2 = new (.025f,.46f,.55f,.48f);
            Vector2 screenSize = new(Screen.width, Screen.height);
            Vector2 convertedPosition = new(truePosition.x / newRect2.width + screenSize.x * newRect2.x,
                                            truePosition.y / newRect2.height + screenSize.y * newRect2.y);
            return convertedPosition;
        }
    
    }
    

    This, of course, overrides AC's reading of the mouse position everywhere else as well. You would need to rely on Hardware cursor rendering so that it doesn't place the cursor at the updated position, and also use Unity UI for Menus so that this script doesn't interfere with UI selection.

    There may well be other aspects to deal with, but let's see if the above handles the interaction issue first.

  • TY. Ill look into this. Im using the new input manager as its unity 6.1, but that should be fine

Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Welcome to the official forum for Adventure Creator.