![]() Expose rF2PitInfo and rF2Weather buffers.See "Input Buffers" readme section for more info. Adds battery/electric motor items to the rF2Telemetry buffer. ![]() This version just uses the updated InternalsPlugin.hpp Inserts DeltaBest into the rF2Telemetry buffer.This version corrects the updated InternalsPlugin.hpp That said, I am very passionate about autosport rules, so if you try to use this plugin for rules development and need help/changes (with the plugin part), feel free to reach out. I tried to minimize the impact of this processing gap by copying some of the latest rules state onto the updated state, but I do not know how reliably would that work. So there's a gap between game ouput rules and requested input rules. Using shared memory plugin this process is not synchronous: game sends rules in a function call, plugin picks up rules update from the input buffer in a separate function call, and will apply update next time game calls rule update function. The reason for that is that when done inside of a plugin, rules are applied synchronously: game sends rules input, and allows updating that input in the same callback, meaning synchronously. However, this is experimental, because I am not positive this approach is going to "fly"/is reliable. The idea was that it might make developing custom rules plugin easier, by being able to change logic in an external app/script without rebuilding plugin/restarting rF2. It allows sending Rules input to the game. RFactor 2 API has some limitations/bugs, and plugin tries to deal with that by deriving some information: basic accumulated damage info, tracking session transitions and optionally reading game memory directly. A lot of work was done to ensure it is as efficient and reliable as possible. For read operations, it can handle any number of clients without slowing down rF2 plugin thread. This plugin is carefully implemented with an intent of becoming a shared component for reading rF2 internals. It also allows keeping CPU time impact in rFactor 2 plugin threads to the minimum. Reading and writing shared memory allows creating external tools running outside of rFactor 2 and written in languages other than C++ (C# sample is included). Plugin also allows some level of input back into the rFactor 2 API. Essentially, this is direct memcpy of rFactor 2 internals (except for extended stuff implemented to workaround API limitations/bugs). So taking individual images would probably take forever.This plugin mirrors exposed rFactor 2 internal state into shared memory buffers. Besides, I didn't want to spend too much time doing it, so decided on taking a video, which anyway took about 10 hours, because I had to do multiple passes. However, I was surely not in a position to close the traffic in the city for a day or so and couldn't make scans slowly and thoroughly. Photogrammetry is a technique that requires high-quality images, the better the image quality and the better pattern of taking them the easier it is for the program to create a 3D model of it. But that didn't work seamlessly as well – there were a lot of errors in image alignment so I had to manually make a lot of control points to guide the software on what parts should be where. After that, I input all of the sections in a new project and reconstructed the whole track like that. That made it much easier and faster to work. I separated the track into smaller sections and reconstructed each of them separately. I had to find some workaround to solve that. When I input all of the images into the software, it could not reconstruct the whole track seamlessly. I used low-budget equipment and the images were taken in a kind of a quick way, so my input data was not that good.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |