It was his idea to compare it to yours. I made the claim it is the most advanced because it is the most advanced. If there were more advanced ones after 20 posts someone would have linked to them, but they cannot because no such thing exists.
What you've created is nothing special. It's not hard to make realistic physics based engines. You didn't even attempt to create a .obj file importer - which isn't hard.
Good job (sarcasm).
Do you even read pony. I made an obj importer a while ago. The purpose of this is NOT loading models. It's a physics engine, loading models is trivial and irrelevant to the purpose of a physics engine. Why would I waste time reinventing the wheel for trivial non-essential things? Would you prefer it if I used simple blocks like the other one? No, they you would complain about the graphics, because for some reason that has some unneeded importance.
"It's not hard to make realistic physics based engines"
Really now? Why then are there no GM games with them? Because its hard and especially hard to have them with a decent frame rate.
GM Engineer produces racing games with small maps, 2d flat roads with 2d physics, and yet still somehow manages to have laggy unplayable framerates. And he continually asks that his unfinished games get featured, I find it cute and humorous. I haven't tried his flight sim yet maybe he had better luck with the framerates there.
I played the forest game in the video, the physics are completely 2dimensional. The game maxes at 5 frames per second, completely unplayable. GM Engineer's physics model needs a complete redesign, whatever he is currently using is much to laggy to be ported to 3d.
I doubt that his engine is 3d for several reasons. One reason is because all of his roads are flat, which is to hide the fact that the base engine is really 2d, otherwise why would he hide the engines best features? He also includes 3d cone physics in one of his games, but this is probably to hide the fact that the car physics only work in 2d.
Now if his engine really is 3d (which it probably isn't) there are some more problems. Even at a high framerate you'll notice that both of the videos feature low-speed sedans. Whilst you may be blown away by the HD looking presentation and nice looking suspension on the car you will find that the actual velocity of the car is rather low speed, and not at all suited for a high speed racing game. The dirt road is there to mask the fact that the actual physics of the engine is unsuited to high speed racing. In short, there's much added fluff like fancy graphics and shader effects, and added in suspension effects to mask the fact that it's not a high octane racing game. Now if the physics really are 3d, and for some reason he just added in totally flat roads for no good reason, having 3d physics does not necessarily make it game-ready. For example, 3d Rad has a 3d racing physics engine but its absolutely rubbish for game development, the car physics are ridiculous and theres severe input lag. No serious developer would ever consider using it.
"your engine physics are fake 3d"
No they are not "fake 3d." You do drift differently on the slopes, if the car is not sealed to the ground the car slides down slopes. It's very easy to spot but not if you do it deliberately, because there is a such thing as a car brake. If you are slow on a hill the car automatically brakes so you don't roll off it. I did this for developers who were interested in using this for games where you can exit the car. It's really annoying in free-roaming games to exit a car and have it roll down the hill, it's quite unrealistic. However, if you are on a hill and the car is not sealed to the ground the car will slide down it. Your conclusions that these are fake physics are simply untrue. It's easy to spot also, if you travel up a hill at low speeds with low momentum it is much slower than either a flat surface or high momentum. Try it on the terrain, you'll notice that you go slower up hills.
"The earlier comment about the steering being too sharp at high speeds"
Reason is in race cars they have a thing called "race steering". It's a safety feature that increases the steering wheel weight and makes turning much smaller of an angle. Instead of yawing the wheels at 30 degrees, it increases the steering wheel weight so the driver can only yaw them at 5 degrees at high speeds. Otherwise the car might flip out. I am a bit torn, since computer mice have no force feedback or weight feature how do I go about this. Should I add a "flip out" animation if the car turns too sharp at high speeds, or do I just lock the steering to a reduced angle at high speeds? The reason it feels weird to you and "too sharp" is because you are expecting the car to flip out and it doesn't, it just continues steering like crazy taxi or one of those fast moving older films, lol. I suppose the third option is that I make it mega-drift when you turn sharply (I already programmed it to do this, but for some reason it doesn't seem to be consistent, which is why I am labeling it as a minor glitch for now.)
these claims really weren't that bold, there really isn't any competition. Still waiting on links to prove me wrong, so far I've dispelled all the contenders.
And now you're just trying to sound smarter than you are If you're talking about z-fighting between the terrain and the 3D primitive you draw to represent the road, you can solve that by just drawing the polygons slightly above the ground (znear should be enough in Studio, aka default 0.01 above the ground, but in GM8.1 you need to use 1 pixel above the ground).
And if it isn't that... what problems would it cause, more exactly?
It has nothing to do with z fighting and it's really simple. A Gm path is like a spline. You generate a polygonal road from the spline. The problem is that road is polygonal, and the spline is curved. Your collision plan was to retrieve them from the path, not the road. The collisions will not match up. The car will retrieve data according to the spline, not the rendered road on screen. So you will see artifacts, like the car appearing to go through the road itself. And this is exactly what you see in Snidr's Racing Friends (though in his instance I am not sure if it is exactly because of this reason, or simply lazy or incorrect collision maths.)
It's not a matter of "road matching terrain" its a matter of "car matching road."
Now you might try and circumvent this problem by either making a hyperdetailed road to match the path. There will still be artifacts and it will just make the game lag more from the detail. So then you might have the bright idea to instead, make a non-curved path. However not only is this tedious but it rarely looks nearly as nice as an automatically generated road from a curved path. I mean, you might as well make the track by hand, then. Also I have a hunch and I'm fairly sure you may still run into collision problems from using this method, for example the edges of walls. If you use the equidistant approach you will collide into edges of walls that don't exist. You see when you generate a road using triangle strips it kindly makes walls on the outside of curves longer than ones inside, which is nice to render and good for gameplay. But this data is not easy to obtain from simply checking the spline. You would actually have to make a spline seperate from the path that contains additional data containing the length of each wall on left and right. At this point you might as well just go with my original technique of polygon checking because you wont be saving any speed.
If you use bilinear interpolation along the four z points of the polygon's corners, you can do it in linear time
And now you're trying to sound smarter than you actually are. Why the hell would I need to use bilinear interpolation? That would just add more unneeded lag. It doesnt even solve the lag probem, the "polygon" is really just a line. The edges of the walls are defined as lines, 2 points in order to both reduce the amount of ds_list calls and jump on GM's built in collision_line routines. (Built in routines are usually speed boons.) what you propose would save no time, not even linear time (Whatever that is supposed to mean in this context?
Edited by GreatandWiseOne, 14 May 2015 - 10:10 PM.