Really nice!! could you tell us how it works? Is it from the material name you define on a face of "Colmesh-1" that define the ground model? does it work with the name in capital later or by id? I'm asking because I'm going to have sh*t lot of work with my gta map.
I'm more hyped for this blogpost than the update. It seems for years you guys have been very hush hush at what goes on behind the scenes, and now for the first time you are opening up a little bit about your company's past and future. This is the kind of developer transparency that we love.
I want a high resolution download of the artwork. Looks beautiful as a wallpaper... or anything really.
here ya go http://www.beamng.com/threads/something-is-on-the-horizon.21667/page-4#post-329104 OT: im hyped for the blogpost and the update. this blogpost should be a fun read when its posted.
The more I think about it, the more I think that someone's "horizon = larger maps" theory holds water. Even though I know it's stupid to think it refers to anything more than a blog post, it does make a certain kind of sense. Remember how Utah was apparently put back on the shelf because of "T3D issues". Remember also that one of T3D's issues is having a 2GB? hard limit on heightmap size, meaning that if you want a map larger than 4 klicks square, you have to sacrifice detail/resolution. Perhaps the devs originally envisioned Utah as being an extremely large map, with fairly flat terrain and sparse scenery - a fairly typical "deserted desert road where you can go as fast as you want". But then, they realized that the heightmap size limit would make it difficult to make the roads as long and straight as they wanted, and the sparse scenery and terrain would make the small size of the map too apparent by increasing the maximum effective sight distance. They could decrease the terrain resolution to get more area out of a 2GB heightmap, but perhaps they considered any such sacrifice in resolution to be unacceptable for official content, or perhaps Utah was intended to be of such an extreme size that the required resolution decrease would have made the terrain visibly "polygonal" and of generally low perceptual quality. So they put it back on the shelf and focused on smaller maps that either were more "closed-in" in terms of scenery and terrain or weren't so dependent on size to live up to their concept. Now, perhaps, they've managed to increase the maximum heightmap size in Torque3D (remember that, at least, tdev is apparently involved with the Torque3D project), allowing Utah to live up to its original concept. If this is true, it's probably been either true or in the works for quite some time now; remember that one of the dev threads, as I recall, showed what could have been Utah progress several months ago (in fact, I was the one who added that to the wiki).
It's probably okay to speculate, so long as we understand and clearly communicate that this is little more than speculation. Not as though that will keep the mindless minority from shouting everything we say from a street corner as fact. One issue with this theory is that terrain block resolution isn't the only limitation when it comes to big levels in Torque; there's also some pretty wicked floating point issues that come up after about 2-4km from 0,0,0. Mostly in the form of z-fighting and a subtle jerking of the camera's position (most noticeable in-cab). In all other respects, however, you have a point. Most of the reason that East Coast USA feels as large as it does on a ~4km2 map is that the roads are compressed, often running directly next to one another in parallel with no direct connection or line of sight. In an open desert, that's realistically not as easy to pull off.
If what you say about ECA is true, that's some pretty nice level design work. Though it kind of goes along with what I was saying; the more of a map you can see from one point, the smaller it looks. On ECA or even JRI (conjecturing, because my computato can't run the game at all), you can't see any one side of the map from the other, and may have difficulty seeing any point not on whatever road you're currently on. With a wide open desert, even if another road was the maximum theoretical distance of 1.24 miles away, it would still look pretty close-ish, which would ruin the immersion. Also, could you explain in layman's terms what z-fighting is? Is that where the textures jitter and turn half into seizure-inducing gray jaggies because the game can't figure out quite where they go? Also, with those issues in mind, how do fan-created large maps, like Desert Highway, or long maps, like Endless Highway, work?
Indeed; the level design is pretty great. And I pity you on the computer end, as you are missing out on some great roads. Z-fighting is... well, pretty much as you describe. The rasterizer (what turns raw data into shapes and colors and the like) sees two surfaces, and if they are too close to one another and overlapping, the game can't decide which one should be in front. Thus, it chooses the only wrong answer in that scenario: both of them. This can be mitigated with a more powerful rasterizer, which can create more steps from the camera to the max viewing distance, but at the cost of performance. There are other tricks, but I'll just give you the links: https://en.wikipedia.org/wiki/Z-fighting And a nifty little toy I found on the Outerra forum: http://threejs.org/examples/webgl_camera_logarithmicdepthbuffer.html As for mega-maps, I guess it just may be the perfectionist in me (or the 3d artist) causing me to too easily notice small details. These effects are pretty minor nuisances to a normal, sane person.
So, basically, it's computer performance itself that's limiting map size. So then how do other games, which seem to use full mesh maps, handle large distances?
You could handle such things with moving-everything-around-the-camera instead of moving-the-camera-around. Don't even think that performance is the issue. More likely troublesome is to move 2000 beams and nodes around the camera instead of just 1 camera while still enabling it to crash into things.
a floating origin. Minecraft for example had *HUGE* issues with maths as you moved away from the spawn, culminating in "The End" map generation where the terrain generation itself turned into, well, technical description here, "Janky as fuck". As a result, you move the origin of the game world, tada.
Technically that's the farlands, not the end. If you want to see an example of floating point math self destructing in minecraft, go watch the latest episodes of "far lands or bust" by kurtjmac and skip to a point in the video where he is walking. You'll see lots of odd things. Actually, here's the video
I was think about minecraft far lands on beamng and I wanted to try it. I was surprised that camera shake are really noticeable about 20km. I tried to go further and it's like the watch dog effect. It's sad to see that the graphical engine is limited and the physic part is still ok. I think the game engine was made for fps game with small map.
I think t3d uses floats whereas the physics core uses doubles. Doubles are more precise and less prone to those kinds of errors than floats, but slower.