diff --git a/doc/base/classes.xml b/doc/base/classes.xml index 91c1c72ff58..ea74007482b 100644 --- a/doc/base/classes.xml +++ b/doc/base/classes.xml @@ -2216,32 +2216,40 @@ + Anchor point in AR Space + The ARVR Anchor point is a spatial node that maps a real world location identified by the AR platform to a position within the game world. For example, as long as plane detection in ARKit is on, ARKit will identify and update the position of planes (tables, floors, etc) and create anchors for them. + This node is mapped to one of the anchors through its unique id. When you receive a signal that a new anchor is available you should add this node to your scene for that anchor. You can predefine nodes and set the id and the nodes will simply remain on 0,0,0 until a plane is recognised. + Keep in mind that as long as plane detection is enable the size, placing and orientation of an anchor will be updates as the detection logic learns more about the real world out there especially if only part of the surface is in view. + Returns the anchor id for this anchor. + Returns the name given to this anchor. + Returns true if the anchor is being tracked and false if no anchor with this id is currently known. + Returns the estimated size of the plane that was detected. Say when the anchor relates to a table in the real world, this is the estimated size of the surface of that table. @@ -2250,6 +2258,7 @@ + Binds this anchor node to an anchor with this id. You can set this before the anchor itself exists. The first anchor that is identified gets id 1, the second id 2, etc. When anchors get removed that slot remains free and can be assigned to the next anchor that is identified. The most common situation where anchors 'disappear' is when the AR server identifies that two anchors represent different parts of the same plane and merge them. @@ -2262,8 +2271,11 @@ + A camera node with a few overrules for AR/VR applied such as location tracking. + This is a helper spatial node for our camera, note that if stereoscopic rendering is applicable (VR-HMD) most of the camera properties are ignored as the HMD information overrides them. The only properties that can be trusted are the near and far planes. + The position and orientation of this node is automatically updated by the ARVR Server to represent the location of the HMD if such tracking is available and can thus be used by game logic. Note that in contrast to the ARVR Controller the render thread has access to the most up to date tracking data of the HMD and the location of the ARVRCamera can lag a few milliseconds behind what is used for rendering as a result. @@ -2272,26 +2284,33 @@ + A spatial node representing a spatially tracked controller. + This is a helper spatial node that is linked to the tracking of controllers. It also offers several handy pass throughs to the state of buttons and such on the controllers. + Controllers are linked by their id. You can create controller nodes before the controllers are available. Say your game always uses two controllers (one for each hand) you can predefine the controllers with id 1 and 2 and they will become active as soon as the controllers are identified. If you expect additional controllers to be used you should react to the signals and add ARVRController nodes to your scene. + The position of the controller node is automatically updated by the ARVR Server. This makes this node ideal to add child nodes to visualise the controller. + Returns the controller id currently assigned to this node. + If active, returns the name of the associated controller if provided by the AR/VR SDK used. + Returns true if the controller bound to this node is currently active and being tracked. @@ -2300,12 +2319,14 @@ + Returns the value of the given axis for things like triggers, touchpads, etc. that are embedded into the controller. + Returns the ID of the joystick object bound to this. Every controller tracked by the ARVR Server that has buttons and axis will also be registered as a joystick within Godot. This means that all the normal joystick tracking and input mapping will work for buttons and axis found on the AR/VR controllers. This ID is purely offered as information so you can link up the controller with its joystick entry. @@ -2314,6 +2335,7 @@ + Is the given button currently pressed? @@ -2322,6 +2344,7 @@ + Changes the id that identifies the controller bound to this node. The first controller that the ARVR Server detects will have id 1, the second id 2, the third id 3, etc. When a controller is turned off that slot is freed ensuring that controllers will keep the same id while it is turned on even when controllers with lower ids are turned off. @@ -2334,12 +2357,14 @@ + When a button on this controller is pressed, this signal is given. + When a button on this controller is released, this signal is given. @@ -2348,50 +2373,64 @@ + Base class for ARVR interface implementation. + This class needs to be implemented to make an AR or VR platform available to Godot and these should be implemented as C++ modules or GDNative modules (note that for GDNative the subclass ARVRScriptInterface should be used). Part of the interface is exposed to GDScript so you can detect, enable and configure an AR or VR platform. + Interfaces should be written in such a way that simply enabling them will give us a working setup. You can query the available interfaces through ARVRServer. + Returns the name of this interface (OpenVR, OpenHMD, ARKit, etc). + Returns the resolution at which we should render our intermediate results before things like lens distortion are applied by the VR platform. + Returns true if an HMD is available for this interface. + Call this to initialize this interface. The first interface that is initialized is identified as the primary interface and it will be used for rendering output. + After initializing the interface you want to use you then need to enable the AR/VR mode of a viewport and rendering should commence. + Note that you must enable the AR/VR mode on the main viewport for any device that uses the main output of Godot such as for mobile VR. + If you do this for a platform that handles its own output (such as OpenVR) Godot will show just one eye without distortion on screen. Alternatively you can add a separate viewport node to your scene and enable AR/VR on that viewport and it will be used to output to the HMD leaving you free to do anything you like in the main window such as using a separate camera as a spectator camera or render out something completely different. + While currently not used you can activate additional interfaces, you may wish to do this if you want to track controllers from other platforms. However at this point in time only one interface can render to an HMD. + Returns true if this interface is active. + Returns true if this interface has been installed. Say your game is designed to work with OpenVR so you are using the OpenVR interface but the user hasn't installed SteamVR, this would return false. + Returns true if this interface is currently the primary interface (the interface responsible for showing the output). @@ -2400,18 +2439,21 @@ + Set this interface to the primary interface (unset the old one). + Returns true if this interface supports HMDs and by extension uses stereo scopic rendering. + Turns the interface off. @@ -2421,23 +2463,32 @@ + Mono output, this is mostly used internally when retrieving positioning information for our camera node or when stereo scopic rendering is not supported. + Left eye output, this is mostly used internally when rendering the image for the left eye and obtaining positioning and projection information. + Right eye output, this is mostly used internally when rendering the image for the right eye and obtaining positioning and projection information. + Our origin point in AR/VR. + This is a special node within the AR/VR system that maps the physical location of the center of our tracking space to the virtual location within our game world. + There should be only one of these nodes in your scene and you must have one. All the ARVRCamera, ARVRController and ARVRAnchor nodes should be direct children of this node for spatial tracking to work correctly. + It is the position of this node that you update when you're character needs to move through your game world while we're not moving in the real world. Movement in the real world is always in relation to this origin point. + So say that your character is driving a car, the ARVROrigin node should be a child node of this car. If you implement a teleport system to move your character, you change the position of this node. Etc. + Get the world scale applied to our positioning. @@ -2446,6 +2497,9 @@ + Changes the world scaling factor. + Most AR/VR platforms will assume a unit size of 1 unit in your game world = 1 meter in the real world. This scale allows you to adjust this to the unit system you use in your game. + Note that this method is a passthrough to the ARVRServer itself. @@ -2458,44 +2512,54 @@ + A tracked object + An instance of this object represents a device that is tracked such as a controller or anchor point. HMDs aren't represented here as they are fully handled internally. + As controllers are turned on and the AR/VR interface detects them instances of this object are automatically added to this list of active tracking objects accessible through the ARVRServer + The ARVRController and ARVRAnchor both consume objects of this type and should be the objects you use in game. The positional trackers are just the under the hood objects that make this all work and are mostly exposed so GDNative based interfaces can interact with them. + If this is a controller that is being tracked the controller will also be represented by a joystick entry with this id. + If available this returns the name of the controller or anchor point. + Returns the orientation matrix of the controller. + Returns the position of the controller adjusted by world scale. + Returns true if the orientation of this device is being tracked. + Returns true if the position of this device is being tracked. @@ -2504,12 +2568,14 @@ + Returns the transform combining the orientation and position of this device. + Type of tracker. @@ -2518,14 +2584,17 @@ + Base class for GDNative based ARVR interfaces. + This class is used as a base class/interface class for implementing GDNative based ARVR interfaces and as a result exposes more of the internals of the ARVR server. + Should return the projection 4x4 matrix for the requested eye. @@ -2536,12 +2605,14 @@ + Outputs a finished render buffer to the AR/VR device for the given eye. + Returns the size at which we should render our scene to get optimal quality on the output device. @@ -2552,54 +2623,63 @@ + Get the location and orientation transform used when rendering a specific eye. + Return true is an HMD is available. + Initialize this interface. + Returns true if this interface has been initialized and is active. + Returns true if the required middleware is installed. + Returns true if we require stereoscopic rendering for this interface. + Gets called before rendering each frame so tracking data gets updated in time. + Returns true if this interface supports HMDs. + Turn this interface off. @@ -2608,8 +2688,10 @@ + This is our AR/VR Server. + The AR/VR Server is the heart of our AR/VR solution and handles all the processing. @@ -2618,6 +2700,7 @@ + Mostly exposed for GDNative based interfaces, this is called to register an available interface with the AR/VR server. @@ -2626,6 +2709,7 @@ + Find an interface by its name. Say that you're making a game that uses specific capabilities of an AR/VR platform you can find the interface for that platform by name and initialize it. @@ -2634,18 +2718,21 @@ + Get the interface registered at a given index in our list of interfaces. + Get the number of interfaces currently registered with the AR/VR server. If you're game supports multiple AR/VR platforms you can look throught the available interface and either present the user with a selection or simply try an initialize each interface and use the first one that returns true. + Gets our reference frame transform, mostly used internally and exposed for GDNative build interfaces. @@ -2654,18 +2741,21 @@ + Get the positional tracker at the given ID. + Get the number of trackers currently registered. + Returns our world scale (see ARVROrigin for more information). @@ -2674,16 +2764,28 @@ + Removes a registered interface, again exposed mostly for GDNative based interfaces. + If true we ignore the tilt of the device and we don't reset the tilt. This means that when the player is looking down we don't counter this and the player will still look down in game. If this is false the player will look straight ahead even when looking down. + The direction in which the player looks is centered so the player looks to negative Z regardless of where the player is looking in the real world. + This is a really important setting. When true we keep the height information given by our tracking. + You should set this to true when you are using room scale tracking and want your player to freely walk around the room, be able to crouch, etc. Your ARVROrigin should be placed on the floor of your scene in this scenario. + You should set this to false in all other situations. The current location of the HMD will become your 0,0,0 location and you should place your ARVROrigin point where your player currently is positioned. Use this when room scale is not available or when your making a driving or flying sim and you want to ensure the HMD is centered in your cockpit. + This is a really important function to understand correctly. AR and VR platforms all handle positioning slightly differently. + For platforms that do not offer spatial tracking our origin point (0,0,0) is the location of our HMD but you have little control over the direction the player is facing in the real world. + For platforms that do offer spatial tracking our origin point depends very much on the system. For OpenVR our origin point is usually the center of the tracking space, on the ground. For other platforms its often the location of the tracking camera. + This method allows you to create a reference frame, it will take the current location of the HMD and use that to adjust all our tracking data in essence realigning the real world to your players current position in your game world. + For this method to produce usable results tracking information should be available and this often takes a few frames after starting your game. + You should call this method after a few seconds have passed, when the user requests a realignment of the display holding a designated button on a controller for a short period of time, and when implementing a teleport mechanism. @@ -2692,6 +2794,7 @@ + Changes the primary interface to the specified interface. Again mostly exposed for GDNative interfaces. @@ -2700,6 +2803,7 @@ + Changing the world scale, see the ARVROrigin documentation for more information. @@ -2712,12 +2816,14 @@ + Signal send when a new interface has been added. + Signal send when an interface is removed. @@ -2726,27 +2832,35 @@ + Signal send when a new tracker has been added. If you don't use a fixed number of controllers or if you're using ARVRAnchors for an AR solution it is important to react to this signal and add the appropriate ARVRController or ARVRAnchor node related to this new tracker. + Signal send when a tracker is removed, you should remove any ARVRController or ARVRAnchor points if applicable. This is not mandatory, the nodes simply become inactive and will be made active again when a new tracker becomes available (i.e. a new controller is switched on that takes the place of the previous one). + Our tracker tracks the location of a controller. + Our tracker tracks the location of a base station. + Our tracker tracks the location and size of an AR anchor. + Used internally if we haven't set the tracker type yet. + Used internally to filter trackers of any known type. + Used interally to select all trackers. @@ -57579,6 +57693,10 @@ + If true this viewport will be bound to our ARVR Server. + If this is our main Godot viewport our AR/VR output will be displayed on screen. + If output is redirected to an HMD we'll see the output of just one of the eyes without any distortion applied else we'll see the stereo buffer with distortion applied if applicable + If this is an extra viewport output will only work if redirection to an HMD is supported by the interface. The render target will allow you to use the undistorted output for the right eye in the display. @@ -57635,6 +57753,7 @@ + Returns whether this viewport is using our ARVR Server