| Age | Commit message (Collapse) | Author |
|---|
|
This allows light sources to be specified in physical light units in addition to the regular energy multiplier. In order to avoid loss of precision at high values, brightness values are premultiplied by an exposure normalization value.
In support of Physical Light Units this PR also renames CameraEffects to CameraAttributes.
|
|
|
|
Fix incorrect Camera3D size documentation
|
|
|
|
|
|
|
|
|
|
|
|
Implement built-in classes Vector4, Vector4i and Projection.
* Two versions of Vector4 (float and integer).
* A Projection class, which is a 4x4 matrix specialized in projection types.
These types have been requested for a long time, but given they were very corner case they were not added before.
Because in Godot 4, reimplementing parts of the rendering engine is now possible, access to these types (heavily used by the rendering code) becomes a necessity.
**Q**: Why Projection and not Matrix4?
**A**: Godot does not use Matrix2, Matrix3, Matrix4x3, etc. naming convention because, within the engine, these types always have a *purpose*. As such, Godot names them: Transform2D, Transform3D or Basis. In this case, this 4x4 matrix is _always_ used as a _Projection_, hence the naming.
|
|
* Added additional information to the camera documentation to explain
how the 'current' attribute behaves when multiple cameras are in a
scene.
|
|
|
|
This allows for lower field of view (or higher zoom) in orthogonal
and frustum camera modes.
The property hint also allows setting the size with greater precision.
|
|
This mentions that internally, the inverse camera projection is used
to perform projections.
|
|
This makes it easier to spot syntax errors when editing the
class reference. The schema is referenced locally so validation
can still work offline.
Each class XML's schema conformance is also checked on GitHub Actions.
|
|
|
|
* Usage was always confusing for users
* The ability to generate a pyramid shape was moved to Camera3D
* SpringArm3D now casts using the camera pyramid shape if no shape is supplied.
|
|
Clarify documentation of Camera3D.get_camera_transform()
|
|
- Back to 1-based layer names to make it clearer in editor UI
- Layer bit accessors are renamed to layer value and 1-based too
- Uniform errors and documentation in render and physics
- Fix a few remaining collision_layer used in place of collision_mask
|
|
For the time being we don't support writing a description for those, preferring
having all details in the method's description.
Using self-closing tags saves half the lines, and prevents contributors from
thinking that they should write the argument or return documentation there.
|
|
This pull request fixes an assortment of typos, improves conciseness, and enhances clarity.
|
|
* there is now a more clear distinction between camera_2d and camera_3d functions in the engine code
* simplified camera2d's exported interface - now everything happens directly with the 'current' variable and make_current and clear_current are no longer exposed- there were some situations where calling one instead of set_current would result in incomplete results
* rebased to current godot master
|
|
|
|
|
|
|
|
|
|
|
|
Renames:
- get_znear() -> get_near()
- set_znear() -> set_near()
- get_zfar() -> get_far()
- set_zfar() -> set_far()
|
|
This makes it possible to view far away objects without
having to tweak any settings. This results in a more usable
editor when working on large-scale levels.
This change should have no impact on performance, but note that
Z-fighting will be visible at a distance. This can be made less
visible by increasing the Znear value (however, doing so will cause
nearby surfaces to disappear).
This change was also applied to the editor, but it will only
apply to newly created scenes.
This also changes the default camera settings in the glTF importer
to match the Camera node's defaults.
|
|
See https://github.com/godotengine/godot/issues/1725.
|
|
|
|
This makes the Camera3D documentation 100% complete.
|
|
A vertical FOV of 75 degrees is roughly equivalent to a 91 degree
horizontal FOV on a 4:3 display (~107.51 degrees on 16:9),
which is close to the typical default FOV used in PC games.
Note that this doesn't apply to the in-editor camera which keeps its
FOV to 70. This is because it doesn't display in fullscreen;
its viewport only displays in the center of the editor (roughly).
This means the viewport won't cover the viewer's eyes as much. Therefore,
the editor camera FOV should be slightly lower to account for this.
Since this changes the default value, this may break existing projects
slightly.
For the record, this was already done in
https://github.com/godotengine/godot-demo-projects/pull/260
for the official demo projects.
|
|
A few extra renames for classes which were missed in last week's PRs.
|