#Refactoring Rendering

1 messages · Page 2 of 1

magic magnet
#

So all the geometry is still staged in java. You still construction the geometry In java but it goes to the rust layer where it's then passed to the gpu

#

Chunkgeometry is just a container for the geometry. We need to stage it in the scene??

#

Tell the renderer we want to render this geometry at this coordinate

charred kiln
#

How will handling rebuilding meshes?

magic magnet
#

you can just request a new resource or do you think we can just update the data in the buffer :?

#

you can in theory just reuse the buffer

charred kiln
magic magnet
#

for now lets say we're lazy and just request a new mesh

#

discard the buffer and the mesh

charred kiln
magic magnet
#

the chunkView can hold a weak refernce

#

once its freed then its dead

#

if we have a scene with chunks that have meshes attached to them.

#

a scene will have one camera for now lets keep it simple i think :?

#

Scene {
Camera
chunkViews
}

#

a chunkView has a mesh and a location to render it in the world

#

the view can have a set method to update the chunk resource

#

the future plan would be to make this all indirect rendering

charred kiln
magic magnet
#

so we need to suballocate into one large buffer

#

lets do that laaater

charred kiln
#

Then current api should looks like:
Scene#addChunk
Scene#removeChunk
Scene#settings - basic rendering settings?
Scene#Camera - return camera api?
ChunkMesh#setTransform
ChunkMesh#updateBuffer

magic magnet
#

chunkMesh also encapsulates its transformation :?

#

I guess that makes sense

#

that's simpler lets go with that

#

we need to index into a uniform buffer

charred kiln
#

Oh. That was mistype :3

magic magnet
#

we don't want to have a buffer per chunk

#

it would be like 60 or so bytes thats a lottt of tiny allocations

#

umm we still need a logger bridge ... 😦

charred kiln
#

Are you suggest bake world meshes at java side and then update it all at once? On every world change?

charred kiln
magic magnet
#

you need to copy the mesh data generated on java side to rust but the actual uniform data will be in one large buffer

#

each chunk view will get an index into one large uniform buffer

#

we can slice it into block per chunk

charred kiln
magic magnet
#

nice

#

we will have the uniform data shared across the board

charred kiln
magic magnet
#

umm for now lets be a little wastful and say we need a new muesh its immutable

#

you can add the API, if you want to

#

just want to get it working then improve

magic magnet
charred kiln
charred kiln
#

@heavy bloom

We try to integrate lowlevel graphics for performace issue.

Current trying - rust lib which using wgpu crate(rust's library)

leaden widget
#

For reference, this my test set-up. Just for comparison.

OS: Windows 10 (21H2)
CPU: Intel i7-6700K
Memory: 16GiB
GPU: Nvidia GeForce RTX 4070

heavy bloom
#

I have two machines, a laptop and a tower

#

Laptop has integreated gpu and tower has a 980ti

#

Windows 11 and 10 respectively

tawny veldt
#

I'm testing on Linux Mint

  Kernel: 6.2.0-31-generic x86_64 bits: 64 compiler: N/A Desktop: Cinnamon 5.4.12 tk: GTK 3.24.33
    wm: Mutter dm: LightDM Distro: Linux Mint 21 Vanessa base: Ubuntu 22.04 jammy
Machine:
  Type: Desktop Mobo: Gigabyte model: B550 AORUS PRO AC v: x.x serial: <superuser required>
    UEFI: American Megatrends v: F2 date: 07/07/2020
CPU:
  Info: 8-core model: AMD Ryzen 7 3700X bits: 64 type: MT MCP arch: Zen 2 rev: 0 cache:
    L1: 512 KiB L2: 4 MiB L3: 32 MiB
  Speed (MHz): avg: 3448 high: 4337 min/max: 2200/4426 boost: enabled cores: 1: 4279 2: 2154
    3: 2151 4: 3887 5: 3576 6: 4331 7: 4337 8: 4297 9: 4125 10: 2200 11: 2164 12: 2200 13: 3521
    14: 3600 15: 4161 16: 4197 bogomips: 114980
  Flags: avx avx2 ht lm nx pae sse sse2 sse3 sse4_1 sse4_2 sse4a ssse3 svm
Graphics:
  Device-1: NVIDIA GP104 [GeForce GTX 1070] vendor: ZOTAC driver: nvidia v: 525.125.06 pcie:
    speed: 8 GT/s lanes: 16 ports: active: none off: DP-1,DP-2 empty: DP-3,DVI-D-1,HDMI-A-1
    bus-ID: 09:00.0 chip-ID: 10de:1b81
  Device-2: Logitech HD Pro Webcam C920 type: USB driver: snd-usb-audio,uvcvideo bus-ID: 3-1.3:6
    chip-ID: 046d:08e5
  Display: x11 server: X.Org v: 1.21.1.4 driver: X: loaded: nvidia
    unloaded: fbdev,modesetting,nouveau,vesa gpu: nvidia display-ID: :0 screens: 1
  Screen-1: 0 s-res: 4480x1440 s-dpi: 122
  Monitor-1: DP-0 pos: bottom-r res: 1920x1080 dpi: 96 diag: 585mm (23")
  Monitor-2: DP-2 pos: primary,top-left res: 2560x1440 dpi: 123 diag: 604mm (23.8")
  OpenGL: renderer: NVIDIA GeForce GTX 1070/PCIe/SSE2 v: 4.6.0 NVIDIA 525.125.06
    direct render: Yes```
magic magnet
leaden widget
#

@tawny veldt is your crash backtrace still the same as #1125142900154564701 message ?

leaden widget
# magic magnet https://youtu.be/QVbOp1h-Jb4?si=INuTuEw-AExzYZ7F

I don't have time to watch a 30 minute video at the moment (but I'm interested when I can find the time to focus). If you don't want to implement a deferred renderer then any other kind is fine, as I believe you replaced the entire rendering loop with the rust library? So you could possibly implement rendering using whatever technique you prefer.

magic magnet
tawny veldt
leaden widget
tawny veldt
#

I rebase the PR onto main, still not working. I see the splash, but not window showing up. Here's another build scan: https://scans.gradle.com/s/duxvlcoq6f6ma

workspace
  engine ts-rusty                          feature/wgpu-ren… 221e454e
libs
     lib TeraRusty                       ± fix/choose_high_… 22de534a```
magic magnet
#

I can look at this on sunday

heavy bloom
#

With my finger broke I’ll be a little slow but should get a chance to look at code later

leaden widget
# tawny veldt I rebase the PR onto `main`, still not working. I see the splash, but not window...

I'm going to try and reproduce this under WSL but, in the meantime, could you possibly provide some even more detailed debug logs? It might be useful in determining why wgpu is doing what it's doing.

GitHub
build: add logger implementation for wgpu logs · MovingBlocks/TeraR...
#

I'll include my logs here for comparison (just in-case anybody else is also looking into it).

📎 game.log
#

[2023-09-11T17:45:27Z INFO wgpu_hal::gles::egl] Unable to open libEGL: Library(LoadLibraryExW { source: Os { code: 126, kind: Uncategorized, message: "The specified module could not be found." } })
This does seem interesting, to be fair. Why is it even trying to load EGL in the first place?

tawny veldt
leaden widget
# tawny veldt there you go

The crash points towards https://github.com/timothee-haudebourg/khronos-egl/blob/4.1.0/src/lib.rs#L961, which implies that the crash is in eglMakeCurrent. I'm not sure why it would be calling that in the first place, since we don't want an GLES/EGL context.

Can we try forcing the Vulkan back-end in wgpu? It might be trying to initialise both and then failing on EGL before it gets a chance to try Vulkan properly.

  • Apply the changes fromhttps://github.com/MovingBlocks/TeraRusty/commit/b84d00acff315e52a82c2a103219e1291d5f089f (or just use the wgpu-force-backend-env branch)
  • export WGPU_BACKEND=vulkan
  • gradlew game
    (It might also be worth trying WGPU_BACKEND=gl for comparison - which certainly should not work.)

I am rather guessing here though. Let me know if I'm wasting too much time.

cedar parrotBOT
# 
Err(self.get_error().unwrap())
tawny veldt
#

whoop whoop!

image.png
#

just in case, logs for
WGPU_BACKEND=vulkan RUST_LOG=debug gradlew --console=plain game > vulkan.log 2>&1

📎 vulkan.log
#

and as expected, does not work with backend GL. Also, logs for reference if needed.
WGPU_BACKEND=gl RUST_LOG=debug gradlew --console=plain game > gl.log 2>&1

📎 gl.log
charred kiln
magic magnet
#

Good that you got that working

heavy bloom
#

So quick question, are we actually tailoring this to just terasology, or should we be steering this to be multi purpose?

#

Imo the effort making multi purpose is huge, and if we tailor to just Terasology we can really squeeze as much performance as we can

rugged olive
#

from my pov it should be just for Terasology - we don't need that kind of rendering for DestSol and we're not going to make another game that would need it anytime soon.
the part that is disputable is the NUI stuff - @leaden widget can you comment on DestSol's needs here if any? if DestSol is fine with the current state and feature set of NUI we could also argue that it sticks to that and Terasology can use whatever the future rendering approach provides. @tawny veldt and I have previously mentored projects in the direction of UI overhauls and would definitely be interested in getting into that, provided the technical foundation exists and is usable.

leaden widget
rugged olive
#

Yes, I was thinking more along the line of - if we invest here for Terasology, would it make sense if it's done in a way that DestSol can benefit too...? After all NUI is a bit buggy and limited in places IIRC (please don't ask for details on that I'd have to refresh my memory first).

That's why I was asking about whether DestSol is fine with the current state and feature set of NUI

leaden widget
#

It gets along. I've seem more offputting bugs from NUI than I'd like but it stil beats the old system by far. The current state of NUI is enough for Destination Sol, even if it has been a bit awkward to work with.

rugged olive
#

Great, then @heavy bloom I'd say: just Terasology in all regards

pseudo compass
#

great job but I'm more impressed by the Gradle glue code you wrote. It all works so seamlessly. I'm working on something similar and I'm the process of converting the groovy scripts from TeraRusty to kotlin kts for my project. Let's see how this goes 😄

rugged olive
pseudo compass
#

Soo I also needed to create jni bindigs of Rust for a personal project of mine thus took a lot of inspiration from TeraRusty and its gradle scripts ultimately converting the groovy scripts into kotlin dsl. If you think you can benefit from this here's my fork. https://github.com/ThanosFisherman/TeraRusty I certainly benefit from kotlin's static typing and IDE support in my gradle scripts.

charred kiln
pseudo compass
rugged olive
hot shoreBOT
#

Gave +1 Slime Tokens to @pseudo compass

pseudo compass
#

PR is up 🙂

rugged olive
hot shoreBOT
#

Gave +1 Slime Tokens to @pseudo compass

pseudo compass
heavy bloom
#

Been giving the rendering a go, things have been slow though so apologies for the lack of communication

tawny veldt
#

@leaden widget did you manage to run Terasology from WSL?

leaden widget
tawny veldt
#

I'm trying to get a minimal setup on my Windows machine so that I can at least compile the projet and test out PRs without rebooting into Linux... thought I'd give WSL another try.
Trying to compile from develop fails because of missing natives I think, so I thought maybe this re-write might work 🤷‍♂️

leaden widget
#

The new renderer can't even load a save game right now, unless it's got further on since I last checked. You might need to enable the WSLg features to get the graphical bits working.

#

develop should be fine? I'll just test that quickly now though.

leaden widget
#

Windows 10 here, it's not just a Windows 11 feature anymore.

tawny veldt
#

hm, I'm puzzled. I am on WSL2, and I don't understand what I need to do in order to enable WSLg