Issue in VR since latest version

[RBRPro]

After the latest update the image seem to not work when in VR while it works well on monitor. I have implemented in my manager that a file preview.png can be added to the livery textures so that the image visualized can really follow the skin. The rendered previews are nice but real photos are visually amazing!!! So my advice is to eliminate the resolution subfolder from "previews" and support directly my method: one only preview.png of a fixed format in the car skin folder! Keep up the good work! I love it. Some screenshots attached https://scontent.fcia2-1.fna.fbcdn.net/v/t1.0-9/109697544_10208054311832126_3908567798105536072_o.jpg?_nc_cat=100&_nc_sid=07e735&_nc_ohc=llXDkjQzoHYAX8PF3pH&_nc_ht=scontent.fcia2-1.fna&oh=2e9caae3ddb01cea7ff08a7820014c68&oe=5F3A8E3F

Cheers Carlo

[mika-n]

Thx for the feedback. By "VR" do you mean "Kegetys VR" mod? And the latest "V1.10.1" NGPCarMenu version?

Hmm.... The latest release should not have changed anything related to VR integration. Did the Kegetys VR mod work better with V1.10.0 or do you have to go all the way back to V1.09.0 version? And do you mean that the bult-in RBR QuickRally is not showing the preview image or RBRTM integration screens? Or the app crashes? Any error messages in plugins\NGPCarMenu.log logfile?

I think I will add an optional configuration option to override the default logic of using the source img folder.

- Option 1 (default): plugins\NGPCarMenu\preview\<resolution>\<carModelName>.<imgExt>
- Option 2: Fixed path: whatEver\mypics\<carModelName>.<imgExt>
- Option 3: Fixed path + fixed filename: whatEver\mypics\myOneAndOnly.png
- Option 4: Different path+image for RBR built-in menus and for RBRTM/RallysimFans/RBRPro plugins (after all there is a lot less "empty space" for an image in RBRTM than in built-in RBR SelectCar menu screen).

The path option would support runtime variables like resolution/carCategory/carModelName/carslotnumber/carrbrslotfolder/carfolder/plugin/imgExt etc, so it would be possible to do the option1 by default, but other options would be easy to do also.

What is the exact logic of RBRPro car folder structure? I can see that one of the screenshots above has cars\C3_r5\Skins\Pro\ folder. cars\C3_R5 seems to be a standard NGP folder, but skins\pro subfolder is something specific for RBRPro. Do you have this custom skins\pro subfolder in every NGP car folder? If you are using skins\pro subfolder in every car folder then the path logic I described above might work with RBRPro also.

PreviewFolder=Cars\%carfolder%\skins\Pro\preview.png (the above shown option would make NGPCarMenu plugin to use rbr\cars\c3_r5\skins\Pro\preview.png file as a preview source at runtime).

I'm using EasyRBR tool to manage car installations and skins for cars in slots 1..8. EasyRBR makes it easy to add and choose custom livery skins (more than one per car). I am doing an improvement to make NGPCarModel to automagically notice when a car in slot1..8 has changed a skin since the last preview image. However, if user uses custom images (ie. not the ones generated by NGPCarMenu plugin) then it is up to the user or car manager tools to install preview images with correct skins.

And based on the screenshots you posted I realize that this is one problem in placing the "car specs text block" in RBRTM plugin screen if the image is scaled to be more narrow than the reserved space. The car spec text is not properly horizontal aligned with "Stage info" text block. There is a custom option RBRTM_Car3DModelInfoPosition you can use to override the placement of "3d model credit text", but not an option for spec texts. I think I may change the default logic to align the specsText block with "Stage Info" text (at the moment this text block is always horizontally placed at "image width + 10 pixels margin" position).

I'm also working on adding a support for transparent alpha-blended PNG image backgrounds.

[RBRPro]

Well, the exact folder structure in RBRPro doesn't matter much. RBRPro allows to keep multiple skins per car (that's why the "skins" folder) but in the end the selected skin textures are copied in the RBR standard folder (\textures). I wouldn't focus much on RBRPro. Of course I am using the latest version of everything.

I realized that the problem in VR arises when you use the "fullscreen mode" or however you use a video resolution different from 1920x1080. I am doing further investigations. The transparency support would be really nice. Thanks for your suggestions!

[mika-n]

There is now V1.11 release available which supports custom ScreenshotPath folder structure (runtime variable support). See NGPCarMenu.ini.sample file for more details and examples. I believe this new ScreenshotPath logic with runtime variables does what your app is hoping to see?

Also, CarPictureScale (and RBRTM_CarPictureScale) option supports new features (for example horizontal and vertical centering of preview images bit masks if the image size is smaller than the specified drawing rectangle area).

The new version supports also transparent (alpha channel blending) PNG files.

[RBRPro]

Thanks a lot! Anyway, to be honest, what I suggested (and of course take it as it is, just a suggestion, my app will work however), is to implement in the plugin what I have implemented in the manager, that is:

• the folder containing the preview disappears completely
• the preview is moved to the "textures" folder of each car with a fixed name (e.g. "preview.png")
• the format of the preview image can be whatever, it only have to respect an aspect ratio.

this way you could eliminate a lot of configuration an make the plugin a real extension of the RBR capabilities

Concerning the VR, I realized that in the version I am using the image positioning fails when the screen have a particular aspect ratio, because the real in-game resolution can be different from the window resolution. For example in the case of a window spread on 2 monitors while having a real resolution of fullHD (the image is stretched).

I don't suggest a fix, I am sure you already have one. Cheers Carlo

[mika-n]

Hi. Yes, I agree that the original decision of using resolution specific folder was a bad decision. Don't know why I even came up with such an "idea" (maybe because the first few versions of the plugin didn't support scaling and aspectratio drawing at all, so those images generated by the plugin itself worked best if the image was created using a native resolution).

Anyway. Now the new logic in ScreenshotPath (V1.11 and newer versions) makes it possible to use the path logic you described above. I have to think about whether I will make it a default logic in the INI file, but at least it is now possible via INI tweak. The following ScreenshotPath value does what you described: ScreenshotPath=Cars\%carFolder%\Textures\preview.%fileType%

I have been lazy enough not to test JPEG/TIFF/GIF image formats. Anyway, the plugin supports only PNG and BMP file formats while generating new "screenshot" preview images through the plugin itself (and it probably remains to be so). But, it shouldn't be too difficult to add support for other image formats while reading an existing image files. I'll add it to "TODO" list.

There has been some issues with monster resolutions with triple monitors (positioning images and/or car spec text boxes). Few of those bugs were fixed, but I don't have multiple monitors and my "gaming" laptop supports max 1920x1080 resolution, so haven't been able to test those double/triple monitor setups and monster resolutions. Well, time to debug this issue in our real gaming rig (multiple monitors with real monster reso GPU/monitors) used by our teenager.

Thx for testing and reporting these issues in the plugin.

[RBRPro]

Eliminating the dependency on the resolution will simplify a lot. I've already implemented your solution by just removing the %resolution% from the path. There is too much configuration to do to support multiple resolution and in the end I think that everything can be done without the need of configuration. There is a little "maybe" to adapt you solution to my "idea". I just don't know if the "carname" you are using is the IniName, the folderName or the physicsName... IDK why but the creators of the RBRCIT distinguish these 3 things and sometimes they are different. Thanks again. BTW I have a news for developers. Since the 15th of August my TGD Navigator engine will go open source. Hopefully it have all the potential to replace the Pacenote plugin and make happy all the RBR users hoping in a better codriver. Stay tuned!

[mika-n]

%CarModelName% = Car model name as shown in RBR menus. This car model name in RBR menus is set by NGPCarMenu plugin and the name is taken from NGP carList.ini:Name entry. RBRCITCarListPath ini option points to this carList.ini file. (The option has bad name because carList.ini file is not exactly RBRCIT thing, but NGP thing. RBRCIT tool just happened to download this file for me in the first place, so that's why I somehow used RBRCIT in this option name). Cars\Cars.ini:CarName entry is the search keyword for NGP carList.ini lookups (well, in practice Cars.ini:CarName is the same value as carList:Name value).

%carFolder% = Car 3D model folder name below Cars folder. This name is actually taken from rbr\Cars.ini:FileName entry (the trailing xxx.sgc filename part in this FileName value is dropped. Then then leading cars\ prefix value is also dropped). This leaves the %carFolder% option as having a value with the folder name below rbr\Cars\ root folder.

Great news about TGD Navigator. RBR as a game would die without map, car model and plugin authors. Releasing something as open source is a great way to receive even more comments and contribution suggestions. I have found that very few people will actually contribute as code changes, but some users find it easier to test something and then they ask the original author to implement something the user is hoping to see in the officially supported app/plugin version. Nowadays there are not too many RBR plugin authors.