News:

Herr Otto Partz says you're all nothing but pipsqueaks!

Main Menu

Bridging ReplDump + R5E for cool multiplayer replays of (live) races

Started by Cas, March 15, 2023, 07:15:24 AM

Previous topic - Next topic

Cas

Introduction
 >:( I'm very upset because I lost everything I had written when I was trying to upload the image file by dragging it. Recommendation: if you're going to include an image, do it first, then type!  Otherwise, just do it by "browse" button. Avoid dragging.

Now to the point. Feel free to skip sections that you're not interested in. I guess some of you will want to know the whole thing, but most will want to skip the part of the coordinates and angles, so I've marked those as "hardcore".

What this is about
I've been working on a project to create a bridge between ReplDump, which extracts detailed information from replays, and R5E, my graphics engine. This idea came from Daniel3D and Duplode has been helping me by providing ReplDump source code and explaining the game structures. I'm thinking now that the possibilities here are so great that this definitely deserves a thread.

My work today
So... this evening I began by looking at my R5E code and realising I haven't commented it well enough. After an hour or so of examination, I found where to plug my new code. I created a new routine to allow for loading of car shapes. Until now, the engine was working exclusively with track element shapes. The difference is minor, but a special routine was necessary. I tested and it works well. It now renders cars at any desired paint job. No wheels for now, though.

You'll notice that some track elements, such as the tunnel, result in glitches. This is because, while I'm using a painter's algorithm, same as Stunts, it's impossible to guess the exact details of another such algorithm and some of the shapes rely on these details. This can be solved by switching to Z-buffering or by recreating some of the track elements in a way that won't produce the glitches. But let's leave that for later.

Beginning to explore the output of ReplDump (hardcore)
With this working, I started to examine the source Duplode gave me, with the game memory structure and creating test replays to carefully analyse the binary that comes out of ReplDump. I quickly found where the current car coordinates are. However, there are two sets of them, very similar, but not quite the same. Don't know why that is, but taking the first set should work. Right after that, comes the rotation values and there's a funny comment in the source code stating that this is a source of confusion. After some work, I found out why it appeared confusing.

Explanation of the angles used inside Stunts (hardcore)
Stunts works with Euler angles in the same order as my engine, which is the most logical thing to do in a cars game. But it has some curious quadrant representation. First of all, azimuth, that is, the rotational dimension that's change with yaw, always takes precedence. This value is always zero or positive and goes from 0 to 1023 on a full turn. It grows counter-clockwise. Now comes the interesting part.

Banking/roll is the last angle and 0 is what you get when the car is standing. If you roll to your right, the car will bank left and this value will get negative until you're upside down at -512. You'd think that it'd now wrap around, but no, it continues to grow negatively for another quadrant and when it gets to -768, it becomes +256, which means 90 degrees of banking right.

I've saved the middle one for the end of the explanation because it's what I believe caused most of the confusion when this was first inspected. Say you're approaching a loop. Your pitch is 0 because you're standing on the ground, but then you begin to climb and pitch grows positively. When you're around 67 to 70, you're climbing at a typical ramp angle, which I think is 30 degrees. When you get to 90 degrees, this value is +256. What happens past this seems crazy, but is very simple if you think about it. As the car continues through the loop, it's not really climbing anymore. It's pitch is now decreasing, but its yaw and roll have suddenly both been inverted. This has to happen because azimuth is the main angle. So now pitch keeps going down and it becomes zero again when you're upside down. As you keep on moving, it becomes negative because now you're going downhill, even though inverted. Then you reach the point when you're looking straight down and roll and yaw suddenly get inverted again and pitch is still negative, but begins to grow until it reaches zero again at the end of the loop.

What we will be able to do with this
Being able to connect these two tools means a lot. I means, for example, that we will be able to take a set of replays run on the same track and render a video of all cars of different players together, running on the track in high resolution. It also means we can place a camera anywhere we want on a track and create a replay from a perspective that wouldn't be possible natively in Stunts. Needless to say, we'll be able to generate pictures combining cars and track elements in hi-res very quickly. It also is a first step in doing something useful with the engine for the first time!

Questions or suggestions?  Shoot. Also, I'll keep you posted on whatever news come up!
Earth is my country. Science is my religion.

Daniel3D

My mind functions a bit differently from most people apparently. Even now, while I have medication to dampen the effects, I still have more plans, ideas and whishes than I can handle.

The above story started about 40 hours earlier with the following message to duplode..
Quoteok,
brain fart.,.

i still had the lambdacube-stunts page open and rememerd there was an youtube video of it.,

then i noticed that the lambdacube-stunts is only yhe graphic engine and they added bullit physics to it to make it drivable...

so i was wondering......
is it possible to process cartography data through to generate high res stunts footage..

(i guess the answer is yes but it is a lot of work to make it so...)

in the same line, could we use CAS his graphic engine for it?
so not for actual racing, but to process replays through,

That snowballed quickly after that.   8)
Edison once said,
"I have not failed 10,000 times,
I've successfully found 10,000 ways that will not work."
---------
Currently running over 20 separate instances of Stunts
---------
Check out the STUNTS resources on my Mega (globe icon)

Overdrijf

That looks really cool. The draw distance, the detail! The Melange flying without wheels! ;)

It almost makes me want to start remaking track 3D models with a higher polygon count. Almost...

Cas

 8) Drawing wheels has been a pain and I haven't managed to find a good way to achieve it yet. Removing the artifacts on some track elements will be easier. One thing I know how to do, but probably will leave for later too because it's kind of annoying to do is having animation like windmills and Joe's.

It was great that Daniël came up with his. I hadn't thought of this possibility and it's really very feasible.
Earth is my country. Science is my religion.

Daniel3D

There are several on here that are capable of adapting a model.
Edison once said,
"I have not failed 10,000 times,
I've successfully found 10,000 ways that will not work."
---------
Currently running over 20 separate instances of Stunts
---------
Check out the STUNTS resources on my Mega (globe icon)

Cas

Thanks. I'll try to first get this working and then, we'll tune the fine details. I guess some adaptations will make it look much better then. One thing I specially dislike on the current look is how the black lines inside tunnels can be seen through the walls.
Earth is my country. Science is my religion.

Overdrijf

Quote from: Cas on March 16, 2023, 01:52:37 AMOne thing I specially dislike on the current look is how the black lines inside tunnels can be seen through the walls.

Also there's no roof on the front one.

Might be something with the Z-bias or with polygons set to 2 sided. Or maybe something with the rendering of lines (which would be harder to fix, but we could try replacing the lines with thin polygons specifically for the rendering model set.)

I'll have a look at the tunnel model, see if I can find something.

Daniel3D

It's not for in game use, so the lines can be removed completely.
Same with the barn. We can remove the lines and use white polygon strips. Looks better for video.
Edison once said,
"I have not failed 10,000 times,
I've successfully found 10,000 ways that will not work."
---------
Currently running over 20 separate instances of Stunts
---------
Check out the STUNTS resources on my Mega (globe icon)

Daniel3D

CAS, what would be the simplest way to fix it?
In other words, what is practically causing it. Explained in a few sentences  ;)
I think that it is the lines in general, but I'm not sure.
Edison once said,
"I have not failed 10,000 times,
I've successfully found 10,000 ways that will not work."
---------
Currently running over 20 separate instances of Stunts
---------
Check out the STUNTS resources on my Mega (globe icon)

Cas

Alright. I'll try to explain. Some details are not that fresh in my head because it's been several months since I was last working on the core of the engine... maybe a couple of years, but it goes more or less like this:

To properly sort and draw, Stunts engine has several tools: 2-sided/1-sided polygons, Z-bias, culling flags and sorting polygons by distance. My engine does not have culling flags, but it supports 2 bits of Z-bias instead of 1. Polygons are first converted to triangles and then sorted.

The idea in both cases is the same, what's called a Painter's Algorithm. Polygons that are further away are drawn first. The problem with this is that two polygons may be overlapping in terms of distance. If you take the nearest point or the farthest point or the middle point in a polygon and measure the distance to the camera, then you sort and you will not get the same order, so even though all of them make sense, not knowing which is being use by an engine will mean that some 3D objects will look somewhat different on different engines. Besides, because I split polygons into triangles before sorting, there's a chance that Stunts doesn't. It sure does split to draw, but maybe distance is taken before that. So that adds another possible difference.

Another problem happens when you have two polygons that are one directly on top of another. This is what the Z-bias is for. In Stunts, you have only two layers. My engine allows for four layers, so you can have a polygon with another on top and another on top of that one and so on, four of them. You need to tell the engine which one is on top and that gives priority. To me, it was clear what this meant, but when I apply what was obvious to me, it looks like Stunts uses it differently.

It is possible to designe track elements in a way that they are compatible with any Painter's algorithm. It's more restrictive, but it's the "safe" way. I suggest not making any polygon 2-sided unless this is really needed and make all polygons strictly convex. If you're going to draw a concave polygon, use two polygons. This guarantees (almost) that it will look good.

What I can do is give my engine a configuration file that allows you to add an object that you create so that you can test with the engine to see how it looks in it.
Earth is my country. Science is my religion.

Cas

An update. I recorded a replay on Napalm and dumped the output from it. Now I'm reading it and scaling the output into my engine. At this point, the engine can only rotate objects around the vertical axis because this is sufficient for track elements. I added the car as an extra track object, so it can't rotate in the other two ways, but that's easy to solve.

For now, I'm trying to calibrate the coordinates. Taking them from the dumped information and just scaling them, I can't find a good scale. The best number I found so far is 33800. What I mean is, I grab the X, Y and Z from the dump and I have to divide those by 33800 to more or less get the coordinates in my engine's system (which is 1 = 1 tile). Using this divider, I can see the little Melange racing through the track and it clearly follows it, but there's some offset sometimes. Besides, 33800 is a really ugly number. I expected something like 32768, but no. So my conclusion is there must be some offset, some absolute value I have to add to the linear equation. In other words, (0, 0) in Stunts does not mean the point at the corner of the track field. At least, no when taken relative to the centre of the car. Any ideas?

Rotation around the vertical is perfect. I converted it to radians and it works just fine. It looks like I'm going to have no problem with that.

I'm having some extra difficulty, but it has to do with the design of my engine so far, which is only prepared for track elements. Sometimes, the car is drawn before the road it's on. I can fix this by forcing all cars be drawn after all track elements. This will have the side effect of the car being sometimes visible through track elements. Where have I seen this before?

Anyway, the Painter's Algorithm sucks. It appears simpler and faster, but you have to do lots of things to make it look decent because deep inside, it really never is. It is very tempting to just completely switch to a Z-buffer-based engine core, but I guess that's for later.
Earth is my country. Science is my religion.

Daniel3D

QuoteIt is possible to designe track elements in a way that they are compatible with any Painter's algorithm. It's more restrictive, but it's the "safe" way. I suggest not making any polygon 2-sided unless this is really needed and make all polygons strictly convex. If you're going to draw a concave polygon, use two polygons. This guarantees (almost) that it will look good
You mean, make all polygons triangles?
Edison once said,
"I have not failed 10,000 times,
I've successfully found 10,000 ways that will not work."
---------
Currently running over 20 separate instances of Stunts
---------
Check out the STUNTS resources on my Mega (globe icon)

Duplode

Quote from: Cas on March 17, 2023, 04:31:49 AMFor now, I'm trying to calibrate the coordinates. Taking them from the dumped information and just scaling them, I can't find a good scale.

The conversion factor between tiles and carstate coordinates is exactly 65536 (2^16), with no offset. That is what I use in Cartography, and it works perfectly. Any divergence from that probably originates from how track graphics are scaled in the engine -- besides the extra factor of two there seems to be somewhere, one thing I can think of right now is how 3D shapes for track elements are usually a little larger than a tile, which is exactly 1024 x 1024 in Stressed units.

Cas

Thanks. Yesterday night, after had posted, I actually found it. My engine wasn't using 1 = 1 tile, but 2 = 1 tile. This is because I wanted the "radius" to be 1, that is, so that track elements that fit in one tile would have a max radius of 1. I had forgotten about this. So I made a little track to measure more precisely and recorded a replay in which I was driving on the centre line. Then I assumed 32768, which was the closest power of two (this to 2 is like 65536 to 1, so it's the same) and I got an offset of -1. I'm pretty sure now this has to do with how I loaded the elements on top of the track, so with this, problem solved.

Now I'm having another issue, this time, with rotation. I look at the values and yes, the angles are correct, but when I rotate the car, obviously I'm doing something wrong because it looks super weird in some combinations. I tried inverting the order of the angles because it's being done prior to camera rotation, but that doesn't seem to be the problem. I'll keep on researching.
Earth is my country. Science is my religion.

Overdrijf

Quote from: Daniel3D on March 17, 2023, 07:54:19 AM
QuoteIt is possible to designe track elements in a way that they are compatible with any Painter's algorithm. It's more restrictive, but it's the "safe" way. I suggest not making any polygon 2-sided unless this is really needed and make all polygons strictly convex. If you're going to draw a concave polygon, use two polygons. This guarantees (almost) that it will look good
You mean, make all polygons triangles?

Or at least make all polygons in such a way that they will still look the same if the program automatically splits them into triangles.

This is pretty good car design advice in general. If doing triangles is too much work you can use rectangles, but make sure all of them are actually flat planes, there's no two ways about interpreting them. In other words: if you would replace the rectangle by two triangles split along the line from point a to point c the resulting shape would be exactly the same as if you used triangles split along the line from point b to point d. Concave shapes, think Pacman, are also a "bad" practice. If the program tries to automatically assign triangles to replace that shape the mouth is probably going to be fully or partially filled in.