AC-Map Design/Clipping etc.

[3XIX]

Hey Guys,

after another 2 years of research i learned alot more about performance aspects, when it comes to 3D art.

today i wanna show a little map project i´ve made (had to clean it up, since i couldnt get license permissions from Quixel) I still believe it should look decent enough for AC Level, remember that its created with Hardware for AC in mind. Also containers could have seperate textures each, if i find more CC0 sources.

Some technical info:
Vertices: 1310 (minimum possible, textures give the detail)
Shader Changes: 6
Surface/Material Changes: 7 (Bump/Normal Map texture stored within the alpha channel of a texture, "fake" Normal)
Draw Calls: 1 (Combined all Models to one Model, this reduces CPU usage around 75%)
which is really important, since we effectivly using 1 Core only in CUBE Engine, besides that many developers doing that wrong even in AAA games (combine models/collision, after that games are nearly limited to GPU only) Also having the CPU deliver data faster to the GPU result in more FPS, if GPU isnt maxed.

The overall environment vertices of 7429 have to be seperated, gun, hud and specificly shadow (doubles vertices)

Design copied from Line of Sight - Opencage Map:


Still, since i didnt really learned more about Assault Cube itself, im thinking about how to Clip it.
I´ve tried to clip it seperate and with playerclips but both seem to be collision only and dont stop bullets.
So, if someone knows how thats done, the map can be released.

Note: I know that it could be done with walling inside of each container for example, but that would require world quads and world vertices (which are waste of performance, since it only needs clips which doesnt display anything, that way its nearly exact 400 fps on an old Intel HD4000, couldnt test with ATI Xpress 1100 yet, but those who wanna give it a try to test without clips (not final performance) you can use a seperate game client (Make sure to not play online! You wont see anything in most Maps anyway :P) loadmap opencage via console or go to singeplayer, empty map, show all maps, opencage. At moment the map replaces Makke/Barrel Model (Loading times will be increased due to 4k textures)

Opencage for AC - Alpha:
https://workupload.com/file/syXhgznSXDs

Piece

[Mr.Floppy]

You can use clip entities, which support 45° rotation and tilting since v1.3. It is a little clumsy to set it up correctly, but it has everything you'd need:



For this particular instance (see screenshot) the command would be /newent clip 0 4 10 9 0 0 3, the last digit is the rotation. However, on this scale it would be a pain in the neck to set all those clips up manually.

I have some faint memory of someone explaining that clip collision is way more costly than geometry collision. Therefore I imagine using geometry to 'block out' the map might indeed be more efficient.

As far as I can tell, any surface does stop bullets. I tried it with this map and when I shot with the sniper rifle into the edge of a container I could not see the bullet trail go through, so I guess this already works as expected.

Anyhow, I don't quite understand what exactly you have done here. It seems all those technicalities you mentioned are only relevant to the editor you used for creating the model, or did you actually change AC's rendering pipeline and recompiled a modified client?

I'm asking because I managed to reproduce this in the vanilla v1.3.0.2 client with basically the same performance, simply using your map and the model, which btw., you should have put in a separate folder rather than overwriting one of the most used default models. In any case, there's absolutely no need to ship the entire game folder even if you modified the binary.

However, this all still does not work because lighting is completely f*cked up. Ever tried to place a light entity in there? Even worse, with dynamic shadows ('stencil') enabled, when the camera is fully 'within a shadow' the shadows suddenly flip, that is, the light areas become the dark areas and vice versa.

Besides that, 4K resolution is too much, even if this wasn't AC we were talking about. That one 'map', which is basically simple 8-vertices boxes with 5 different skins for containers, 1 texture for a crate and 1 floor texture takes up 30+ MB. That's almost half the size of the actual AC download. As much as you care about performance you should also care about data size optimization. I guess you could chop the texture sizes in half, maybe even smaller than that and it wouldn't look all that different ingame.

Finally, and I guess I have said this in the past already. This entire approach of building a map completely in some CAD editor and load it into AC as one mapmodel is not feasible.

I don't mean to be harsh or something, but you should take a step back and think about what you are actually trying to achieve here. I guess most of what you have in mind is already possible with the engine (we have high res texture support for geometry now), it only takes new high quality assets and some advanced mapping skills to get there.

[3XIX]

You can use clip entities, which support 45° rotation and tilting since v1.3. It is a little clumsy to set it up correctly, but it has everything you'd need:



For this particular instance (see screenshot) the command would be /newent clip 0 4 10 9 0 0 3, the last digit is the rotation. However, on this scale it would be a pain in the neck to set all those clips up manually.

I have some faint memory of someone explaining that clip collision is way more costly than geometry collision. Therefore I imagine using geometry to 'block out' the map might indeed be more efficient.

As far as I can tell, any surface does stop bullets. I tried it with this map and when I shot with the sniper rifle into the edge of a container I could not see the bullet trail go through, so I guess this already works as expected.

Anyhow, I don't quite understand what exactly you have done here. It seems all those technicalities you mentioned are only relevant to the editor you used for creating the model, or did you actually change AC's rendering pipeline and recompiled a modified client?

I'm asking because I managed to reproduce this in the vanilla v1.3.0.2 client with basically the same performance, simply using your map and the model, which btw., you should have put in a separate folder rather than overwriting one of the most used default models. In any case, there's absolutely no need to ship the entire game folder even if you modified the binary.

However, this all still does not work because lighting is completely f*cked up. Ever tried to place a light entity in there? Even worse, with dynamic shadows ('stencil') enabled, when the camera is fully 'within a shadow' the shadows suddenly flip, that is, the light areas become the dark areas and vice versa.

Besides that, 4K resolution is too much, even if this wasn't AC we were talking about. That one 'map', which is basically simple 8-vertices boxes with 5 different skins for containers, 1 texture for a crate and 1 floor texture takes up 30+ MB. That's almost half the size of the actual AC download. As much as you care about performance you should also care about data size optimization. I guess you could chop the texture sizes in half, maybe even smaller than that and it wouldn't look all that different ingame.

Finally, and I guess I have said this in the past already. This entire approach of building a map completely in some CAD editor and load it into AC as one mapmodel is not feasible.

I don't mean to be harsh or something, but you should take a step back and think about what you are actually trying to achieve here. I guess most of what you have in mind is already possible with the engine (we have high res texture support for geometry now), it only takes new high quality assets and some advanced mapping skills to get there.

Will have to check the newent clip method, as far i saw bullet trails stop when hitting a surface no matter if clipped etc. but players would still receive damage (atleast bots do) so idk about that. 

The technical stuff i mentioned are indicators for performance, basicly meaning that for better graphics we would have to keep the vertices as low as possible, combining as much models as possible, higher resolution textures. 

And i havent done anything to the engine itself, it only was easier to zip the whole game instead of sorting the files, since it should be seen as showcase of a different way to create maps in Assault Cube, to archive better quality and other map design.

Also i didnt knew that AC map editor supports 4k by now, but while thinking about it...how would you create a container for example, that would require 4-6 textures instead of 1, leading to more drawcalls and surface changes (lower frames per second)

High quality assets we wont be able to do without losing alot frames per second, only if we keep vertices low and textures high.

My focus/vision is high fps, better graphics. In general i think the game could be enjoyable for more people, but many no more or dont wanna see washed out surfaces etc. The map opencage as its called in the game line of sight has a reason behind, we will have to think about scenes in reality which are totaly human created, like a harbour/shipment cause we like to build cubish, mostly to reduce production costs but knowing that and finding areas to recreate is the key, also indoor maps would be possible using cubes mostly. 

And doesnt the map design feel completly different/new, if you spawn some bots you could imagine how it would feel to play and dont tell me it doesnt look nice...as you said yourself 8verts each container, i mean sure i could go for 200 verts each container (still ultra low poly) but there are over 100 containers in the map meaning that it would take 20.000 verts (include shadows and you end up with 40.000) while an old GPU would still be able to reach over 144 fps with that it could be done, but then you have to check pickups, weapons etc. and obviously player models count itself 32 players on a map would lead to another 40.000 verts, so things stack up quickly and we´re easily at 100.000 vertices in a scene. I wanna keep the requirements pretty much same, except for disk space (even there i compress the textures to a minimum) but at the end im not a magician.

Edit: To the shadows, thats due to stencil shadows working for models only, they have an atlas size max at moment its set to 1024 (you can check within the model md3.cfg, also modelscale itself has an effect on it (would have to check to increase the model size in blender) i also tought about overlaying shadows on textures (had done that but would require alot more diskspace, with the benefit of not having double vertices, since shadows are static anyway) rn its solution finding to make it work for AC and most maps you dont have any shadows except for models?.

Some pickups in work:


Ammobox and Pistolclip (changed to simple .45 bullet carton) probably will stay, Vest i replaced with an Armor Plate, all reasons of performance.

In general while playing and while they´re moving you wont notice the cubish design that much, also "fake" normals give the slight bump effect. Colors are not final.

Note: Im using an RTX3070, 1000 fps is the limit of the fps counter, the true fps is higher. Ported to a new engine its around 5000 fps, honestly it would make things easier (baking shadows/lighting etc.) but i choose to also include/produce for AC, the fps of 5000 is mainly due to multi CPU cores delivering data to the GPU.

[3XIX]

I feel like i have to clarify a few things you might didnt thought about when talking about diskspace.

A texture of atm size 256x256 fits 4x into a 512x512 texture which is still low and washed, meaning that if you would update all textures to the next higher resolution you end up with 200 MB (if we just assume most would be textures) now lets calculate it up to 4k.

512x512 x 4 to archive 1024x1024 = game size of 800 MB
1024x1024 x4 for 2048x2048 = game size 3,2 GB
2048x2048 x 4 = game size 12,8 GB 

Those are basics, remember all those values are uncompressed (the game textures at this state are uncompressed btw)

The about 30 MB for the few textures are uncompressed, it would be around 14MB after compression but after that we reach a point where you will notice color artefacts within the texture, therefore lower is impossible.

But lets look at the hardware itself, for textures alone you wont have to buy a new GPU or CPU (depending on amount where we would hit framebuffer limits) So even if it would end up with 2 GB for multiple Maps, these days you basicly get even USB sticks of 8GB for free. While even my old Acer notebook of the year 2000 has an 80 GB HDD. I mean even for the Android version...smartphones will mostly have that space and then seeing a few GB as a problem?

Again if we go for higher detailed models /more vertices we end up with higher diskspace usage and massive FPS loss, since models itself will get bigger in size, so no matter where you start...at the end it will cost alot more diskspace, there is no way around.

The newent clip command also does nothing else as the clips via hud, also i think the person you heard saying collision clips would be more exspensive compared to geometry ones, its the opposite (as i mentioned)

Still what i dont understand, why or for what would you need clips for, if they dont stop bullets (in code, the trails and bulletholes are normaly seperated, same for the detection of the "world") So i strongly believe that i either cant find the correct clips or there is none coded. 

Seems like i have to use geometry itself, meaning getting ingame cube sizes and making them slightly bigger for about 0,02 or something as "overlay" over the world geometry (wqd and wvt in hud) that should be around 6000 wvt for that map maybe less, which then wont allow stencil shadows.

So for those who wanna know, we could predict the FPS by looking at maps where you have 6000 wvt/world vertices and evt/environment-model vertices of 7000. Combined around 13-14.000 verts without players.

I think many maps are within that area, so it should be around same performance but increased graphic textures. Have to see when i find time to rebuild that map to fit the Cube map editor cube sizes, until then piece

[Mr.Floppy]

Well, it's hard to explain everything I want to say, so I decided I give it a try myself and set up a little proof of concept on how to do 'high fidelity' in AC v1.3 using the cube engine as intended. Get the download and extract it into your personal AC-folder. It contains a map called poc_container and all assets required. 



Download: packages.zip (1.8 MB)

Note that this is only 1.8 MB! Not even close to your 30 MB and it has basically everything you wanted and appears to perform just the same.

Admittedly the container model skin is somewhat sanitized (using only the door face on either end), which helps a lot in optimization. But it's exactly those trade offs you have to find in order to keep things within reasonable file sizes. However and more importantly, my skins are properly optimized in terms of space usage, that is, no black areas and no doubling of the same parts, which allows me to keep the size down to 2046 x 2046, while maintaining almost the same effective resolution like your 4092 x 4092 version.

There are two skin variations missing (grey and light red), which would only add around 400 kB each to the package size.

Hints and findings:

• Bullets are being stopped for human players only. What you experienced is only happening with bots. Maybe a bug that should be fixed, but nothing to worry about too much. You can use clips (/newent clip) or clip-tags (/edittagclip) if an area can be blocked from ground to ceiling.
  
• Stencil shadows seem to be broken, or were implemented only to work for small models intentionally (key word: simplicity). I wouldn't enable those (see: md3.cfg > mdlshadowdist 0) for most models actually.
  
• Huge models should have vertex lighting mode enabled (see: md3.fg > mdlvertexlight 1). This way the model will be lit per vertex, rather than uniformly per the light value which is found on the cube where the model is put.
  

My conclusion:
There is no use in 'baking' everything into one gigantic model. From a mapper's perspective it is always better to be able to work in the engine's native editor, so one can change around positions on the fly, make use of geometry (collision, occlusion, ...) and so on. From a performance perspective I see no benefit. To me it looks like you're assuming a lot of stuff, which simply does not work like that in cube's rendering pipeline (e.g. number of draw calls, amounts of vertices change when solids are added).

Finally, please don't get this wrong. I really don't want to stop your enthusiasm and I don't want to be the old smartass neither. After all you inspired me to do this POC and I'm actually thankful for that.

But, frankly you seem to lack quite some understanding and experience for what you are trying to achieve. For one and you said this yourself, you have no idea how the cube engine works, which is the core issue in my opinion. Secondly, the container textures have a lot of flaws, like overlapping, obvious mirror fill ups, wrong orientations, visible copy/paste-seems and poor colour and contrast adjustments. You really got to step up your Photoshop skills and be a lot more disciplined, when you are aiming for 4k quality.

[3XIX]

Well, it's hard to explain everything I want to say, so I decided I give it a try myself and set up a little proof of concept on how to do 'high fidelity' in AC v1.3 using the cube engine as intended. Get the download and extract it into your personal AC-folder. It contains a map called poc_container and all assets required. 



Download: packages.zip (1.8 MB)

Note that this is only 1.8 MB! Not even close to your 30 MB and it has basically everything you wanted and appears to perform just the same.

Admittedly the container model skin is somewhat sanitized (using only the door face on either end), which helps a lot in optimization. But it's exactly those trade offs you have to find in order to keep things within reasonable file sizes. However and more importantly, my skins are properly optimized in terms of space usage, that is, no black areas and no doubling of the same parts, which allows me to keep the size down to 2046 x 2046, while maintaining almost the same effective resolution like your 4092 x 4092 version.

There are two skin variations missing (grey and light red), which would only add around 400 kB each to the package size.

Hints and findings:

• Bullets are being stopped for human players only. What you experienced is only happening with bots. Maybe a bug that should be fixed, but nothing to worry about too much. You can use clips (/newent clip) or clip-tags (/edittagclip) if an area can be blocked from ground to ceiling.
  
• Stencil shadows seem to be broken, or were implemented only to work for small models intentionally (key word: simplicity). I wouldn't enable those (see: md3.cfg > mdlshadowdist 0) for most models actually.
  
• Huge models should have vertex lighting mode enabled (see: md3.fg > mdlvertexlight 1). This way the model will be lit per vertex, rather than uniformly per the light value which is found on the cube where the model is put.
  

My conclusion:
There is no use in 'baking' everything into one gigantic model. From a mapper's perspective it is always better to be able to work in the engine's native editor, so one can change around positions on the fly, make use of geometry (collision, occlusion, ...) and so on. From a performance perspective I see no benefit. To me it looks like you're assuming a lot of stuff, which simply does not work like that in cube's rendering pipeline (e.g. number of draw calls, amounts of vertices change when solids are added).

Finally, please don't get this wrong. I really don't want to stop your enthusiasm and I don't want to be the old smartass neither. After all you inspired me to do this POC and I'm actually thankful for that.

But, frankly you seem to lack quite some understanding and experience for what you are trying to achieve. For one and you said this yourself, you have no idea how the cube engine works, which is the core issue in my opinion. Secondly, the container textures have a lot of flaws, like overlapping, obvious mirror fill ups, wrong orientations, visible copy/paste-seems and poor colour and contrast adjustments. You really got to step up your Photoshop skills and be a lot more disciplined, when you are aiming for 4k quality.

First of all, appreciate that you also give it a try.

Ive checked it and yea, you cut off 3 container sides (the idea was to brush containers later on, grafiti etc to not have this clean look, each container side with a different look*) therefore it requires all of its faces to safe textures (6 faces you cant fit within a quad texture without black, which isnt a big problem since black pixels need less kilobyte compared to color)

To the hints,

I also figured that stencil shadows seem to be meant for small models (everything below camera) while thats not huge deal, since we dont have shadows in maps anyway (besides models)
To the clips, yes thats good to know but since we´re creating most walls via model faces, you could scale the model down for multiplayer and have a kind of "wallhack" since you will be able to see thru clips. 

And obviously nothing here is final, i made it within a few days (texture orientations, overlapping, sky not fitting correctly etc. i know all of that...but the way i work is seeing something, knowing faster how it would look like, the tweaking comes after that (i mean it could look totaly shit and you would spend all your time in perfection and later deleting all files) Also im modding an old game as far i tought, im not touching a AAA here.

And im also checking hardware usage in realtime, while i wont have to for this...


The placed pickups we can ignore pretty much, since they´re the switched 8-16 verts ones, also they add up on environment vertices/evt.

Now my method, updating in process(geometry/walls within the containers will work for bots aswell):


I probably dont have to tell you the huge difference it makes (not even on low hardware) having 16.000 world vertices/wvt and 6000 wqd, compared to 2000 wvt and 500wqd. Remember the heightfield itself costs performance while 128x128 map is less than 256x256, that comes on top.

Conclusion, both methods have its pros and cons, while for performance/graphic a big mapmodel is the better choice, again you could have the same amount of models in this case containers 100 seperate models will cost alot more performance compared to combining 100 to one, since a processor likes 1 task and not multiple (stop and go effect). Sure for this game and those models the difference is not that big, the moment you add 10 pallets or something else you quickly find out, minimum verts for a pallet is pretty much 160x10, 1600 verts. 

At the end, i wanna work together...and i see what you could do, what i dont know...and im sure that you know the engine better (commands etc.) for example implementing it correctly...for the moment all been "alpha" state.


EDIT:

I somehow couldnt understand the huge difference of world vertices and ive also noticed something strange which seem to got confirmed now. I just dont know if its only on this hardware.





Same i´ve noticed when creating/increasing map geometry within the editor, sometimes its correct vertices sometimes its way more as it should be. Sadly i cant check on more devices atm, so it would be nice if a few of you could check Mr.Floppy´s version out and go into that exact corner looking to the corner of that wooden box (writing us the wvt/wqd stat amount you see right bottom).Please restart the game a few times, to check if its consistent. Would be really important, if it would be an issue which appear randomly and not hardware related we would be fucked up, when comparing Map Designs.

[3XIX]

Update:

The geometry issue occurs randomly, on different maschines with same client, checked on ver. 1.3.0.1 and 1.3.0.2 ,someone would have to look at it if possible. 

To the map design, i´ve read the assault cube docs for mapping and asked myself if im completly dumb, and maybe there been to much enthusiasm, while finding out that AC Editor supports UV scaling, its not even needed to use that high resolution textures, again didnt knew. I´ve also checked how things been done in past for wooden boxes as example, and i saw that we both basicly moved a stick up our ass when looking how simple it could have been (without models/clips and even better having bulletholes displayed) 

I tought about it and remembered you cut of faces from the container, and its right why would we need them all aslong we wont make every side different in decals etc. 

So let´s forget about all the nonsense and use the geometry itself.
Still please dont expect a map release within a few days, i have to get into the way of creating within Cubes Editor now and have to create some different type textures, which can be used later in other maps aswell...choosing some cubes and selecting the texture, as you said still allowing editing on the fly for everyone.

Dont be afraid, i dont stop until i´ve done atleast one map, the idea is to create a few more.
Some more seamless containers and neutral in theme (if wanna be done in other maps)
Textures are 1024x1024 (possible due to UV scaling, still as usual the closer you get the less detail, pretty much like holding your hand 5cm infront of your eyes...things become blurry even in reality)

[Mr.Floppy]

Hehe, sounds like you got it now. Welcome to cube mapping! :)

You usually will always try to build the majority of your map with geometry and only use mapmodels when geometry isn't sufficient to resemble what you want to create. Mostly when things need to be fine and detailed rather than bulky and square-ish.

Actually, for the most time mapmodels used to be the only way to get higher resolutions. I guess that's what you still had in mind. But with v1.3 we've finally put that constraint to history and even can edit all the assets of a map on the fly in the editor now. One of my favourite new features.

It's quite a joy to use custom assets now, especially mapmodels which can be attributed and automatically added to the editor menus. Great stuff. All in all there's plenty of new possibilities when it comes to mapping and 'high' fidelity visuals are actually feasible these days, except for lighting though.

Talking about lighting. I guess what you experience with the different values is caused by light entities. As far as I understand light entities require the impacted faces to be subdivided and thus raise the amount of world quads. That's where /ambient comes into play. Using a sensible ambient light value allows to keep the amount of light entities low, which results in better performance.

Thinking about it, it would be nice if we could exclude areas from the ambient effect using tags, just like the clip tags. This way you could have indoor areas lit differently, darker that is. Those areas usually would be concealed by solids anyway. Maybe worth a feature request...

Anyway, I'm looking forward to your map, but don't feel hurried, I'm a patient person.

----- Edit -----

There's something I somehow kept forgetting to mention in my previous posts. AC has an auto download feature for custom content, as you may know, which however is limited to 2MB max per package. Package meaning:

• Textures: single image file
  
• Sounds: single sound file
  
• Mapmodels: the 'lowest' object folder containing all skins, config and the md3 file
  

You should keep an eye on that, so players won't need to manually download the files somewhere. Unfortunately we have no frontend-service for the package server at the moment, so you will have to reach out to XRD (pm, discord) and ask to upload your contents to packages.cubers.net.

[3XIX]

Hehe, sounds like you got it now. Welcome to cube mapping! :)

You usually will always try to build the majority of your map with geometry and only use mapmodels when geometry isn't sufficient to resemble what you want to create. Mostly when things need to be fine and detailed rather than bulky and square-ish.

Actually, for the most time mapmodels used to be the only way to get higher resolutions. I guess that's what you still had in mind. But with v1.3 we've finally put that constraint to history and even can edit all the assets of a map on the fly in the editor now. One of my favourite new features.

It's quite a joy to use custom assets now, especially mapmodels which can be attributed and automatically added to the editor menus. Great stuff. All in all there's plenty of new possibilities when it comes to mapping and 'high' fidelity visuals are actually feasible these days, except for lighting though.

Talking about lighting. I guess what you experience with the different values is caused by light entities. As far as I understand light entities require the impacted faces to be subdivided and thus raise the amount of world quads. That's where /ambient comes into play. Using a sensible ambient light value allows to keep the amount of light entities low, which results in better performance.

Thinking about it, it would be nice if we could exclude areas from the ambient effect using tags, just like the clip tags. This way you could have indoor areas lit differently, darker that is. Those areas usually would be concealed by solids anyway. Maybe worth a feature request...

Anyway, I'm looking forward to your map, but don't feel hurried, I'm a patient person.

----- Edit -----

There's something I somehow kept forgetting to mention in my previous posts. AC has an auto download feature for custom content, as you may know, which however is limited to 2MB max per package. Package meaning:

• Textures: single image file
  
• Sounds: single sound file
  
• Mapmodels: the 'lowest' object folder containing all skins, config and the md3 file
  

You should keep an eye on that, so players won't need to manually download the files somewhere. Unfortunately we have no frontend-service for the package server at the moment, so you will have to reach out to XRD (pm, discord) and ask to upload your contents to packages.cubers.net.

So, things became even worse as before.
While we would safe diskspace with geometry (not less than models, explain later) we will have the problem of having less variation, when making a wall with geometry and applying a texture onto it, it would display a container (in my case 8 cubes high) and after that it would "redo" the same, leading to same color containers in height, i found a way around that by just putting 2 containers colors on top in a 1024x1024 texture, still that reduces the quality more and isnt really the solution aswell.

Then there is the thing which will become an issue for further steps, when a texture is asigned to a wall, it well also asign it to the left and right face of the first cube, technically it wasnt a problem when i made the first containers, i just made them so that they fit seamless like the container would have 4 exact same corners, why thats a problem now, well it all isnt when graphic doesnt matter, but for the project and the detail i had in mind when starting this its not possible this way. I looked at my first screenshot i posted in here and no matter if yours or my versions which came later, all been worse in graphic, not because of lower textures, mainly due to having less variation due to less different container faces/color and probably the biggest part of all shadows, which represent that there is lighting in the scene, obviously the first screenshot with shadows we came across the shadow problem which appiers with models over "head/camera" position but for me thats not a reason to not have shadows, cause high res textures but no shadows...then we wont have to start updating graphics.

Now lets see what i´ve had done, and remember i sometimes searching for hours to find container textures, adding them, then finding out their shit and wouldnt fit into the theme (the more you change colors with photoshop the more unrealistic it gets) basicly the yellow container is best example, that was grey first same as some others like the red container which was pinkish, so things often look simple and i understand...containers what could take so long...well besides color even the container build in reality makes a difference if doesnt fit to the others placed. And yea, i also have a job and not that much time to spend on it. Following screenshots should be seen as more tests, this engine causing alot of trouble, you might also noticed.

The clean "neutral" container where i tought it could fit, lacks huge detail in colors, specificly for a map based of containers.



Now we have containers back with more color differences and it already gives a much better feeling but however you quickly notice the different red containers with shiny red stripes, thats an example of having not fitting ones for the scene. But what else is missing, or what does the brain say...containers but no door face? If door face, no back face? left and ride side looking same? And the overall feeling that the light itself might fit to the skymaps but not having darker spots or in other words shadows...and obviously all containers seem to be in line way to perfect.




Also the geometry issue happens without any entity placed, no light whatsoever, technically i dont know what happens anyway if the choosen walls getting merged, cubes s 8 verts each, lets say selecting 1x8 line if it would keep the verts then it would be 8x8 verts, so basicly 64verts only for that wall-line (maybe only 8 but with triangles) but again dunno the code for that.

To the part of having ambient lights excluded from specific parts would help for some "indoor" maps but i believe turning it the other way around could be better performance wise, meaning not using light entitys only ambient light and darken the spots where you wouldnt have light in reality, pretty much like shadows, since its basicly that in reality

I also dont know if shadows could be fixed for a map like this, besides that it would always double vertices, leading to higher gpu usage (scales with hardware).

Stencil shadows, you notice some container faces are darker others light


Now my idea, which might would lead to around double diskspace needed, but still not doubled vertices
And yea might be a pain to do it for a full map, but we sadly cant bake lighting/shadows in here (you should see some baked exr´s from some games, they eat up 200MB for a map)



But as you see i would need all container faces seperate to add fake shadow to it, for models you could simply render the model and using its oppacity and placing it on the specific surface/ground.

My plan now is to combine my first method with your method, i believe thats the only way to get shadows, obviously 4k was never needed, scaling it down to 2k will do a big difference and im pretty sure even with fake shadows we max end up with 10 MB, single files obviously wont reach 2MB (i think only some 4k textures with 100% detail level could) or if they´re not jpg, but for things like skymap we can "trick", there it obviously makes a difference having 512x512 vs 1024x1024 but 2048x2048 should be the way to go there (we can cut the bottom of to effectivly have 2048x1024 as ive stated before and you can check, if you have an 2048x2048 color texture and you make 50% of it black it also will shrink in diskspace while still beeing 2k. Skymap was around 5MB down to 900kb.

So if someone thinks that 3 or 4th version? is good...and you wouldnt want shadows, just write it...but for me its not how it should be [funny when created by yourself^^] 

It been a learning process so far, next version should be better

Edit:

Here is why fake shadows would be a problem when using geometry to display containers, wont be able to only overlay a shadow to the "face" or side

[3XIX]

I think there been a logic flaw when thinking about the container map beeing good for performance, while obviously model wise and based on vertices and models needed (cargo normaly looks pretty empty in reality aswell) i didnt had in mind that we´ve "world" weapon models and characters to calculate aswell.

Also im to used to other engines and their "newer" methods, still the most important method for this engine i didnt found instantly, it needs to be present for everyone who wanna create maps.

The method im talking about is "solids", its really powerful to be able to stop rendering objects behind a wall, specificly if it had been done in many maps before (maybe not perfect, or as much as it could be) but still creating hallways etc. with that in mind is game changing, creating corners 90° and not having a too far view, to understand the impact better, some screenshots


32 characters, weapons etc. beeing rendered behind the containers.



Also 32 characters but "solid-walls" and on top of that i placed dumpsters every few meters (around 350-400 verts) and we´re below half vertices for world and enviroment.

Im really frustrated now, if i knew it could be done, i wouldnt have started an "open-field" map design.

However the map should be still good for some (obviously huge performance drop the more players there are on the map)

If someone wanna test it for singeplayer, keep it, change it...idk
https://workupload.com/file/UXwV89wNMWC