Yesterday, the grid limit was removed, and now large cards can be made not only in single player mode, but also in multiplayer. It’s very cool, but as I’ve been told by good people, Still, it is better to make a map 10km, I had in plans (or you have plans) to make a map for example 20-30km, but I was told then polygons, textures and so on will collapse, I wanted someone to transfer the map from gta v, it is larger than 10km, I hope by the release we will be able to make maps 20-30km or more. I apologize if I didn’t describe my point that way.
Is this a question, complaint or comment?
My friend said that if you make / import a map 20/30km+, then there will already be bugs, lost textures,Problems with polygons, when there will be for example 500 or 1000+ players on the server, perhaps this will be fixed. Let’s hope for the best.
Upd: there is only a floating point limit (if you make a map more than 10km then there will be artifacts like this), I hope this will be fixed for release, or earlier. @garry
That is not something that can be “fixed”
Maybe I didn’t say it right, sorry, I just wanted us to be able to make maps more than 10km, but until that’s not done, read my Upd.
My bad for sounding condescending before, but it’s not really an error to be fixed but a limitation. To “fix” this the developers would have the get their hands dirty into the engine to modify how coordinates fundamentally work. There are a few workarounds to this but idk. haha
So facepunch can’t change that? Will we only be able to make maps 10km no more?
Hopefully someone will find a detour, some…
Well, will they move the game from float to int32?
There is no way integer number could represent float, it must implement intermediate values for computing projections and other math. Technically float type is pretty similar to integer, intermediate values are encoded as integer and mantissa describes the range of these values, but as mantissa goes up, the accuracy of float number drops as the same integer would represent a higher range.
There is a 64-bit float type in programming, but the main reason why it simply can’t be used is that graphical hardware for games is mainly focused on 32-bit float computation and code using 64-bit floats would be slow or even couldn’t be supported at all on some video adapters.
I suppose a trick can be done for games to allow great computing precision - the coordinates of rendering geometry can be represented relatively to the view position when reporting to graphical API, that way the position of the view is always zero and all the geometry is located around the origin of coordinates.
It turns out that we can still make maps 20/30/40/50km inSo, we can still make maps 20/30/40/50km in s&box? Without loss of polygons, textures.
If it is possible to make a 10km map, then it is possible to make a 100km map.
It can be done simply, too… For instance, 10km map cubes - or even 5km cubes ( 4 of which makes up a 10km ) so as you enter a boundary of a 5km cube, the others load in… You’d want to be far enough away from the edge you don’t get pop in, and close enough it doesn’t cause performance issue…
You can also partially read the map so the entire thing isn’t loaded and stream the map - then it really doesn’t matter… But if there is the issue with artifacts because of an issue with the maps themselves, coords, etc… then they could just be split into small parts…
This can be done dynamically, or by the mapper.
There are a lot of ways around it. As for positioning - if there is an issue with positioning then more numbers can be added - x / y / z as integer + or - … move throughout a 3d array and based on position load other cubes around you.
This could even be done on small city block style sizes - make an infinite map of smaller maps.
I was looking into this on gmod, and it was possible because you could read a bsp file and render it so you’d only need an open bsp with the base physics, then as you walk around you render the details bsp on top. Since the BSP system was slow, the areas had to be small but it was an option. Another option was to dynamically create the map ( someone is doing that right now and they want to bring that to S&box ) and not difficult. There are a few other ways…
But if it was possible in GMod where we had a lot less control, then it will be a lot easier in this game where we have a lot more even if limits are imposed to start by setting up a simple 3d array and streaming maps, or whatever…
It would be better if this was in the back-end though. A simple definitions file could be created and a simple tool to create the definitions file and layout a map like this wouldn’t be hard to make - use hammer for the normal maps, etc… then assemble them with another tool… then in the back end just handle how the maps are loaded / unloaded… if the map files are structured better than Source 1.0 then streaming them may be better and that would be easier.
increasing map limit is hard especially source 2 where some of engine mechanic are same as source 1.
Source 2 is based from Source 1.
and no 10km dont mean it can also 100km.
and no changing float to int32 will just bring more problem, look online how hard it is to change engine code.
and just removing the grid is not enough there is still lot of problems.
they are finding alternative from increasing the map limit because they know that they can’t increase it as they want with all bugs fixed and mechanics working.
they have LOT other priority that this.
if u want big map, then level streaming and networking tweaks (like town game mode, where you stay at the center on the map but as you walk, the rest is generating while you are still staying at the center ) is the only way. infinite map and player is just false and misleading, everything has a limit.
and if u want map as big as gta 5 , go to another game engine because source 2 is not made for open world map and you will just have 1fps
why bother increase map limit if the engine cannot handle and optimize big maps…
So, at the release, we can still make maps 20/30/40km+, without missing textures or polygons, right?