meerkat

Members
  • Content Count

    74
  • Joined

  • Last visited

Community Reputation

8 Neutral

Flight Sim Profile

  • Commercial Member
    No
  • Online Flight Organization Membership
    none
  • Virtual Airlines
    No
  1. If comparing the computing power needed to show a conventionally modeled city like Dzewicky New York (which has to omit a lot of small details) with 30 fps to a textured 3D mesh of a photogrammetrically generated city (which shows every details as it was seen by the camera) then you will realize that this is the future way to go for densely populated areas (provided you have access to the geodata whis MS clearly has). There are many advantages: no more ground textures with roads cutting through buildings, no need to turn down autogen building density in large cities, no repeating autogen textures, no need to model most of the landmarks, even shader based animations like road traffice are working inside this textured mesh. You only need fast internet and a graphics card capable of fast tesselation and good antialiasing. The streamed data surely will be cached on your PC so you don't have to wait for downloading them each time if your every day starting airport is, say, NY La Guardia. One big drawback is, that "holes" in the geometry (like in the Arc de Triomphe) and transparent elements are not always shown satisfyingly (at least until now and what I have seen on my PC). Also, if you get very close, the resolution will likely be insufficient. In an airplane you normally don't come too close, but landing a helicopter on a skyscraper might be problematic. Also, airport buildings are better modeled as 3D objects. But, I could imagine that this can also be done (semi)automatically using HD photogrammetry and some clever algorithms. The LA airport in the video is a good example: it is modeled with HD textures, buth the trees in the background seem to be 3D mesh. Contrary to FSX, P3D etc., the amount of data and the workload for your PC will be nearly the same in a city or in a mountainous forest area when using this 3D mesh technique. Admittedly, the latter case will be a waste of bandwidth if it can be done convincingly with an improved conventional landclass tech. Also, for huge areas of the world (tropical forests, polar regions, ..) there are no HD textured mesh data - thus they'll have to use landclass tech if the whole globe is to be rendered (which I believe). I see this video (apart from the absolutely stunning lighting an weather) as a showcase of new scenery technologies that might (or will) make it into the product, but surely not completely replace the old tech. It's a way for MS to generate profit from the data (satellite and aerial imagery) they own. In Bing you can view them for free, but in FS it's value added and probably will cost a subscription fee. I could even imagine that you can use the product without such subscription - you simply will see some default scenery then. Not worse than what we have now. So I really don't understand all the panic and negative comments. I'm looking forward what they will achieve during the next months.
  2. meerkat

    Phil Spencer Interview

    With all respect, I don't think it's possible to change a winter satellite image to a snowless one that convincingly (if not correctly) shows what the satellite would have seen in summer, and that even without manual retouching but only AI procedures. The other way round would be much easier and still seems very hard to do as we get no winter season in satellite scenery.
  3. meerkat

    Phil Spencer Interview

    I also saw this tiny triangle of misfit ground - appears to me like a seam in the satellite scene: main part was taken during winter while that small piece shows a summe scene. You can see it on the lake that is half ice covered, half water colored. This is one of the obstacles in establishing a seamless worldwide satellite ground coverage.
  4. meerkat

    E3-Trailer Scenery Locations?

    Aaaw, and nobody recognized the flamingo scene and the Ngong Mountains (giraffes scene) in the Rift Valley (where they buried Finch Hatton) from the 1985 "Out of Africa" movie?
  5. meerkat

    Phil Spencer Interview

    If you have a look at the scenes with the elephants, giraffes and bush flying at 1:22 you will see that the scenery doesn't show satellite imagery but a new issue of classical landclass textures with clever use of procedural, probably shader based overlays. The slightly polygonal river in the bush flying scene shows that vector data are used as well. My conclusion is, that thy showed in that trailer mainly the HD areas that are built up of a photogrammetric mesh (like the 3D cities in Google Earth, probably made from aerial imagery and not just satellite scenes) and the MD areas with satellite ground texture and some (auotgen?) trees on it, but in the abovementioned three scenes the were honest enough to show us what the huge rest of the world will look like. This absolutely makes sense as in most areas of the tropics due to cloud cover there is even a lack of medium resolution satellite imagery - have a look in Google Earth or elswhere. Moreover, natural landscapes with trees as photogrammetric 3d mesh look not soo good closeup as the trees look quite blocky and completely intransparent. It would also be a waste of bandwidth to stream thousands of km² of uniform tauiga forest instead of using the conventional texture and autogen tech. So, a mix of techniques for terrain depiction is the right way to go. It also will open a lot of possibilites for scenery addon publishers, provided a SDK (which we will see in time, I'm sure - they will have learned from the FLIGHT desaster).
  6. meerkat

    Problems with Tomatoshade on P3DV4.5

    There is a hint within Tomatoshade's own preset, that after installing the new shaders you must first start a flight in P3D with a night setting, clear weather and no AS active, in order to have correctly compiled shaders. Have you tried that?
  7. meerkat

    MA RealTurb North America

    Go to SimMarket and search for RealTurb - you will find the two free continents Antarctica and Africa.
  8. Hi Kernel, I also searched for variables like temperature and dewpoint that could be used within shaders. For now my solution is using the precipitation intensity - for instance for the haze effect density this: (0.00000000080 + cb_fPrecipitationLevel * 0.00000000120) This way at least I don't get 20 miles visibility on a gray rainy overcast day, even if AS doesn't reduce visibility. But in arctic or hot deserts where surface visibiliy in very dry air can be > 100 nm, or on a pre-storm humid day in EU with little more than 10 nm vis, only the difference between dewpoint an temperature would help.
  9. meerkat

    bugs reports

    Wow, thanks - I didn't know that, seems to be not mentioned anywhere. Another great plus of your work.
  10. meerkat

    bugs reports

    It might have to do with the missing lower LODs that are displayed in the distance. Maybe, the terrain engine samples the mesh just between data points and produces erroneous -32768 m data? I suspect, with a precompiled multi LOD mesh these problems could be avoided (but it would further increase the download volume :( ). Another approach to find out what's wrong would be testing different LOD resolution and radius settings in FSX.
  11. Hi Daniel, I found another "no data" hole in the N50E020 tile at N57,03 E29,28. Concerning the ridges following the degree boundaries, I can assure that they are visible in FSX in some places - please see the linked image. In this case the ridge is some 50 m higher than the surrounding terrain. It though may depend on your FSX terrain mesh settings (I have mesh_resolution=22). They are often more prominent in TmfViewer due to the simulated oblique lighting in the viewer. I suppose that they are more visible in FSX at low sun angle in spot view, when even small hills or ditches cast shadows. Another case where it could be visible is along the 28 and 29° boundary in the N50E020 tile. Sometimes they are ridges, sometimes trenches of some 40 m depth. Those linear faults seem to come from the way your software stitches the 1 degree SRTM tiles together. Maybe some interpolation parameter ca be changed? I'd suggest to check the other tiles for faults before offering a new patch. https://drive.google.com/open?id=0Bw8Pa2ZosQcwMTkzYWlIY04zWmc&authuser=0
  12. Hi Daniel, first, many thanks for your huge and generous effort. It adds a lot to most regions. Sadly, there are some more or less strong artifacts that seem to have different reasons: (1) "no data" cells in the SRTM source that is coded as -32768 m altitude. I found several small ones in N Poland in the N50E010 tile causing deeep holes that can be surrounded by high spikes when the mesh resolution in FSX is set to less than 38 m (which comes from the way FSX interpolates the altitude data when using a higher mesh resolution than the actual bgl files has - they seem to use some kind of bezier function which overshoots at very steep cliffs). These should be easily detectible and can be replaced by the value of surrounding cells. I hope this can be automated with your geo tools? (2) perfectly linear ridges of some meters altitude in north-south direction along the boundary of the one degree source tiles. They seem to become prominent mainly in the flat lowlands - there are some in N poland near the baltic sea that are very easily visible. The cure for these problems that can be found in other of your bgl files too is not so obvious to me as it depends on your workflow. I would suggest to open each 10x10 degree bgl file in TmfViewer and inspect them with a medium zoom factor. These lines and also data holes (in a deep pink) should be easily visible. (3) very narrow plateaus of 500 m altitude near the Oder river (already reported by Rainer) for which I have no idea how to detect them easily and what is their cause. I will see if I find tomorrow the time to check all bgl files of the Europe package which is the only one I downloaded. If such problems occur in most tiles I suggest it might be better to disable the torrent and other download links for now to prevent unneccessary traffic before these faults are patched...
  13. No, don't say that. I just had no time to check after the update, and as you only mentioned the apron... Now I flew a circuit in the nicest, densest fog with stratus clouds included and all looked fine! So thank you for the support and continuous improvements! Btw., did you see what Thorsten Renk was able to achieve with shaders in FlightGear? Realistic light scattering taking into account the real humidity without dawn and dusk bitmaps, cloud shadows, snow cover taking into account real weather data instead of a built in seasons table, puddles after rainy weather and so on. I think this should be the direction LM should take with further development of P3D. Much less need for texture addons a la REX, probably no more separate winter textures needed, much more realistic visuals and weather depiction. Oh, dreaming :blush:
  14. OK, thank you very much. Just downloaded the update. But more than that are the clouds annoying. They are REX textures btw. Now I can't use the "stratus layer for dense fog" feature in FSGRW as it looks awful. Do you have an idea? Any diagnosis tool? Edit: I see, that the screenshot links don't work. Steve, if you need an image, I will send you a PM, ok? Regards
  15. I am running FSX with DX10 fixer v. 2.4 with Nvidia driver 344.48 on a GTX 550 Ti, Windows 8. When the visibility is in the foggy range I get dark apron textures and dark clouds that shine through the fog (obviously the don't become faded out by the fog, thus the stick out more with increasing distance). I tried nearly all combinations of options in the Fixer, but only disabling the general shader restores the normal behaviour (but introduces other errors, of course). It may be a driver problem, as I did not have this issue a year ago (when I run the 331.82 driver, but also an older DX10 fixer). dark apron and clouds visible through fog: General shader disabled - apron and clouds correctly fogged (ORBX lights don't show right)