Jump to content
Sign in to follow this  
Justin Toposim

10m mesh - a limitation?

Recommended Posts

HI Dick>As I stated, once a coastal flatten is applied for the >water, it forever destroys the underlying mesh. >I'm not grasping this statement. You mean that even when the coastal flatten is removed the mesh is "gone forever"? Where does it go? Mesh-heaven? :-)>You can delete the LWM BGL causing the problem, but then be >prepared to spend months making a replacement LWM BGL for >the coast, as the span covered by the default LWM BGLs is >usually quite large, and our tools are rather crude. >I'm still confused here. (Not a difficult thing to accomplish, granted.). But let's say we have a DEM along the coast of an ocean. The elevation points will go from something greater than zero down to zero at the coast. Say we lay down a coast poly covering every point that has a zero value. Sounds simple enough theoretically.What is the issue? What does LMW do that will destroy the mesh?Similarly, for inland water bodies, only instead of a zero value, we'd have some other value that defines the water areas.>Photoreal designers are particularily hard-hit, as often >their coasts do not match the default. >I say get rid of the 1:2000000 coasts altogether and replace them with 1:100000 data. This gives a vertice approximately every 11 meters which is more than enough detail in most cases.Why >NOT< remove the appropriate default BGLs altogether? If we're not using them, why this struggle to keep them active to live in detente with our addon stuff?>So "remeshing"... faking a mesh with tiny LWM elevation >polys is the only sane recourse... and tools are going to be >developed to simplify that process. >>Then you don't need to replace any default BGLs. >Why not just move the default BGLs out of sight of the Scenery.cfg? Seems like a bunch of hoops to jump through just to retain the default coasts, which are grossly inaccurate to begin with.>But with TERRAIN_MAX_VERTEX set to 21, instead of not >greater than 19, this remeshing is terrible looking, instead >of acceptable. But as I said, it's our only recourse. So I >am advising everyone to not raise the TERRAIN_MAX_VERTEX to >over 19. >>As more designers start adjusting coastlines, and remeshing >problem spots with LWMs to raise reclaimed coastal areas, >this will become an issue. Just a heads-up. >OK, I appreciate that. But I still don't understand the need for remeshing. Probably since I have no practical experience in this yet, but it seems to me that it would be much easier to just remove the offending default files and replace them with better after-market ones.Or, am I still not grasping the issue?JustinFSG


________________

Justin - Toposim

http://www.toposim.net

Share this post


Link to post
Share on other sites

Hi Justin.I don't think you do understand the problem with these LWM BGLs.LWM define the land and water areas with polygonal masks. That is not a problem, as we can alter these masked areas any way we want.But, Microsoft has attached an elevation element to these masks that can flatten these polygonal shapes. LWMs have some sophisticated exclusion properties that allow the conversion of land to water easily ( and back again )... but MS forgot to have an exclusion for the flattening properties. So once something is flattened, you must live with it ( or delete the BGL and all of its land/water shapes ).A single LWM BGL typically cover thousands of square miles. A single LWM polygon can cover only about 0.58 miles squared... so we are talking about replacing thousands of LOD13 areas ( 1024 per LOD8 sized area ), each separately defined, when we replace a singular default "hyp" type BGL. So there is a huge problem, as most designers are simply correcting small coastal areas, or applying a rather small photoreal slice set, or making a coastal island MS forgot in the original scenery... and finding the terrain no longer matches their mesh. Not the mesh's fault, but the default "hyp" BGL's fault.With hand-coding it would take months to re-code a single default "hyp" BGL. And we can't simply delete the BGL, as it contains all the land/watermasking and trimming for hundreds of square miles... all the ocean and lakes.If we had an LWM decompiler, we could quickly remove the flattening elevations, and recompile the BGL. Then we'd have a world like CFS2, where water doesn't have any elevational element, and the mesh could then control the elevations of the water, and photoreal would cling to the mesh... instead of photoreal clinging to the flattens plus the mesh.Unless a designer is willing to devote months of his life to reconstructing the "hyp" BGL, then indeed the mesh under the LWM masking does go to mesh heaven, as there is no LWM "unflatten" command.----------------An alternative, is to ignore the flattening, and go ahead and develop new coasts, or islands, or lay down photoreal slices, and live with it. In that scenario, your mesh will look great, until you come upon the coast or lake areas with the old flattens still dictating to the terrain. Then, like airfield flattens, the mesh will appear "off". You and I know the mesh isn't at fault, but it won't look right.----------------The alternative I suggest is simply limiting the TERRAIN_MAX_VERTEX to 19. Then designers can use new 'transparent' LWM flattens to their advantage, and make everything look right again. At 21, the LWM remeshing looks like a hopelessly oversampled mesh. At 19, the remeshing is usable.I think Steve Greenwood is realising that setting TERRAIN_MAX_VERTEX to 21 introduces some other odd elements into the mesh display itself, so why not just leave that setting alone?----------------I don't think anyone is going to delete their hyp BGLs and the hyl BGLs ( beaches with waves ), just so detailed mesh can properly define the shoreline and lake elevations. That would leave a blocky world without land and water shoreline trimming, and no beaches or waves. It would be nice to replace all the world's watermasking and beaches with more accurate versions, and let the mesh define elevations, but it is not going to happen before FS2006 arrives. We do not have the tools needed to convert the geodata to BGLs.-----------------Oddly, in CFS2, your suggestion makes the best sense. There are no waves, and the beaches look pretty cartoonish, and default LWMs don't flatten.. So I have suggested we get rid of the the default LWMs and the VTP beaches, roads, etc... and start from scratch... and let the mesh do it's job. Again, we don't yet have the tools to convert geodata to LWM polygons, and VTP lines, but the problems are less pronounced with CFS2, as we don't need to delete the BGLs, but can use LWM and VTP exclusion. There are no flattens to deal with.The biggest problem with LWMs and VTPs in CFS2 is that I am probably the only person in the world that has any interest in correcting the deficiencies of their default LWMs.That is not the case with FS2002. I get a lot of questions about LWMs, remeshing, and VTP lines and polygons. This is a real area of interest in this sim. That's why I poked my nose into this forum's thread.---------------What is already happening, is that people are adding islands, and photoreal, and correcting shorelines, and LWM remeshing is the only viable solution to raising tiny areas flattened by the huge default BGLs. These remeshed areas, are essentially LOD13 mesh, that overrides any default or addon mesh. The damage has already been done by the original flattening, and these folks are just looking for a workable fix. With the TERRAIN_MAX_VERTEX set to 21, the appearance of this fix is laughably oversampled and blocky looking. At TERRAIN_MAX_VERTEX set to 19, it is a reasonable solution. Dick

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
×
×
  • Create New...