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
Quote from: Daniel3D on January 23, 2021, 01:17:43 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
Quote from: Cas on January 24, 2021, 11:20:22 PM

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
Quote from: 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.

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
Quote from: Cas on February 23, 2021, 07:13:25 PM
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.

Quote from: Cas on February 23, 2021, 07:13:25 PM
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.

Quote from: 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.

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).
Title: Re: Camera placement
Post by: Daniel3D on January 15, 2022, 10:35:17 PM
Quote from: Duplode on February 24, 2021, 01:00:00 AM
Quote from: Cas on February 23, 2021, 07:13:25 PM
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.
Did you release it and did I miss that? Or didn't it go as planned. I kind of want to continue this research and generating camera placement would help a lot.
Title: Re: Camera placement
Post by: Duplode on January 15, 2022, 11:06:24 PM
Quote from: Daniel3D on January 15, 2022, 10:35:17 PM
Did you release it and did I miss that? Or didn't it go as planned. I kind of want to continue this research and generating camera placement would help a lot.

I didn't properly release it yet, though the basics of integrating the trackdata functionality to Cartography have been done since November. The main thing I need to do now is compiling and wrapping up a Windows executable (which might be slightly tricky to do due to the GTK dependencies of Cartography). I'll attempt that either tomorrow or, failing that, next weekend.
Title: Re: Camera placement
Post by: Duplode on January 19, 2022, 11:42:06 PM
Quote from: Duplode on January 15, 2022, 11:06:24 PM
I didn't properly release it yet, though the basics of integrating the trackdata functionality to Cartography have been done since November. The main thing I need to do now is compiling and wrapping up a Windows executable (which might be slightly tricky to do due to the GTK dependencies of Cartography). I'll attempt that either tomorrow or, failing that, next weekend.

Update: I have managed to compile the current Cartography on Windows. There still are a few wrinkles to sort out -- most remarkably, using the current version of GTK requires me to put thirty DLLs in the zip if I'm to make a "naive" portable distribution (that is, just zip everything together), so I'll try to find tidier approach. In any case, I will wrap up and release a new version in the weekend.
Title: Re: Camera placement
Post by: Duplode on January 30, 2022, 03:15:08 PM
Quote from: Duplode on January 19, 2022, 11:42:06 PM
Update: I have managed to compile the current Cartography on Windows. There still are a few wrinkles to sort out -- most remarkably, using the current version of GTK requires me to put thirty DLLs in the zip if I'm to make a "naive" portable distribution (that is, just zip everything together), so I'll try to find tidier approach. In any case, I will wrap up and release a new version in the weekend.

One weekend later, it is finally done! Here is the Windows binary download link (https://github.com/duplode/stunts-cartography/releases/download/1.0.0.0/stunts-cartography-1.0.0.0-windows-x86_64.zip); see also the Cartography topic (http://forum.stunts.hu/index.php?topic=2937.msg83560#msg83560) for extra information. Basic usage info on the t2c command, which generates Cartography annotation input from a trackdata memory dump, can be found in the readme (https://github.com/duplode/stunts-cartography/blob/master/README.md#t2c-trackdata2carto), and of course please do ask if you want a more detailed explanation.
Title: Re: Camera placement
Post by: Cas on January 31, 2022, 12:21:44 AM
Does Cartography not have a Wiki article? :o
Title: Re: Camera placement
Post by: Duplode on January 31, 2022, 01:14:50 AM
Indeed it doesn't. A Wiki article would be a nice place to talk about how Cartography came into being, and what its different parts have to do with each other.
Title: Re: Camera placement
Post by: Cas on January 31, 2022, 06:29:16 AM
Yes, I think it'd be great to have one. Also, with time, when we develop a program, we tend to forget details about how it all happened, so it's very good to leave everything written. At least in my case, that happens a lot. My memory is very selective. Some things I remember very well, no matter how long. Others, I can forget to the point that I have no idea. Sometimes I forget what I have said myself, ha, ha