BZ-Next: A modern OpenGL BZFlag client

[bz_next]

(Watch the development progress here: https://bz-next.github.io/)

I didn't want to post this in the development subforum since it's not really related to official dev activities.

I'm hacking on the bzflag codebase to try to make some sort of client that can render stuff with modern OpenGL.

[bz_next]

New demo: working chat console with imgui, and instanced rendering of identical boxes and pyramids

https://i.imgur.com/WdQk8uI.png

[Zehra]

I usually write quite lengthy posts, but to summarize my thoughts:
@guyfox2, I am very much impressed, you've done extremely excellent work. I am certain that very few truly appreciate or realize the scale and potential of it.

I personally believe that it's very possible that it may supersede BZFlag's 3.0 attempts at visuals, as your work is light years ahead of the technology currently used.(For reference API documentation and how even 2010 OpenGL is light years ahead of what BZ currently has.)

I am nearly certain that even the true potential of drawInfo may be unlocked as well.

-Zehra

[bz_next]

Some more progress, working scoreboard and global auth.

https://i.imgur.com/H2rsRTq.png

The imgui UI can be useful as a dev UI for working on this project further.

[bz_next]

Texture previewing, material viewer and material manager debug UI added.

The material viewer will eventually apply all the material attributes to the render preview. The viewer uses custom fragment and vertex shaders that get compiled into the app. Currently, the shader just combines the texture with the diffuse color, but the sky's the limit with what can be done in terms of material rendering.

https://i.imgur.com/Epcf41V.png

[bz_next]

I have a rendering setup now that seems to support all the major material properties in BZ:

- Ambient, diffuse, specular, emission colors
- Shininess
- Alpha threshold (haven't really tested this but it's supported by the shader)
- Diffuse texture
- Texture alpha
- Texture matrix
- Dynamic color

https://i.imgur.com/b9k8iVN.png

[bz_next]

I have a basic mesh compiler working now. The idea is to build a single mesh / bzflag material, so the number of render calls is roughly on par with the number of materials in the scene.

I've tested this idea with boxes on a map, and it seems to work. Next is to implement geometry generators for the other world objects so they can be added to the combined material meshes.

https://i.imgur.com/Z27RCTx.png

[bz_next]

The renderer supports all the classic objects now, mesh support is next.
I've tried to make it as true to the original as possible for now.

Notably, it should be much, much faster than the current codebase, since it emits only one render call per assigned material, so only a handful of render calls to draw the entire map.


https://i.imgur.com/BDPnwJE.png

[bz_next]

Mesh support is basically complete, here's a cool screenshot of Louman's churchyard in the new client, connected to a server, with some ImGui dev tools open as well.

https://imgur.com/a/6FA1uXi

In its current state, this code could be used as the basis for a really full featured map editor.

[bz_next]

Drawinfo support should be around 90% working now, with the exception of angvel. I also think that normals need to be transformed in certain cases.

I got a hacky mingw cross compile working with cmake to compile a windows build from Linux. I need to document it and make it proper in the cmake. (Setting up cross compilers is a pain, even with docs).

There's also some general TLC to do on the code before moving on to rendering tanks/shots.

[bz_next]

I've made a website for this project, I'll update it as I work through cleaning up the project while preparing for the next phase of dev.

https://bz-next.github.io/

[bz_next]

There's a windows test build available at https://github.com/bz-next/bz-next/releases

Note that you may need to add an antivirus exception, as Windows seems trigger-happy in flagging anything built with MinGW as a potential virus. Instructions at the link.

You may also want to edit your DownloadAccess.txt to allow all images while running the client, since if it cannot download all resources, it will print lots of debug messages and lag.

There are also instructions for building on Linux at https://bz-next.github.io/building/ if you want to try it out.

[macsforme]

I am intrigued by this project. I have also created various basic rendering prototypes over the years (which you may see on the forums), but this seems to be more ambitious and to have a more clear direction. I plan to follow your progress.

One question I have (which is something I've pondered in case we were to do an official rewrite from scratch) is how do you plan to do geometry culling? From my limited knowledge of it, our existing code seems modeled after the "scene graph" paradigm (similar to the rendering engine OpenSceneGraph), but I have heard of other methods (such as the portal method). I believe we also have some ancient BSP tree stuff as well, which may have been more applicable to software rendering. Given our relatively low polygon counts (versus other games), another viable option may be simply to render everything and do no culling, and let the GPU automatically cull geometry outside the view frustum, although this obviously comes with some tradeoffs/limitations. In any case, I am curious how you do this or how/if you are planning to.

[bz_next]

My current plan is to just let the GPU do culling, since that is extremely fast for scenes with a few million vertices, and even the most pathological BZ maps currently are way under that. (The most vertices I've seen in a map was GEP's field of flowers, will all max LOD, at around 7-8 million vertices, and even that doesn't cause a strain).

If it's needed, I think it'd be best to do BSP generation and culling based on the compiled geometry of the scene, rather than per-object anyway. That way, everything could be treated uniformly, instead of spread all over the code. But it's not a priority towards getting things playable, since the current proof of concept already achieves framerates in excess of BZ in many pathological cases.

[bz_next]

The experimental client now has basic support for GLES2, an embedded flavor of OpenGL that is more common on things like phones and embedded PCs. It's a good minimum target to support.

Thank you @blast for your help testing the GLES2 support!

Next up is to try to factor out a basic map viewer app, and see if I can get it built for webgl2. If that works, I could host a pretty full-featured map viewer at https://bz-next.github.io and it could be used as the basis for a map editor in the future.

[bz_next]

@blast was able to build and run the current development version of the BZ-Next client on a Librem 5 linux phone:

https://bz-next.github.io/2024-02-05-Librem5/

The performance was OK at around 30fps for MW2.3. On these small devices, the current renderer seems to be GPU bound, so some form of culling on the CPU might help to improve performance. (On desktop, I suspect that this is not necessary, but it would be good to support more platforms!)

My next goal is to get a WebGL map viewer online, which could be a neat tool. You'd be able to browse popular maps, check them out in 3D, and upload your own map to view.

After that, I might try supporting building a sideloadable android .apk. Building for iOS and MacOS should be possible too, but I don't have apple devices to test on, so if anyone wants to give that a go, that would be really cool!

Ultimately, I'd like the project to support most of the targets that the Magnum library does: Windows, Mac, Linux, WebGL, embedded GLES2 and up, Android, and iOS. It's a good time to get platform support out of the way before hacking deeper into the code, since it's easier to get it done now than later, and it'll establish a good baseline to dev off of.

[Bob Cosmic]

Just wanted to chime in and say this is super duper exciting! Thank you so much for undertaking this project guyfox2!!

[bz_next]

You're welcome, it's pretty fun. Hopefully it can mature to a place where people can build on this work and make some cool stuff.

I have most of the infrastructure now to get a basic map viewer online, using WebGL. The screenshot below is of a test build for web using Emscripten of a new map viewer app:
https://i.imgur.com/SJtpQTH.png

Next is to get the emscripten support more cleanly integrated with the build, factor some shared graphics engine stuff into a new library, and then port over the .bzw text loader from bzfs so that it can parse map files.

[bz_next]

There's a WebGL online map viewer prototype now up at https://bz-next.github.io/mapviewer/mapviewer.html

Currently it can't access any textures that aren't bundled with the game, so try it on maps that don't use custom textures.
Meshes and so on should work fine, however. If you load a map that uses non-standard textures, those objects will appear white, and the app will lag a bit as it will output a bunch of errors in the background.

Here's a screenshot:

https://i.imgur.com/cQrOrmx.png

It also builds as a standalone native executable:

https://i.imgur.com/igOXoH4.png

The standalone version has no texture access limitations, so it can draw fully textured, mesh-filled maps.

Try it out if you're curious

The real power of the Magnum graphics library is being able to support web, mobile, and desktop all from the same codebase, so you can have one codebase that generates apps for all the various targets at the same time. This is a demo of that, basically.

[bz_next]

Windows release: https://github.com/bz-next/bz-next/rele ... Prerelease

I've cleaned up the mapviewer app a bit by factoring common graphics and imgui widget code into separate libraries.

The entire mapviewer is now basically one source file, under 600 lines of code, that targets both desktop and web. Most of that code is just generic stuff to handle input events and create the rendering context. It's a decent demo of what can be done using the new approach, and could be a good base to build further projects from.

https://github.com/bz-next/bz-next/blob ... viewer.cpp

[bz_next]

The online map viewer is upgraded to WebGL2, and supports fetching textures from images.bzflag.org (thank you @blast for your support on getting that working!)

https://i.imgur.com/kf2wmmd.png

https://i.imgur.com/MI2WOSH.png

There's still some work to be done to get it less buggy, clean up the code, and re-integrate it with the desktop map viewer app, but if you want to try it, you can find the rough prototype at https://bz-next.github.io/mapviewer2/mapviewer.html

I recommend reloading the page in between map loads. Once it's stable, I'll move it over to https://bz-next.github.io/mapviewer/mapviewer.html

[bz_next]

https://bz-next.github.io/2024-02-16-mapviewer-editor/

Has some map editing functionality too, it might be useful for map makers. A desktop version would be more useful, since it could auto-detect changes to the .bzw file and reload it for you. That way, you could really rapidly develop a map and immediately see your changes.

At some point I need to try an android build, but I am getting tired of platform support stuff for now, so I think it'll be back to working on the game client soon

I tried the app on my android phone, and it gets a solid 120fps on Louman's home sweet home and churchyard maps. So the renderer is likely fast enough even for a webgl port of the game in its current state.

[bz_next]

Cleaning up some of the UI and adding some more widgets to aid with further development.

Current UI Widgets:
- Material Browser
- Texture Browser
- Material Viewer
- [Obstacle, DynamicColor, MeshTransform, TextureMatrix, PhysicsDriver] Browsers
- Cache Browser
- BZW Map Editor
- GL Info
- Profiler
- About

Turning on docking in ImGui promises to help keep things organized. You can customize the layout to your liking.

docking.jpg

(258.65 KiB) Not downloaded yet

[bz_next]

Just a cool demo pic of connecting to a server using the experimental client, with all the various debug widgets on display.

Finally, I think it is time to work on rendering the tanks. Once that's done, there'll be a bit more architectural stuff to do.

widgets2.jpg

(254.31 KiB) Not downloaded yet

[bz_next]

The client now supports animated tanks. Treads and wheels are animated. Explosions (tank pieces going flying) is ported over, and squish factor (squish on landing, tiny/narrow/thief flags) and transparency tweaking (PZ, going through a teleporter, etc) seem to work.

https://bz-next.github.io/2024-02-29-tank-rendering/

tanks.png

(1.29 MiB) Not downloaded yet

At this point you can observe most of a match in the new client.