23 Jun 23, 01:06PM
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.
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.