Posts by RjG

    Vincent,

    Here is an example that will ignore all polygons tagged natural = "bare_rock" within landuse="forest" polys.


    ## ----------------------------------------------------------------------------------------------------------------------

    # osm

    ImportOGR|C:\Users\rgord\Desktop\Test_NATURAL\test_bare_rock.osm|*|*|NOREPROJ


    # clear all 'bare_rock'

    SubtractFeatures|landuse="forest"|natural="bare_rock"|1

    # TREES

    PlacePointsInPolygon|landuse="forest"|0.0001;0.0001|1.0;1.0

    # this line generates a broadleaf tree for 2% of the tree coordinates with each tree between 58 to 65 feet tall

    CreateAF2Plant|FRAND < 0.02|17.67;19.812|0|broadleaf|3

    # this line generates a broadleaf tree for 18% of the tree coordinates with each tree between 40 to 55 feet tall

    CreateAF2Plant|FRAND >= 0.02 AND FRAND < 0.2|12.19;16.76|0|broadleaf|0

    # this line generates a broadleaf tree for 75% of the tree coordinates with each tree between 32 to 45 feet tall

    CreateAF2Plant|FRAND >= 0.2 AND FRAND < 0.95|9.75;13.71|0|broadleaf|2

    # this line generates a broadleaf tree for 5% of the tree coordinates with each tree between 20 to 30 feet tall

    CreateAF2Plant|FRAND >= 0.95|6.096;9.144|0|broadleaf|12

    # Export the AF2 TOC file

    ExportTOC|C:\Users\rgord\Desktop\Test_NATURAL|test_bare_rock

    ## ----------------------------------------------------------------------------------------------------------------------


    -- Rich

    In my situation Steam didn't download the new jul25 WMRforSteamVR with default.vrsettings (sans renderTargetScale), until I opted in to the WMRforSteamVR beta. I had only always been in SteamVr beta but never realized there was a beta checkbox for wmrfsvr. It seems to work much better.


    I also changed WMR setting from Very high (beta), to High. There were a lot of artifacts in very high and changing got rid of almost all of the sparkling swimming edges and harsh vegetation transparency issues I was having.

    I also currently have steam ss dialed back to100% and rsf at1.55 in fs2.

    Performance seems better with much lower frame times and clearer image.

    I'm also getting better performance with ogl vs vulcan. This is not my main rig but one just built with now blow out bargain amd 2700x and my old strix 1070.


    -- Rich

    Dave,
    I first want to say that my response was a result of initially interpreting your RSF as a juxtaposed abbreviation for renderTargetScale as mentioned by Jake a few responses earlier. "Render Scale Factor inside of Aerofly FS2" in your last post put us on the same page and clarified for me where you were going with your table post. I mistakenly thought we were going down the renderTargetScale bunny hole.

    ---


    "I would like it if fpsVR did that but I don't think it adds up all the factors - both Steam VR Video and Application plus the in-game scale factor."


    I also use fpsVR and, as you point out, really represents only about a third of the puzzle. The Microsoft 'WMR for Steam VR' plugin performs it's own scaling based on buffer size and the app rendered content that it is handed.The app in our case, FS2, gives you the ability to upscale the initial rendered output source fed to . You've got all these moving parts with slider options on both ends (SteamVR and FS2) and middleware plugin that lets you manipulate a buffer (renderTargetScale) that can, if misconfigured , 'trigger blurriness and image quality issues'. (face palm)

    Wouldn't it be great if SS at both ends of the render chain could be changed in real time with a pair of sliders that you could fiddle with simultaneously as you balance visual quality vs hosing performance. It would be like turning the tuning knob and fiddling with the rabbit ears on an old analog TV. LOL
    ---


    -- Rich

    I feel compelled to jump in here regarding renderTargetScale 's role in the 'WMR for Steam VR' configuration file.

    -----

    Rather than paraphrase.

    Dan Conti, Microsoft dev, posted in the 'WMR for Steam VR' forum:


    "Short description is it ( renderTargetScale ) controls the size of the buffers we hand to SteamVR for app rendered content. If you set too small a value then the buffers will be smaller than the what the content was originally rendered at and you get downscaling. If you downscale too much, then we later have to upscale to match the resolution of the displays, and you will see blurriness and image quality issues. If it's set too high, you end up with a much larger buffer than is needed.

    There is a point on SS where you'll need to increase renderTargetScale, or you will trigger a downscale. If you try 2.5 or 3.0 you should see the drop-off go away. This is assuming you aren't hitting performance issues.

    In terms of tuning, what you are looking for is the point of diminishing return on upping SS. At some point any value of doing a higher quality initial render either isn't noticeable or impacts your ability to maintain framerate."

    ------

    He also made the point that renderTargetScale has a maximum value of 5 and the current default value for All wmr headsets is 2.0. That's your minimum.


    It would also be helpful to not use percentages for SS. I've noticed in the past (especially in the beta version of steam vr) that 100% equated to different pixel counts with different version releases. Currently Steam vr beta renders 1660x2076 per eye for my Ody+. With hardware native being 1440x1600, that is already a 115% super sample.

    The slider at 200% shows me 2348x2936 per eye, a 1.63 ss ratio.
    The steam vr 100% base rendering resolution is an arbitrary figure based on their expected baseline 'performance' of the headset, not the native hardware resolution.


    -- Rich

    Because I find that IPacs managers, do nothing to help on this point.


    While with the tool FSx AIrport Design Editor we made tracks with taxiways and other objects gas station, parking etc .. a super easy tool to take in hand.


    Without a similar tool and the same level I give up any realization of scenes under AFS2. For me the limits of what I can accept are crossed.

    In a particularly generous post Antoine attempted to gently point out to you that Micosoft never lifted a finger to create any of the tools you mention. They were all produced by third party enthusiasts spanning multiple generations of simulator and decades.


    -- Rich

    Turman,


    As a sanity check I decided o give the file a try. I downloaded the DEM and did a gdalwarp reprojection from Lambert-93 to WGS84 before loading into QGIS.
    I exported as a rendered GEOTIFF and processed as I would any other mesh.





    Looks like a similar result.


    Code
    1. 0.0000503057
    2. 0
    3. 0
    4. -0.0000503057
    5. 6.743398876
    6. 44.365688310

    BTW pixel coefficients will be identical if you are dealing with square pixels.

    Well I don't know what the problem is. But it sure does look like there is a wacky coefficient being applied to the vertical component of the data.

    -- Rich

    Antoine,

    I am super impressed with the effort you made to integrate and consolidate information and tools regarding the mechanics of AFS2's world and geoconversion. Outstanding work. Thank you so much for this reference document.


    -- Rich

    Here's a working snippet from one of my scripts:


    --

    # this line generates a broadleaf tree for 2% of the tree coordinates with each tree between 58 to 65 feet tall

    CreateAF2Plant|FRAND < 0.02|17.67;19.812|0|broadleaf|3


    # this line generates a broadleaf tree for 18% of the tree coordinates with each tree between 40 to 55 feet tall

    CreateAF2Plant|FRAND >= 0.02 AND FRAND < 0.2|12.19;16.76|0|broadleaf|0


    # this line generates a broadleaf tree for 75% of the tree coordinates with each tree between 32 to 45 feet tall

    CreateAF2Plant|FRAND >= 0.2 AND FRAND < 0.95|9.75;13.71|0|broadleaf|2


    # this line generates a broadleaf tree for 5% of the tree coordinates with each tree between 20 to 30 feet tall

    CreateAF2Plant|FRAND >= 0.95|6.096;9.144|0|broadleaf|12

    --

    The last value 'broadleaf|2', 'broadleaf|12' will evaluate to 'T02' and 'T12'.


    -- Rich