polyhedronstudio / polyhedron-engine

Heavily modified engine fork of Nvidia's Q2RTX. https://discord.gg/6Qc6wfmFMR

Polyhedron - A Q2RTX Engine Fork and a Game in one.

What is Polyhedron Engine:

Polyhedron Engine is a heavily modified fork of the famous Q2RTX project by NVIDIA™. Accompanied by a game project named Polyhedron. Its history comes from the Nail & Crescent project (If you are a Quake 1 fan, do check it out. Great team, great project). After the split up, all that was left was a bunch of code that didn't represent anything anymore. That's when Polyhedron was truly born. The game serves as an indirect roadmap towards deciding what to prioritize out of the features to add to the current technology. Its soul purpose is to evolve into a fully stand-alone SDK for RTX client/server -model games. After all, what good is a fully path traced renderer without introducing more modern features next to it?

The engine requires a C++ 20 compatible compiler which is capable of compiling ranges. At the time of writing this it has only been tested with the latest VS2022 Preview release (17.2). Crossplatform support is there however, currently it has been a long while since anyone tested that.

This branch v040 aims to target a first release. Not so much a complete and finished game, but a release that enables other developers to either help out development, or fork it and do their own works with. This means that although there has never been any official release yet, v040 will be the first official release of Polyhedron Engine.

Key Changes made so far:

• The capability of using modern C++ features where possible. We try to stick to a somewhat "Orthodox C++" approach and mainly use modern features where it makes darn sense to do so. Readability is important.
• "where possible" means that we try to stick to a somewhat "Orthodox C++" approach.
• Tick rate of 50hz. This allows for more precise and faster game logic.
• Client side game module. Albeit a slight mess right now, it's fully functional and allows for full control over the client aspects of a game. (Input handling, the HUD, and particle effects.)
• Rewritten server side game module that makes use of an inheritance based class entity system. Game mode classes that determine specific rule sets. This makes for more organized game code where we do not see if (cvar->value) { /*...*/ }. And several other neat features.
• Shared Game folder that contains pieces of code which are used in both client and server game modules. Current examples are: Player Move code, and several functions for skeletal animation processing.
• New and improve player movement, a modified version of Quetoo's movement code (With permission of course.). As such, you can now navigate stairs properly without starting to bounce off them into a single direction.
• New vector math code. (Thank you, Quetoo, and QFusion.) In other words:

vec3_t a = { 0.f, 5.f, 0.f }; // We can construct vectors like this.
vec3_t b = { 5.f, 0.f, 0.f };
vec3_t c = a + b; // Vectors support operators.
vec3_t d = vec3_cross(a, b); // Macro functions replaced with static inline functions to accomodate the above.

• All entities that are of key importance are fully rewritten in C++. Some may still be lacking, or missing certain functionality, the basics are all there however.
• Items and weaponry have gotten a full rewrite so they fit in exactly with the new C++ entity system.
• No more snapping to grid, or being dragged to the 0,0,0 point like a drunk madman when moving around. The player, and entities, move at full floating point precision.
• Way more things, which are best discovered by simply diving in the code and experimenting with it all.
• Support for IQM, MD2, MD3, and obj formats.
• Support for QBism BSP. (Extended boundaries, optional vertex normals allowing for smooth shading brush surfaces.)
• Custom lightstyle strings, of course, with on/off states supported.

A small impression:

Here's a few screenshots to accommodate the above. It's not a Quake game, but it is derived from good old Quake tech.

Things that aren't quite proper yet:

• Net code. Due to having decided to transfer data with full precision and tackle optimizing this later on.
• Demo playback, obviously related to the change above.
• Save/Load states. Simply did not get to this yet.

General guideline for v0.4.0 features:

The following features are intended to be completed before deploying an official first release:

• Add at minimal 3 weapons: Knife(Melee), Pistol(single shot), Sub Machinegun(burst and automatic mode). In order for these to be operational it'll require several states to be implemented for weaponry including: Draw weapon, Holster weapon, Idle weapon, Primary Fire, Secondary Fire, Reload, and Drop.
• Add support for handling skeletal animations in entities accordingly to one of the base classes. (Much of this is inspired by GoldSrc, and FreeHL.)
• Look into QFusion and see if it's worth it to add in Octagon trace and clipping support. This'll add a slight form of realism when bumping into other NPCs/Players or when having somewhat circular like entity models. It's not perfect, but beats a good old BoundingBox any day.
• Add a model config for skeletal animated models defining their animations, blending and model events at specific frames. (Model events can be used to trigger a muzzleflash at said frame, eject a bullet shell, or tell an entity to play a footstep sound exactly when you know his feet touch the floor, etc.)
• Use the above to reimplement player model animation support.
• Save/Load state support needs a reimplementation.
• Clean up the extern submodule folder. Redo all of it and proper this time around.

Other future ideas:

Even though the list for v0.4.0 is small, it's mainly targetting the nescessary things that are still lacking in order to actually be able to call itself a useable project again. With that said we can't deny the everlasting need for more, can we? So here's a list of things that demand more research and/or have been researched but simply not implemented yet.

• Material System, even though one exists for the Vulkan Path Tracer, there is no functionality with regards to surface contents and their physical behavior. Reasons to add it are footstep audios, setting friction, one step closer to adding decals some day.
• Decals: These can most likely be simulated by having some overlay that gets clipped accordingly to surfaces. Not perfect, and may still be prone to creating noise. Can't say until we try.
• Material type defined footsteps.
• Material type defined friction.
• JoltPhysics support. Why? So far nobody has had luck replacing the good old tracing mechanics using PhysX, Bullet3D or other known libraries of its sort. JoltPhysics may play a valuable roll in this thanks to it being targeted to games 100%, fully open-source, and has an easy enough to use API. It allows for implementing custom broad and narrow phases which may play a part in the solution of this mystery.
• RmlUI. Already exists in OpenGL mode, however for it to work nicely in both renderers it requires several small extensions to the R_DrawPic APIs. Including various modifications to the current Vulkan 2D rendering pipeline. The basics are already there however, just not finished. RmlUI will allow for us to use RML(HTML like layouts), and RCSS(CSS3 like styling including transforms: Nice effects in menu's and HUDs.)
• Add in UDP Packet Fragmenting support for up to 4 packets max, anything higher would be irrational and counter-act on the net code instead. This'll prevent the quite easily achieved net frame drops which ultimately ruin a game.
• Change the time code to use int/uint64_t instead. Q2PRO's old code relied on floats that start running out of precision after 4.5 hours. (Q2RTX is derived from Q2VKPT, and in turn from Q2PRo so. We gotta deal with that as it is.)
• Move over to MiniZ instead of LibZ.
• Look into audio effects, we got OpenAL Soft support right now, however perhaps switching to miniaudio(a single header library supporting special effects and 3D spatilization of audio.)
• Persistent client side class entities that can execute their own game logic. Examples for use are for example debris/gib entities. Right now spawning a few of these can already cause a loss of frame packets due to it overloading with baseline entity states.
• Client side weapon prediction.
• Simulate physics on the client where possible. This means less(perhaps, even none) client side prediction errors on stable connections. (Right now riding a platform will always have some minor prediction errors going on due to the client always being a frame behind the server.)
• Binding modelindex2 and up to a specific bone of an entity's mesh. Allowing for weaponry to be held properly by a character model etc.
• (Partial-) glTF2 support. This mainly makes the entire content pipeline of things easier to work with. IQM is a fine format otherwise.
• There's more, this list should just give you a general idea of what Polyhedron is heading out for. Feel free to chime in and suggest possible ideas, or help out.

Acquiring the Sauce

In order to acquire the sauce, one has to do a recursive submodules checkout, otherwise one is going to find himself in a land full of wonderful error warnings that share misery and pain. Keep in mind that the engine is currently still undergoing full development. We promote interested people to check out the code, and join on our Discord if you have any interests in joining forces.

Building the Sauce

Nothing more than using cmake on the Sauce root folder, or using Visual Studio's "Open Folder" which'll use CMake from there.

Windows 10 - VS2022

1. Clone the repository and its submodules from git: git clone --recursive https://github.com/PolyhedronStudio/Polyhedron-Engine

2. Start VS2022, and use the "Open Folder" method to open the project, as one normally would when using CMake projects.

Linux

1. Clone the repository and its submodules from git: git clone --recursive https://github.com/PolyhedronStudio/Polyhedron-Engine

2. Create a build folder inside your <PROJECT_ROOT> directory. Open a terminal in this location, and enter the following: cmake ../src && make

3. If all goes well, you will now have a Polyhedron, Polyhedron_Dedicated, basepoly/clgame.so, and basepoly/svgame.so. If not, we're still looking for help in this department. Feel free to reach out to us on our Discord if interested.

Submodules

• This list is currently not up to date.
• N&C SDL2
• N&C RmlUi
• N&C curl
• N&C tinyobjloader-c
• stb
• zlib
• Vulkan-Headers

polyhedron-engine's Issues

gl_showtris for VkPt

pt_showtris? Either way, same functionality. Supposedly already exists for sky surfaces, and can easily be extended. Happens to be I forgot where it resides exactly anyhow so... But it's a nice one to have around for mappers and for our own debugging reasons.

Re-factor viewbobs/kicks and footstep sounds etc. for 60hz

As the subject says.

Add in support for IQM Animations and a few other of its special features.

Why, what for? Wasn't it already working in perfect shape?

The IQM format comes with a framerate value per animation, and in fact also a name. This framerate aspect is currently unintegrated and is almost a requirement to use in the case of N&C if we want to make things work more nicely with the game code again. If an animation is determined by an integral value and the Hz rate is 50... you can imagine that if all other weapon code which is in return strictly based on which frame you're at goes haywire.

Wished for/proposed solution would be that no matter the hz, it'll play the animation at the same speed. (Of course this would skip frames or just not work nicely at all in case there is a ridiculous high amount and the FPS can't take it, or visa versa.)

There are more reasons to want to have full support, because "as above isn't like below today":

The IQM format can be expended, it leaves room for devs to add in custom data by purpose. FTEQW engine has made great use of this, and in fact loading in what they then called a ".vvm" would be a piece of cake. A single extra structure containing a variable or two.

This specific structure was about model events, for example, when animation "shoot" gets executed, it'd fire a local game implemented event number resulting in cool effects. An example of such a .qc script can be seen here. v_pistol.qc

The other reason is that, should we use a head-torso-legs system like Q3 based engines do, or can we one way or the other integrate blending there? These few topics go beyond my reach on a code technical scale. (well I could do the head-torso-legs obviously but ...)

output v_pistol.vvm
materialprefix /textures/models/weapons/pistol/


origin 64 -20 -24
rotate 270 -90 0
scale 1.5

scene "iqe/v_pistol_muzzleflash.iqe" noanim 1 

scene "iqe/v_pistol_muzzleflash.iqe" nomesh 1 name "idle1" fps 30 start 168 end 196

event reset
    event 2 1337 "weapon_pistol.fire"
    event 2 1338 "muzzleflash1.vvm"
    scene "iqe/v_pistol_muzzleflash.iqe" nomesh 1 name "attack1" fps 30 start 2 end 10

scene "iqe/v_pistol_muzzleflash.iqe" nomesh 1 name "attack2" fps 30 start 196 end 214

event reset
    event 10 1337 "weapon_pistol.reload"
    scene "iqe/v_pistol_muzzleflash.iqe" nomesh 1 name "reload1" fps 30 start 10 end 56

event reset
    event 135 1337 "weapon_pistol.deploy"
    scene "iqe/v_pistol_muzzleflash.iqe" nomesh 1 name "draw1" fps 30 start 135 end 167

event reset
    event 126 1337 "weapon_pistol.holster"
    scene "iqe/v_pistol_muzzleflash.iqe" nomesh 1 name "holster1" fps 20 start 126 end 135

Examples of the file structure I used and the models themselves can be found here in my old SchizoMania project repository:

Notice how the names, the frame rate per second, and the specific frames out of the list in general to pick from can all be adjusted in these "scripts"? The workflow might be a bit time consuming, but it'll be our best bet at having nice animated characters, as well as nice animated weapons.

Keep in mind that for a bullet shell to pop out, it'd just take a certain event number, modelname, and any artist can actually take control over what shell, what sound, and at what frame this has to happen.

Right now we got IQM playing nicely, without blending (If I recall this would require Inverse Kinematics.), however it seems to lack the framerate aspect which is the highest priority right now. And of course, all the other things mentioned.

One final example of how I did the Zombie Character back in SchizoMania, it also mentions how animations can auto loop (unless of course ever the game code tells it to go play some other animation.)

output zombie_derrick.vvm
materialprefix /models/characters/zombie_derrick/

scene "iqe/tpose.iqe"

origin 0 0 0
rotate 0 -90 0


scene "iqe/agonizing.iqe" fps 30
scene "iqe/attack1.iqe" fps 55
scene "iqe/attack2.iqe" fps 30
scene "iqe/dying1.iqe" fps 30
scene "iqe/dying1_fast.iqe" fps 30
scene "iqe/dying2.iqe" fps 30
scene "iqe/dying2_fast.iqe" fps 30
scene "iqe/hit_react_a.iqe" fps 30
scene "iqe/hit_react_b.iqe" fps 30
scene "iqe/idle1.iqe" fps 30 loop
scene "iqe/idle_hunt.iqe" fps 30 loop
scene "iqe/idle_scratch.iqe" fps 30 loop
scene "iqe/running1.iqe" fps 30 loop
scene "iqe/scream.iqe" fps 30 loop
scene "iqe/turn_backface.iqe" fps 30 loop
scene "iqe/walking1.iqe" fps 35 loop
scene "iqe/walking2.iqe" fps 50 loop
scene "iqe/walking3.iqe" fps 30 loop

All of this resulted in a slightly slow and somewhat limited by toolset workflow, however given the advantages and the fact that the Quake communities do keep these tools up to date (Eihrul has his own iqmtool, and Blender export/import.) Where FTEQW has its own iqmtool as well with several other improvements.

Sources:

Source code to the engine Tesseract src, which is messy/tricky to read, you'll see the files soon enough. He goes over the top with a BIH, Ragdolls, no physics engine for it either. That is not our goal but it might help be a reference for loading in IQM data.

Fix SVG_MoveStep issue - Turned into change the edict_t(Entity) allocation over to the server.

Physics problem with misc_exploboxes and other stepmove entities for that matter. If/when stacked and one disappears, it tends to go boom and crash on us. Seems to be related to an out of order deletion of entities. As if the server entity goes out first, and leaves the classentity pointing to invalid memory.

It might be quite nice if we could add the option to be able to shove them off edges too. Right now it is only possible to do so on slopes/stairs.

Add lightstyle support to material surfaces belonging to an iqm mesh.

Exactly as it says, got told to look at:

That's easy, you just need to fill the light_style bits of material_id of model's triangles in the instance_geometry shader
see get_material_info in vertex_buffer.h```

Would be great to have for the Polyhedron sphere and of course any other model object that you'd like to have emit similar light.

Patching up from where we left off.

First things first: Bigger picture goals.

What started out as a Q2RTX Fork, sadly never got to be what it had to be, an engine powering a Quake 1 sequel. So now what?

Work continues as per usual, setting out to solidify what we've got right now and patch it up to reach a usable and functional state. This'll require several things to be taken care of such as:

• Finish work on all the remaining entities to-do in the server game lib.
• Finish save/load and respawn related issues.
• Finish game modes by adding TypeInfo to them and getting rid of coop and deathmatch cvars respectively by replacing them with the already existing gamemode cvar.
• Clean up/Refactor several client game code.
• Refactor/Research net code to allow for more data to be transfered, perhaps by packet fragmenting.
• Interface all import/export functionalities of (game-)client/server import/export -structures.
• Update the code with all the latest updates that Q2RTX has had in the past time.
• Replace all basic content that is required to have a simple FPS with free content, rendering us independent from Quake 2 data, making this project a stand-alone afterwards. (Other than sharing the obvious which is parts of the code base.)
• Add a proper weapon system framework that's easy to work with. (Support for reloading, dual wielding etc.)
• Expand the material system as so to support it passing info to the server game and client game libs. Useful for footsteps, perhaps even custom friction and other game specific details on a per material basis.
• Add proper 2D rendering support for RmlUI.

This is the general gist of things that need to be done in order to actually be a usable piece of work again.

Future ideas/wishlist to research:

When all of the above is said and done, the goal is to get back on track with whichever ideas we got in the following list below:

• Proper start up that displays the logo of the current game project being ran in fade-in and -out fashion.
• Investigate and implement more functionality for IQM support.
• OPTIONAL: Perhaps see if adding in a certain physics engine is worth all the effort. It'd add quite a bunch of powerful features that are useful for designing proper gameplay elements.

... Feel free to suggest any features you'd like to see here yourself! ...

Current tasks being worked on:

Please note that these vary and are sub tasks of the latter above, all serving a "greater purpose".

• Fixing Client/Server respawn for single player(defaultgamemode) in the case of calling gamemap SAMEMAP again.
• Fixing Client/Server save/load for single player(defaultgamemode).
• BaseMover entities such as func_door, func_door_rotate, func_plat and func_rotate. (Half way there already.)

Trenchbroom & Official Support

Having spoken to some in the Trenchbroom Discord, it's not that hard to be reknown as an official project in/for their releases.

In our case it'd mean having to implement a variety of this (which they said would be hard, but we aren't having all that Q3 shaders have nor do we need that in the editor to be displayed per se. Take a bit of a deeper look and you will see why they stated it was "hard".

With Q2 .wal being officially supported now, and that at least being our base to begin with regarding our own materials, it makes sense that this "PolyHedronMaterialParser.cpp" would parse those content and surface flags from the .mat Other than that, it only has to tell TB to load in a .tga

Now when it comes to .iqm support, I have no clue why nobody ever ever added that because it was quite easy for me to find some simple loading and rendering code for that... Here
] is a random one found on the web that I bet can quite easily be converted into a TB compatible loader implementation. Perhaps look at Md3Parser.cpp as a base.

I'm curious to hear your thoughts. Of course this isn't for milestone 0.4.0 per se, we haven't even finished the material system properly yet. But if they do not mind officially supporting us, and the editor being so well known etc, I think it's a great option to go for it.

Adjust to 60hz or whichever tick rate is chosen.

We'll need to come up with a method that is as easy and little annoying as possible in order to have the game run as if it were back in the day, while still being 60hz.

For example, animations are currently stored as integers (ouch) and this becomes problematic, especially if game code depends on it. Like shooting 6 blaster bolts or so a second is really not good. (Looks funny though)

• Get viewbob and footsteps to work again.
• Get the network to play kindly with it again. Slightly related to #5

Implement RmlUI for sweet looking menus and HUDs

This will be sort of a requirement given the amount of flexibility this library has. Let's say when a player gets damaged, it is able to do certain transformations/effects to the font(numbers) in the specific element.

Sun, night and day etc.

Currently is controlled most often by the '/' key, however this should be done throughout the server instead. Perhaps there is room in configstrings, or we'd have to add some extra events. One way or the other, the server game has to rule over its domain where the sun may shine :)

Client and Server side materials.

See whether we can make it fit in with the current .mat system. Seems logical to me to do so. This way, for example, a specific surface of a brush can have its own footstep style, or perhaps have them disabled. It is about control over such matters, decals for bullets that look different per material (we do not have them yet but still)

Other example would be how much friction it gives to the player movement.

Revive Items from the dead, and C++-ify

It'd be nice to be able to pick up guns and drop them again, or let's say, healthpacks, yeah, good!

Weapons, C++-ify

Currently weapons are still done the old-school method, and that does not sit too well. We'll need to see fit on how to modernize this.

Finish all basic C++ entity implementations.

There is little to be said about this.

Implement support for background BSP maps in the mainmenu.

These should only appear if, the game had a fresh boot. Or if a client disconnects and drops back into the mainmenu.

Add in Spotlights suppor.

A while ago spot lights had been discussed and it supposedly quite easy for Alex to add these in. I've found a good old Q2 tutorial on how to do it when it was still generating (lightmaps)[http://www.quake2.com/qworkshop/tutorials/lights.htm] tutorials

I'd suggest we add pointAt(target): targetname_of_other_ent. This way, regular light target can still perform triggering as it should. (It does in N&C).

Either way, this one is on our wish list which of course needs lightstyle support without a doubt.

Add in "Dynamic Light" rendering support.

We'll create a light entity as per usual how things were done. We'll give it a lookAt entity target, custom color(since there is no surface it emits from, but perhaps it is do-able in both ways, also as a brush entity. So you can have spotlights like prisons have etc.)

Obviously the wish for it being able to have lightstyles would be really cool too.

Improve networking to prevent frame drops as they do today.

As it stands, the networking can only handle so much. MTU limits are reached too often due to the transfers of high precision data(we could use quantization there, but it is not enough and can not be applied to every situation.).

Bitpacking is another idea to make use of. However ideally replacing the netchannels with a library that does the dirty job for us with regards to sending these packets around sounds like the most solid idea.