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:
- 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.
- 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.
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
Issues:
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
Here is that example:
However if I move the mouse over, it is detected.
If I disable the canvas, its clear why the hotspot works in this location as the AC thinks the chest is there.
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
And then draw my UI canvas overtop it "works".
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):
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