3XIX´s Graphic Update [Stopped]

[3XIX]

Hey hey, 

As you might know by now, i´m working on updating graphic aspects of this game. Some might have asked themself why i haven´t shared the Blossom Map reproduction, the answer is: I prefer sharing the full package and not only single things, i made an exception for the weapon models and will see what else.

I changed this thread to be a diary of what i try or change/update. Obviously not daily, since i´m doing things step by step and only if i´ve some time for it.

I´ve also found the issue for performance fluctuations, that however is out of my hands and we´ve to rely on "Flowtron" etc. to fix it. I´m still thinking about creating a map which avoids this issue, that however requires alot of math, since i´m going to add ray traced lighting to it (baked into textures as in the blossom showcase, but with better detail and more bounces)

Alot of that takes huge amounts of time and mainly pc resources, since baking ray tracing into 8k textures and scaling them down afterwards is prerendering. Due to the hot weather these days i pushed that project to the colder months, otherwise downclocking/overheating.


CSGO Workshop Map: Blossom reproduction


A little test of using reshade as "external shaders", which makes more sense for people to be able to activate and deactivate or not use based on their hardware:

Blossom with reshade HDR Bloom:


AssaultCube´s Sunset map with Reshade:


I believe many people dont know that they can use AssaultCube with reshade, therefore the link to it: https://reshade.me/

And yup, currently working on a HUD/Icon update.(tested a valorant type texture modification on gun textures) That´s basicly how i do this, adding something and remove, and repeat until i believe i found/created the better asset.

As usual, feel free to let me know what you think and leave ideas etc.

[3XIX]

Link for the Icons & HUD elements (Unfinished, can be modified/used/expanded by anyone)
https://workupload.com/file/y22JcaEL4bF

[Bukz]

Looking amazing 3XIX! Keep up the fantastic work mate. Btw, I'm not sure if you are aware of this project, but it appears that a few of the original AC devs are looking to move AC to the tesseract engine which already supports quite a few modern rendering techs.

While this is unfortunate for the current AC community because we will not be receiving help on the current/future versions of AC as we know it from them; it is awesome to see them planning to move the project in a new direction and to add support for modern tech on a new engine.

Very excited to see what they are able to come up with in the future. I just sincerely hope the game that they produce is more "realistic" than cube 1 or cube 2...

Link: https://github.com/drian0/ac_tech_prototype

[3XIX]

Thanks Bukz!

The reason i do this is because it´s a challenge, it´s not like taking any obj. or other format and simply drag and drop. Also my focus is on performance, where i will explain something below. The HUD icons and elements i´m also pretty limited, since they have to be a specific size (32x32 pixels) that´s the reason why they´re so tiny, but that could be changed codewise to 1 texture one icon, aswell as position etc.

While it´s great to see that some of AssaultCube devs see the need in better graphics, moving it to Tesseract/Cube2 Engine doesn´t makes sense to me, there are many reasons for that. First, if they plan to move it why not using a up2date open source engine like Godot Engine which supports many latest formats for easy drag and drop (Animations gltf import etc.) I had checked out Tesseract and as far i´ve seen it makes use of md3 still, which is limited by 8192 verts and md5 methods where editing is all over the place.

Also i made checks how it runs performance wise in relation to what it does and its "bad performance", i believe mainly due to keeping Cube´s map editing feature of blocks/cubes, which is also the reason/issue in here when it comes to performance (World vertices cost ~10 times more performance compared to Environment vertices) From my perspective its nonsense to keep it if moving the game, since i´ve not seen many doing Co-Op edits or those creating Maps/Modders been happy about the Map editing.

Map creation shouldn´t be done "realtime/ingame", it needs certain aspects of optimization which we cant seem to do that way, aswell as having a max draw distance to camera for making 3d elements not visible/rendered (or in clusters)

Another aspect would be, why not creating an entirely "new" game instead, if you make graphic updates you normaly exchange models/assets to newer fresher ones, which already look different. Or is the idea to port all the old assets including gun models etc. and only have better lighting?

Thats the main question, i wouldn´t see any graphic related element which should be kept which therefore would make a completly different/new game.

Performance wise it also makes use of realtime light/shadows, which is far from playable for those with lower hardware, for example in CSGO low and mid settings make use of prerendered light and only realtime shadows for moving objects (character models etc) same they´ve done with updated shaders in CS2 and they have trouble to keep everyone in the boat in terms of hardware requirements.

So i basicly do the same with the project, i build the map in blender and apply lighting with cycles (path traced, monte carlo raytracing) and then bake the light and shadows into each objects texture, that means that it costs 0 performance at runtime in the game, compared to realtime shadows. Not 0 since we´ve to use more textures to have smoother light/shadows (more draw calls due to material/surface changes in render).

However that still outperforms Cube2/Tesseract, while it has multicore support (as far i know)
On top of that comes that the maps are not created by themself, an engine itself doesn´t make much in terms of graphics (it can update realtime lighting etc. at the cost of higher hardware requirements) but making it look good and having it performance optimized will be the work of the artists/programmer.

The only benefit is see is easier implementation of animations.

I would try to contact "ic3bug", he made pretty similar things but in Godot Engine. Quake like movement etc. https://store.steampowered.com/app/1359160/Rocket_Bots/
And steam workshop implementation, which should be the route for custom maps these days.
That would be the easier way in my opinion compared to moving it to Cube2/Tesseract.

[3XIX]

A little update,

sadly i have bad news, i found some more flaws within the game engine which will cause trouble with performance later on.

The first issue you already know by now, which are the world vertices, those however i managed to avoid mostly but not completly which therefore remain to be a bad impact on frames per second.

The second issue, i found out last days by adding the project (new map) into the game, which is no vram unload. What that means is, that the game will keep all textures stored in the vram even when playing on a different map, that however means that at a certain point we reach our max vram capacity (differs between systems) which then causes massive stutter/fps drops. The engine also goes to "reload" all textures when changing graphic settings.

This will mean that if a map uses 1 GB of Vram, we use 2GB upon second load. Using this knowledge and combine it with the fact that we want to increase texture size (which leads to higher vram usage) we quickly would go to lose people which could play on the map.

For that you have to know that for example 1000 textures of resolution 512x512 will be 1000 draw calls, those are processed by your CPU and since we´re only using one core we would have massive performance issues, if we however switch it around and would use 250 textures of 1024x1024 we have less load on the CPU but use more vram than most peoples GPU´s have, which would result in a pretty unused GPU in terms of clock rates but with maxed out vram causing the performance drop to nearly 0 fps.

Now adding the 2 found issues to those factors, we know that the graphics i aimed for is possible but would still require high hardware (much vram)

So technically it would run with 2000 fps on a gaming system with example. 8GB Vram but on a system with 512 MB vram it might even crash or would run with 0fps, while both systems CPU and GPU wouldnt be maxed out in terms of clock speeds, due to low poly meshes.

In other words, when baking light and shadows into textures i put the load to another direction and the idea was to put it on the CPU (since low hardware has minimal vram or only shared memory) This would have worked if the Game Engine would use multiple cores, or it still works to a certain degree, for example having 250 textures at 512x512 res. its still a problem since the game doesnt unload.

The end result is, we have to use a new engine otherwise we have nice graphics but making it unrunable for people on low hardware.

And there are some other issues which i dont wanna talk about public, since that information could be used for hackers advantage.

Wish i had better news. So hopefully the og developers still plan to move to a new engine (Not tesseract/cube2)