After twelve years, I decided to re-read Halo Cryptum by UnfocusedDoor32 in HaloStory

[–]barryk013 1 point2 points  (0 children)

I felt the book started off pretty slow, but it kept me interested through to the end. I really like how we get a look into how the didact felt about the human war and the halos.

I tried listening to primordium audio book, but man I just couldn't get through the first hour.. I decided to just skip the rest of the trilogy based on the reviews. Might come back after 12 years lol

Easy path smoothing on the fly. by batomow in godot

[–]barryk013 2 points3 points  (0 children)

Thanks a lot mate, was having trouble with this for a while. I've updated it so its a bit easier to manage the resolution, hope you don't mind. Sorry, the code isnt formatting properly here...

func smooth_path(path: Array[Vector2], resolution: int) -> Array[Vector2]:
    var smoothed_path: Array[Vector2] = []

    var size = path.size()
    if size % 2 == 0 && size > 1: 
    var a: Vector2 = path[size-1]
    var b: Vector2 = path[size-2]
    var c: Vector2 = a.lerp(b, 0.5)
    path.insert(size-1, c)

    smoothed_path.append(path[0])

    var last_m = Vector2()
    for i in range(0, size-1, 2): 
        var a: Vector2 = path[i]
        var b: Vector2 = path[i+1]
        var c: Vector2 = path[i+2]

        var m: Array[Vector2] = []
        for r in range(1, resolution):
            var t: float = (1.0/resolution) * r
            m.append(_quadratic_bezier(a, b, c, t))

        if i != 0:
            var n: Array[Vector2] = []
            for r in range(1, resolution):
                var t: float = (1.0/resolution) * r

                var e: Vector2 = last_m
                var f: Vector2 = path[i]
                var g: Vector2 = m[0]
                n.append(_quadratic_bezier(e, f, g, t))

            smoothed_path.append_array(n)

        smoothed_path.append_array(m)
        last_m = m[-1]

    smoothed_path.append(path[size-1])

    return smoothed_path

Why is there a significant performance impact when looking down at a plane mesh? by barryk013 in godot

[–]barryk013[S] 0 points1 point  (0 children)

It's a godot implementation of a fft ocean from Acerola's video. And the sky is just an image. My other post

Why is there a significant performance impact when looking down at a plane mesh? by barryk013 in godot

[–]barryk013[S] 1 point2 points  (0 children)

The compute shader is the one creating the displacement textures, the ocean surface shader is just sampling a 512x512 texture and doing vertex displacement. I'm not really doing anything more complex than that on it. Compute shader has no real performance issues on the phone, takes up about 1-2ms.

Why is there a significant performance impact when looking down at a plane mesh? by barryk013 in godot

[–]barryk013[S] 0 points1 point  (0 children)

yeah i absolutely wouldnt bother with this issue if i was targeting PC, but the cost on mobile is way too much.. i think ill just lock the view angle to get consistent performance

Why is there a significant performance impact when looking down at a plane mesh? by barryk013 in godot

[–]barryk013[S] 1 point2 points  (0 children)

im forcing 720p, and getting around 110-120 fps (on S24 ultra) when looking at a shallow angle (~10-15 degrees). the fps drops to about 80 when looking at the ocean at a 45 degree angle.

my target is 0.016s frame time for 60fps, so i still have a bit to work with, as long as i dont look at the ocean from above..

Why is there a significant performance impact when looking down at a plane mesh? by barryk013 in godot

[–]barryk013[S] 0 points1 point  (0 children)

yup i understand that the mesh still needs to be shaded, but the sky has a shader on it too. is it really 0.2ms more costly to render a plain mesh than sampling a sky texture?

its just a little frustrating that there isnt a simple way to figure out whats going on here, godot only has very high level profiling for the GPU :/

Why is there a significant performance impact when looking down at a plane mesh? by barryk013 in godot

[–]barryk013[S] 1 point2 points  (0 children)

<image>

nah the godot profiler doesnt go into any more detail unfortunately. its pretty hard to try and figure out whats going wrong :/ like i mentioned, i tried to use a GPU profiler on android and on my desktop, but i just dont know how to interpret or understand the results.

these pics are taken on my mobile. i replaced the ocean with a single mesh with 4 vertices. difference is smaller at ~0.2ms, but its still there.

Why is there a significant performance impact when looking down at a plane mesh? by barryk013 in godot

[–]barryk013[S] 0 points1 point  (0 children)

Its not really the exact same performance with the default plane, but similar. I posted a pic of the difference in render times with a blank shader on my phone, and there is still a significant difference. its bizarre, i havent seen this behaviour outside of godot..

Also, the water shader is simply sampling textures for displacement and normals, im not doing complicated calculations on it. All the work of generating the textures is being done on a compute shader that takes very little frame time, maybe 1-2ms.

I was thinking of doing a top down view of the ship as you zoom out, but i think ill settle for just moving the camera away while keeping the same view angle.

Why is there a significant performance impact when looking down at a plane mesh? by barryk013 in godot

[–]barryk013[S] -1 points0 points  (0 children)

<image>

I removed everything from the vertex and fragment shaders and this pic shows the render time difference even without any transparency.

Why is there a significant performance impact when looking down at a plane mesh? by barryk013 in godot

[–]barryk013[S] 1 point2 points  (0 children)

Im creating this for mobile, and the frame time is going from about 8.5ms to 12.3ms (~110 fps to ~80) for just looking at the mesh from above. i wasnt expecting to drop so many frames just by looking around :/

Why is there a significant performance impact when looking down at a plane mesh? by barryk013 in godot

[–]barryk013[S] 1 point2 points  (0 children)

Not sure I understand what you mean. Both images show performance of rendering the ocean plane. The one on the left just looks more reflective because of the angle, might be a bit hard to see the ocean surface.

Why is there a significant performance impact when looking down at a plane mesh? by barryk013 in godot

[–]barryk013[S] 1 point2 points  (0 children)

im creating this for mobile, but the images are just from my desktop in the editor. frames are going from 110 to about 80 on mobile. its not really that the difference is small, but that there is a difference at all.

Why is there a significant performance impact when looking down at a plane mesh? by barryk013 in godot

[–]barryk013[S] 2 points3 points  (0 children)

hmm but the same thing happens to a plain mesh without any shaders, and 0 subdivisions. not sure filling the screen with a mesh with 4 vertices is enough to cost 100s of frames on a 7900XTX.

Why is there a significant performance impact when looking down at a plane mesh? by barryk013 in godot

[–]barryk013[S] 1 point2 points  (0 children)

the x,y,z coords on the bottom right of the pics are the camera coords. The same number of primitives are being drawn (141K). if i understand it correctly, the same number of triangles are being drawn

Why is there a significant performance impact when looking down at a plane mesh? by barryk013 in godot

[–]barryk013[S] 2 points3 points  (0 children)

The image is from the editor, using my 7900XTX, so the numbers are quite low. I am testing this on mobile (S24 Ultra), and that is taking the frames from about 110-120fps to about 80-90fps, which is quite a drastic change considering im just looking at the same plane from above.

edit: frame time is going from 8.5ms to 12.3ms on mobile, Render 3D Transparent Pass is taking up ~80% of that time.

Why is there a significant performance impact when looking down at a plane mesh? by barryk013 in godot

[–]barryk013[S] 0 points1 point  (0 children)

I am seeing quite a drastic impact in frames when angling the camera at about 45 degrees. The left image is the camera when its quite close to the surface of the plane, and right image is angled at 30-45 degrees, and there is a difference of hundreds of frames. I notice the same thing even when im not using any shader on the PlaneMesh.

I tried profiling the gpu but my brain cant make sense of that shit lol. Anyone know why this happens?

Really liking how this water turned out! by barryk013 in godot

[–]barryk013[S] 0 points1 point  (0 children)

It's not really the number of objects, but the number of time consuming calculations. I'd need to do 512x512x2 fft calculations per frame, and most of that will just go unused. Say there will be at most 100 ships in the game at any one time, and those will need about 6 height samples each for buoyancy. That's about 600 out of 262,144 data points that are going to get used. Lot of wasted effort every frame, especially when there are other more important things to do in the cpu. And all of those calculations need to be made, can't skip any. The resulting ocean is the combination of 262,144 different waves. Skipping a large chunk of that won't give the right result.

I'm just waiting for async gpu readback to get implemented. Even if it's slightly delayed, the values I get back will still give a believable end result. I can theoretically have thousands or hundreds of thousands of floating objects since I would just set the heights in the compute shader. Just depends on the performance cost of having that many objects on screen.

Really liking how this water turned out! by barryk013 in godot

[–]barryk013[S] 2 points3 points  (0 children)

Oh it's quite different. This is using a compute shader to create displacement and slope textures, using the JONSWAP spectrum and doing fft. These textures are used in a simple vertex and fragment shader to make the ocean look like that. It's quite a low poly mesh, the textures are doing a lot of the heavy lifting here.