Stunts Forum

Stunts - the Game => Stunts Reverse Engineering => Topic started by: Cas on January 23, 2021, 07:38:47 AM

Title: Camera placement
Post by: Cas on January 23, 2021, 07:38:47 AM
I decided to make a thread for this even though it's not really useful like resolving the opponent's path is. I previously found a solution to how Stunts decides where to place turning signs and at that time, I tried to solve this, but I couldn't. Uhm... maybe there already is a thread?  I couldn't find one. Anyway, if there is, let me know :P

Here's the riddle: How does Stunts decide on the placement of the cameras for F4 view?  I've been making tests and, by placing objects around, it's easy to see where the camera is placed if you follow a replay. But I haven't been able to find a way to predict this. I should have written down what I had tested, even though it was not a solution. It's not as simple as the corner sign problem I resolved. Cameras are sometimes placed on top of bridges and if you count the number of tiles between cameras, it appears like you could predict it at first, but sooner or later, the track has to turn and with turns, all predictability is lost.

Anyway, I'll keep on testing, but if anybody has an idea to add, here we have a thread :)
Title: Re: Camera placement
Post by: Daniel3D on January 23, 2021, 01:17:43 PM
I always found the distance between two cameras to far apart but I did notice something long ago.

The camera locations are always the same for the same track so either fixed or based upon a logical set of rules.

Camera activation is proximity based, sometimes a camera from a adjacent piece of track will pick up the car.

I had a track named bridges, that had with clever use of hills a condensed 3 layer knot of road. The f4 camera was jumping quite a lot in that.
Title: Re: Camera placement
Post by: Duplode on January 23, 2021, 01:33:45 PM
The camera locations are always the same for the same track so either fixed or based upon a logical set of rules.

Yup, the game computes the F4 camera positions for the track upon loading and keeps it in one of the track-related data structures that restunts calls "trackdata". That was one of the partial results from my lost 2016 investigations.
Title: Re: Camera placement
Post by: Daniel3D on January 23, 2021, 04:05:01 PM
I will try to recreate the bridges track (or something similar) and plot the camera positions on the map.
(And check if there are differences in versions)
En post the results here.
Title: Re: Camera placement
Post by: Cas on January 23, 2021, 09:38:42 PM
That would be very interesting to see!
And yes, I had been researching on this earlier too. I wanted to find a rule similar to that of the signs, but it's not that easy. Once the cameras have been placed, Stunts always selects the one that's closes to you. What I want to know is how they are placed. It seems that, like with signs, cameras are only placed by roads that are parsed by the path-resolving engine. Therefore, if you drive off road or take a disconnected track, the F4 view will pick you up from very far away!
Title: Re: Camera placement
Post by: Daniel3D on January 24, 2021, 04:28:31 PM
Hi, i made a quick track with 3 lanes
Drove a test round on the inner 2 (so i miss camera positions of the outer one)

general impression.
camera's are placed about every 3 track pieces (regardless the size) i think,
jumps and overpasses have alternate positions. Long corners have them on the middle outside.

Title: Re: Camera placement
Post by: Cas on January 24, 2021, 08:04:16 PM
I've been watching your test and now I made another, trying to simplify things as much as possible. Look at my very strange results:

I first made a simple closed circuit and placed some scenery to help me identify where the camera was placed. Then, I removed the scenery that was not in front of a camera. From the first test, it seems cameras are placed every three track elements regardless of the element size, starting with the start/finish line, but for some reason, not including the last corner.

Then, I replaced one of the straights with a 1x1 split. That should make no difference, right?  Or maybe it will. Worse!  It doesn't make a difference at the beginning, but it does make later on. Without any logical explanation, the first camera positions are the same, but after the corner, all are displaced one position further.

The yellow markings represent the tiles within which cameras are set.

EDIT: I just made one more test replacing the split with a crossroad. The camera positions result the same as in the first case, that is, same as if it were a straight, suggesting that splits play a special role.

EDIT 2: Now I confirm that placing a tunnel there also yields a result like the first one.
Title: Re: Camera placement
Post by: Daniel3D on January 24, 2021, 08:55:45 PM
Did some easy clovers,
did each track twice by moving the start/finish.
a pattern is starting to show..
Title: Re: Camera placement
Post by: Cas on January 24, 2021, 11:20:22 PM
That's a good test!  So... it looks like we have this:

- Cameras are placed almost always every three elements, but occasionally, it can be two or four
- There is always a camera at the start/finish line and from there, the pattern appears to follow forward
- Changing an element without changing the number of tiles may or may not alter the distribution
- Even without any special element (just straights and corners), irregularities can occur

For your tests we have:
Test 1: 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3 (12 threes, including arriving back at the finish line)
Test 2: The same, also 12 threes
Test 3: 3, 3, 3, 3, 3, 1, 3, 3, 3, 3, 3, 1 (5 threes, 1 one, 5 threes, 1 one)
Test 4: 3, 3, 3, 3, 4, 3, 3, 3, 3, 4 (4 threes, 1 four, 4 threes, 1 four)

It occurs to me that perhaps each element adds a value to a variable. When the variable overflows and wraps around, a camera is placed, but each track element has a different value to add. But quickly I realise this cannot be the case, as 12 x 3 = 36, which is different from 10 x 3 + 2 x 1 = 32 and 8 x 3 + 2 x 4 = 32. I'm more lost than before!
Title: Re: Camera placement
Post by: Daniel3D on January 25, 2021, 05:17:14 AM

For your tests we have:
Test 1: 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3 (12 threes, including arriving back at the finish line)
Test 2: The same, also 12 threes
Test 3: 3, 3, 3, 3, 3, 1, 3, 3, 3, 3, 3, 1 (5 threes, 1 one, 5 threes, 1 one)
Test 4: 3, 3, 3, 3, 4, 3, 3, 3, 3, 4 (4 threes, 1 four, 4 threes, 1 four)
In test 3 the camera on the crossing is not double counted like in test 4.
Test 3: 3, 3, 3, 3,*4*, 3, 3, 3, 3,*4* (4 threes, 1 four, 4 threes, 1 four)
I believe it is t place a camera at midpoint of the track.
Title: Re: Camera placement
Post by: Cas on January 25, 2021, 05:32:41 AM
You're right. That adds more consistency. Now I wonder why sometimes we get all 3s. Adding the numbers yields 32 when not all 3s and 36 when all 3s. It would make sense to me if they added to the same number.
Title: Re: Camera placement
Post by: Daniel3D on January 25, 2021, 05:52:32 AM
You're right. That adds more consistency. Now I wonder why sometimes we get all 3s. Adding the numbers yields 32 when not all 3s and 36 when all 3s. It would make sense to me if they added to the same number.

They do add up.
Test one and two are a longer track.
Title: Re: Camera placement
Post by: Cas on January 26, 2021, 06:22:15 PM
Oops!  It's true!

Anyway, when we get this 4 after a set of 3s, this suggests there's some mantissa being added, but if on some tracks, we get all 3s, then the difference has to lie in the contents, so the non-integer value for large corners must be different from that of straights.
Title: Re: Camera placement
Post by: Duplode on February 23, 2021, 04:49:26 AM
F4 camera positions for Default:

(https://i.imgur.com/x2nDenr.png)

These positions were extracted with a debugger from memory, more specifically from trackdata09 (see this Wiki article (http://wiki.stunts.hu/index.php?title=Trackdata) for an overview of what Trackdata is).

(See also: the companion post about trackdata10 (http://forum.stunts.hu/index.php?topic=3474.msg78129#msg78129).)
Title: Re: Camera placement
Post by: Cas on February 23, 2021, 07:13:25 PM
Fantastic!  I really want to be able to use that tool!

Notice how camera placement once the track element in question has been selected, is completely determined. For "horizontal" paved roads, for example, the camera is always "above". It doesn't matter in which direction the road goes. For "vertical" ones, it's to the right, not relative to the pipsqueak, but to the map. So each track element has a "position-for-camera" that serves as a potential waypoint. My guess is that this is established in the GAME resource files, together with the walls and that.

It occurs to me that, exceptions to the number of tiles before the next camera might be happening because Stunts could be taking the previous camera position as a vector instead of as a tile and then extending with a sphere of a certain radius and finding the next waypoint on the track that's closest to the sphere surface. That, of course, would make it a lot harder to predict by counting tiles, as it would also depend on these internally established potential camera positions for every tile. Since you've found PRNG calls for signs, which are very predictable, then perhaps the PRNG calls for cameras does not have to affect their position as much either. I don't know.
Title: Re: Camera placement
Post by: Daniel3D on February 23, 2021, 11:37:08 PM
I believe that the cameras are placed every 3 track pieces. Sometimes not in the middle but at the edge of the piece. The loop is two tiles but counts as one piece. Same for corners.
Title: Re: Camera placement
Post by: Duplode on February 24, 2021, 01:00:00 AM
Fantastic!  I really want to be able to use that tool!

This map was done with Cartography in pretty much the same way the race reconstitution videos are done, except that I replaced the auxiliary program which extracts car coordinates from the repldump output with one that does it for a trackdata dump (the dump itself was obtained using the DOSBox debugger). If all goes to plan, a new version of Cartography will be released within the next week or two with support for setting up this kind of visualisation.

So each track element has a "position-for-camera" that serves as a potential waypoint. My guess is that this is established in the GAME resource files, together with the walls and that.

There indeed is an element-specific camera position offset, though I didn't look into it too closely back in 2016. IIRC it is defined into the executable, alongside other element information such as the connectivity flags.

I believe that the cameras are placed every 3 track pieces. Sometimes not in the middle but at the edge of the piece. The loop is two tiles but counts as one piece. Same for corners.

It does seem this three-element pattern is the primary rule used by the game. In Default, there is only one sector where it is not followed: the beginning of the long way (there is an extra camera just after the split, then the next one is four elements ahead).
Title: Re: Camera placement
Post by: Cas on February 24, 2021, 04:11:31 AM
What I'm feeling is, as I was saying, that perhaps it's not how many tiles ahead, but how much distance from the previous camera position. This distance is fixed and Stunts is looking for the tile camera position that's nearest that distance from the previous camera and on the same path. This would explain why most of the times it is every three tiles, but not always. If this is so, when it takes four tiles, it's because the place where the camera would go at that tile is nearer that fixed distance from the previous camera than the place in the previous tile.

So are you manually reading the memory dump?  I thought you were using something like rpldump to automatically obtain a file that Cartography would read. By the way, where do I get rpldump?
Title: Re: Camera placement
Post by: Duplode on February 25, 2021, 12:07:27 AM
On the cameras being positioned according to Euclidean distance: I'd find that surprising, as it seems most of the other track setup and checking is based on tile and element counting. But then again, some of those exceptions are really strange, specially that one with the dangling 1x1 split (http://forum.stunts.hu/index.php?topic=3647.msg77669#msg77669).

On reading memory dumps: the usual procedure, which I use for the videos, is (1) generate the binary dump from the RPL with repldump; (2) extract the relevant data from the dump to a text file with an auxiliary tool; and (3) have Cartography read the text file. The main difference is that this time for step 1 I manually created the dump with the DOSBox debugger because repldump doesn't dump trackdata. Steps 2 and 3 were largely the same.

(I could obviate step 2 by making Cartography read the binary dump directly, and I'll likely implement that at some point. Still, it can be convenient to be able to look at the data in a human-readable text format.)

On repldump: you can get the executable from Southern Cross (http://scr.stunts.hu/files/utils/repldump-dos-2013-02-10.zip) and the sources from restunts' SVN repository at svn://anders-e.com/restunts/trunk/restunts . (Next time I boot into Windows I'll try building it from source. It would be useful to be able to tweak a few things in it.)
Title: Re: Camera placement
Post by: Cas on February 25, 2021, 09:23:55 PM
Thanks!  I'll take a look at it :)  By the way, does the default installation of DOSBox allow for memory dumping or did you have to install any mod to it?  I don't know how to generate this dump
Title: Re: Camera placement
Post by: Duplode on February 26, 2021, 12:05:34 AM
The default DOSBox installation doesn't include the debugger. To enable it, you have to give configure the --enable-debug option when building it from source. Two relevant threads from the official DOSBox forums: an usage guide (https://www.vogons.org/viewtopic.php?t=3944), and a Windows binary (https://www.vogons.org/viewtopic.php?t=7323).