vipoo / iRacingReplayOverlay.net

Tools to capture game data, and then transcode a captured video file - overlaying race status
GNU General Public License v3.0
37 stars 14 forks source link

Highlighting rule: Prioritise incidents and battles #57

Open vipoo opened 10 years ago

vipoo commented 10 years ago

Prioritise incident and battle race events, that include positional changes (overtakes) over those that do not.

SpirouHyluan commented 8 years ago

Hi Dean,

About this enhancement (which is currently in progress, imo), it could be interesting to detect more than overtakes in the battle detected. For example by detecting all overtakes within 1 or 2s of the current camera driver. And also detect if this overtake involves a prefered driver, for edits purposes.

In first laps and close races, often battles involve more than 2 cars and you can't know which two will generate an overtake. Another option will be to scan the replay to detect overtakes and use that but it seems, from here, harder to develop.

vipoo commented 8 years ago

Hi,

I forgot I had spike some code for this - trying different things. There is a new branch called 'battle-analysis', which include code to scan the race, prior to capture, identifying where all battles start and end.

Though, nothing is using this data yet!

The idea is to build a model of all interesting things, then during race capture, this data can be used by the direction rules to select the appropriate battles, incidents, etc.

The code a bit 'hacky' - https://github.com/vipoo/iRacingReplayOverlay.net/commit/7e6952ca8bb97a7a5a4dc88ecd3a4cb4d8b711e6

Dean

SpirouHyluan commented 8 years ago

This is greatly expanding the range of possibility !

If I may, I could be interesting to analyse the race as an independant part of the process, with an XML file stored, that could be used again a second time without rescanning the replay.

You could also propose something absolutely terrific imo : after the race analysis, present the list of events detected with the type of event, the timeframe, positions. Eventually, you could place the replay at the start of the event when clicking on it to show what happened to the user. Then user could select what to keep in the replay, and launch the capture.

It is surely a big work, but the added value would be amazing !

2016-01-25 0:35 GMT+01:00 Dean Netherton notifications@github.com:

Hi,

I forgot I had spike some code for this - trying different things. There is a new branch called 'battle-analysis', which include code to scan the race, prior to capture, identifying where all battles start and end.

Though, nothing is using this data yet!

The idea is to build a model of all interesting things, then during race capture, this data can be used by the direction rules to select the appropriate battles, incidents, etc.

The code a bit 'hacky' - 7e6952c https://github.com/vipoo/iRacingReplayOverlay.net/commit/7e6952ca8bb97a7a5a4dc88ecd3a4cb4d8b711e6

Dean

— Reply to this email directly or view it on GitHub https://github.com/vipoo/iRacingReplayOverlay.net/issues/57#issuecomment-174352938 .

vipoo commented 8 years ago

Hi,

If I may, I could be interesting to analyse the race as an independant part of the process, with an XML file stored, that could be used again a second time without rescanning the replay.

This could work, - it harks back to some of my earliest pre-release revisions --- have to be careful of versioning. eg - users attempting to use a prescanned file, after updating the application. This adds the usual maintenance, user explanation, and other general development costs.

You could also propose something absolutely terrific imo : after the race analysis, present the list of events detected with the type of event, the timeframe, positions. Eventually, you could place the replay at the start of the event when clicking on it to show what happened to the user. Then user could select what to keep in the replay, and launch the capture.

This does take the application away from the 'automation' to the 'manual' approach. Personally I prefer to get the intelligence into the application, so users dont have to customise each race. But I will consider such updates, if this is hidden behind an advanced option screen or something similar.

I do worry, that this would be a fair bit of code, and would potentially increase maintenance issues.

I am just thinking as I am typing this, but perhaps we can look at a 'plugin' model, where this feature is a separate add-on to the application. IE: provide ability for a separate assembly (dll) to be loaded, with appropriate hooks for it to do its extra stuff... I will think about this and get back to you.

Cheers Dean

LGRDDOG commented 8 years ago

I would have no issue about a secondary scan, specifically for battles if it allowed the program to better prioritize and select battles. As quite often in it's current form, there's times where it shows 1 battle, and just as something's about to happen, it jumps to another battle that's just starting. I've also seen instances where it will jump away from a battle, only to come right back to the same battle because the same car is passing a few vehicles in a short span of time.

Perhaps some battle prioritizing process to detect how many vehicles (lapped or otherwise) are overtaken within X seconds, as well as battles that have some back & forth happening having more priority than battles that only pass one vehicle, or even battles that don't even involve an overtake.

I could see some people complaining about the extra time, however that could be avoided by simply having a configuration option where you can select "Enhanced Battle Logic" which would then enable the extra scan through the replay specifically for battles :)