Vertex shader to distort a flat world into a round planet or ring

MirceaKitsune

For a long time I wanted to make entire planets the player can navigate, with other seamless environments like a ring world similar to the first Halo. Merely getting sphere shaped terrain is easy, but everything else makes this not worth it: You need to use "spider physics" to have gravity work not in one axis (-Y) but attract or repel from a world position, this gets very complicated when it comes to properly rotating characters and having pathfinding work too... it's otherwise harder to align stuff accordingly compared to everything being in flat space.

There is a better way though... at least in principle and for other engines, I don't know if this is even theoretically possible in Godot. You can use a vertex shader to distort everything inside a cubic area so that it maps to a cylinder or sphere: This doesn't change the position of objects or even vertices internally, but displaces them on the GPU so from any distance and position you see a normally flat world warped into a sphere / ring / plateau without being able to tell a difference.

The ideal implementation would be something like this: Everything warps around the world center of '0 0 0', the shader takes a scale as the parameter so for example 1000 if you intend your world to be 1000x1000x1000 units. Any point at position X: -1000 will seamlessly connect with everything at position X: +1000... same for other axes if the system can allow it in multiple directions, a flat plane can't be warped into a sphere without cutting or shrinking / expanding some pieces so I doubt it could do a full planet. Obviously the game must separately ensure any entity going below -1000 or beyond +1000 is teleported across the seam without seeing a difference, or that the heightmap terrain is identical across the seam.

Obviously there are a lot of complications that may make this impossible. For instance something that's behind you in flat space might appear in front of you when distorted by the shader, view frustum culling may need to be either disabled unless it can somehow run after the distortion. There's also the issue of things other than geometry such as lights or particles: It's not just every vertice but also every particle that must be moved to the correct location, light sources need to still shine in the correct spot and have their origin offset... sound would be so complicated I'm not even adding that to the list, audio can still work in flat space without much accuracy loss.

xyz

MirceaKitsune Putting regular stuff onto a sphere is simpler. Your idea introduces a lot of additional problems instead of reducing the amount of problems.

MirceaKitsune

xyz Each approach is simpler in some ways but more complex in others, in the end doing it from the real geometry is by far better. The biggest obstacle I remember is that I couldn't find a way to script a player that faces and falls toward an origin point: I had the player oriented to face feet-first toward the planet's center, but when trying to apply gravity in that direction the player would fly off in another spot.

I wonder if there are any basic examples of a character & player movement system (WASD + Jump) with attractive or repulsive spider physics, where gravity can also increase or decrease with distance from the world origin? Same for rigid body or soft body object gravity, I don't remember if by default those have a hardcoded weight fixed to the -Y axis which can be changed.

Also if pathfinding would at least in theory work with this: Does the builtin navigation system allow a navmesh that's agnostic of up / down direction, or would it confuse the equator of the planet with angled slopes? Even if Y axis slopes can be disabled, it should still understand slopes relative to the center of the planet, else NPC's will attempt to climb cliffs that are too tall for them... this would likely require a complete reimplementation of pathfinding; If I manage the rest I may have to settle for dumb AI that just walks toward a target and eventually gets stuck into a wall.

xyz

MirceaKitsune Moving a character body on a sphere surface with proper planetary gravity is not a big deal. It's just some linear algebra and some high school physics calculations.

For rigid bodies, you'd need to apply a gravity impulse each frame, with a direction pointing towards the planet center and a magnitude proportional to the distance. Also no big deal.

Navmeshes don't care about orientation or slopes. They only care about mesh connectivity/topology. You can wrap a navmesh onto a sphere surface without problems.

MirceaKitsune

xyz That's very good to hear, indeed my shader based approach is highly overkill then. Still I remember trying this once and nothing I did got the character to work right: If you or anyone else knows, so I don't open another thread just for this, could you point me to a simple GDScript example please? I just need to see how you properly orient a basic capsule character so their feet always point to '0 0 0' origin, apply gravity relative to that, WASD movement and mouse look working relative to this rotation.

xyz

MirceaKitsune I don't know if there's an exact example of this. I generally don't follow any tutorial content though. There might be something out there, maybe someone else knows.

But imho, if you can't implement this initial setup on your own, you should perhaps start with a less tricky project because things will get even harder as you develop it further.

xyz

MirceaKitsune Ok, here's your example. You owe us at least a small jam game based on this now 😉

extends CharacterBody3D

const SPEED = 5.0
const JUMP_VELOCITY = 4.5
const  GRAVITY = 20.0

var vel_vertical = 0.0


func _input(e):
	if e is InputEventMouseMotion:
		rotate_object_local(Vector3.UP, -e.relative.x * .02) # left-right turn


func _physics_process(delta):
	
	# handle vertical velocity
	if is_on_floor():
		vel_vertical = 0.0
	else:
		vel_vertical -= GRAVITY * delta
	
	# jump
	if Input.is_action_just_pressed(&"ui_accept"):
		vel_vertical = JUMP_VELOCITY
	
	# horizontal movement velocity
	var input_dir = Input.get_vector(&"ui_left", &"ui_right", &"ui_up", &"ui_down")
	velocity = (global_basis.x * input_dir.x + global_basis.z * input_dir.y) * SPEED
		
	# add vertical velocity to final velocity
	velocity += global_basis.y * vel_vertical
	
	move_and_slide()
	
	# orient on sphere
	global_basis.y = global_position.normalized()
	global_basis.x = global_basis.y.cross(global_basis.z)
	global_basis.z = global_basis.x.cross(global_basis.y)
	global_basis = global_basis.orthonormalized()
	# set the up direction so move_and_slide is not confused
	up_direction = global_basis.y

MirceaKitsune

xyz Thank you, I appreciate it! Can't make promises since I tend to start so many projects and rarely finished any, but should at least give it a good try. At least I can hopefully create a dynamic planet with a lot of detail which was my original goal.

xyz

MirceaKitsune You should at least try setting this up now and report back if it works. Otherwise I'll feel I typed this script in vain. Better yet, try to understand how it works.

kuligs2

xyz dont worry, some people will find this usefull!, Thanks

Tomcat

xyz Otherwise I'll feel I typed this script in vain.

What you do is never in vain.

MirceaKitsune

xyz Will do, I should try at least a small project at some point. At very least it will help others looking for answers to this exact question. But obviously I asked because I plan on using it just need to find the right setup with everything else.

xyz

Tomcat What you do is never in vain.

Hopefully 😃

xyz

MirceaKitsune Setting this up would require less effort than typing your original post. Not telling you what to do but since you went to some length to solicit the example code, it'd seem reasonable to at least try to run it.

MirceaKitsune

xyz I plan to. I'm actually thinking what the best way to attempt simulating either a heightmap or voxel planet would be, without having to use one of the terrain plugins which are designed to be flat and most require C# to run: Was thinking of (ab)using CSG spheres but what I'm thinking of would be so slow it will likely just freeze.

xyz

MirceaKitsune How big would that planet be compared to the player?

MirceaKitsune

xyz The plan is to go for acceptable realism, not ridiculously small but obviously not life sized either. If the player is 2m tall, I'd need to have the sphere at very least 1.000 units large and see how that works, after that see if I can push it to 10.000 and beyond.

Obviously it will need some form of LOD, which is harder to do out of square patches for a bent sphere unlike a flat ground, another reason why I initially wanted a deform shader for roundness. Currently my idea is to use noise to add CSG spheres based on camera distance, larger units / spheres and thus lower LOD the further away something is; I still risk having to use thousands of them even so, and to my knowledge the CSG system doesn't like so many items which cause slowness and random tares in the surface.

It would be a lot easier if Godot had a tesselation shader, but as it stands you can't add or remove vertices through GLSL only displace them. There's also collisions: Those can only be calculated on the CPU to my knowledge, you can't have a collision mesh read the displacements from a shader which would have been really amazing.

xyz

MirceaKitsune If the planet is only seen from player's perspective, then there's no point in making it spherical, or at least the sphere can be approximated using planar patches.

MirceaKitsune

I haven't forgotten about this and plan to come back with an example later! I'm first focusing on the most flexible terrain setup and figuring how to get displacement right: Here's my separate question on that, if anyone knows how to set that up I'll take a look at how the player physics script works.

https://godotforums.org/d/40249-displace-vertices-along-normals-on-csg-nodes

MirceaKitsune

Sorry for the delay. I integrated your code with my old player script and am happy to say it works wonderfully! I managed to simplify it a bit so this is the only transform required for the base math:

global_basis.y = global_position.normalized()
global_basis.x = global_basis.y.cross(global_basis.z)
global_basis = global_basis.orthonormalized()

Here's the full player script, it contains more features including distance scaling and inverted gravity for inside-out planets or rings:

extends CharacterBody3D

@export var Sensitivity_X = 0.01
@export var Sensitivity_Y = 0.01
@export var Minimum_Y_Look = -90
@export var Maximum_Y_Look = 90
@export var Accelaration = 100
@export var Decelaration = 25
@export var Air_Accelaration = 50
@export var Air_Decelaration = 5
@export var Jump_Speed = 500
@export var Jump_Jetpack = true
@export var Gravity = 2500
@export var Gravity_Sphere = true

func _ready():
	Input.set_mouse_mode(Input.MOUSE_MODE_CAPTURED)

func _physics_process(delta):
	var input_dir = Input.get_vector(&"ui_left", &"ui_right", &"ui_up", &"ui_down")
	var accel = Accelaration if is_on_floor() else Air_Accelaration
	var decel = Decelaration if is_on_floor() else Air_Decelaration

	# Apply velocity: Gravity, jump, movement, friction
	if not is_on_floor():
		var dist = 1 / (1 + global_position.distance_to(Vector3i(0, 0, 0)))
		velocity -= global_basis.y * abs(Gravity) * dist * delta
	if (Jump_Jetpack or is_on_floor()) and Input.is_action_pressed(&"ui_accept"):
		velocity += global_basis.y * abs(Jump_Speed) * delta
	velocity += (global_basis.x * input_dir.x + global_basis.z * input_dir.y) * accel * delta
	velocity /= 1 + decel * delta
	move_and_slide()

	# Apply sphere orientation, overrides up_direction for move_and_slide to work correctly
	if Gravity_Sphere:
		var dir = +1 if Gravity >= 0 else -1
		global_basis.y = global_position.normalized() * dir
		global_basis.x = global_basis.y.cross(global_basis.z)
		global_basis = global_basis.orthonormalized()
		up_direction = global_basis.y

func _input(event):
	if event is InputEventMouseMotion:
		rotate_object_local(Vector3.DOWN, event.relative.x * Sensitivity_X)
		$PlayerCamera.rotate_x(-event.relative.y * Sensitivity_Y)
		$PlayerCamera.rotation.x = min(deg_to_rad(Maximum_Y_Look), max(deg_to_rad(Minimum_Y_Look), $PlayerCamera.rotation.x))

There is but one issue left, and it would be amazing if anyone could give me a hand with it as well. As can be seen in the image, the atmosphere doesn't rotate with the player when using a PhysicalSkyMaterial, which causes the horizon to tilt and doesn't look realistic from behind: The horizon should always be down from the perspective of the player, the sun should shine from the same direction but moved to the new position on the rotated sky. If I create a script for my WorldEnvironment node to rotate it and its DirectionalLight3D child, what should it contain to get a proper results? It should probably have an offset for specifying the time of day, I could plug the time into it to get a daytime cycle and run it at a different phase for the moon.

xyz

MirceaKitsune
Not sure I understand your environment problem. If you're walking on the surface of a spherical planet the environment could in reality get "tilted" in all kinds of ways. What's the meaning of having a "horizon" in planet's environment anyway? There should only be sun. The actual horizon is planet's contour.

But if you want the environment horizon to align with planet's horizon you'll need to use a custom sky/sun shader. Or do what @Megalomaniak said.

xyz

MirceaKitsune I managed to simplify it a bit so this is the only transform required for the base math:

global_basis.y = global_position.normalized()
global_basis.x = global_basis.y.cross(global_basis.z)
global_basis = global_basis.orthonormalized()

For a bulletproof solution, you need the second cross product as well. The third one in my example was redundant.
The order of cross products the engine does in Basis::orthonormalized() is not guaranteed. So if your code does not ensure orthogonality the whole thing may potentially misbehave.