3D View with vector areas flimmer

3dvr_m4
Global Mapper UserTrusted User
in Vector Data
I'm laying out airport data such as runway and taxiways over WORLD imagery. When I use the 3D view, the areas conflict with the imagery layer and "flimmer" and are not drawn cleanly. The 3D view doesn't seem to take advantage of the draw order in the Control Center. I don't have any terrain elevation data loaded in the project.
I've tried a few different things in the 3D Properties but nothing helps.
Any suggestions? Is it possible to draw clean vector data without adding elevations?
I've tried a few different things in the 3D Properties but nothing helps.
Any suggestions? Is it possible to draw clean vector data without adding elevations?
Tagged:
Answers
-
-
Hi, this is very common in 3D modelling and, if I remember correctly, it is called Z-plane buffering. It occurs when two surfaces are close together (or occupy the same plane) and the computer graphics process cannot determine which one should be shown. The result is a flickering between the two surfaces or "flimmering" as you have now christened itI have seen the same thing frequently in SketchUp which, as you may know, is dedicated 3D software.As far as I know, it cannot be resolved with draw order. The only way I have found to resolve it in SketchUp is to have one surface (say the paving in your example) cut out the base surface (the grass) - essentially only one surface at any given point. I can't tell you how to do that in GM, but perhaps there is an option to subtract one area from another?
-
Hi 3dvr_m4,
I'm guessing that what you're seeing is what we call Z-fighting. That's when two separate geometries have identical depths in the depth buffer (or "z-buffer"). This mainly shows when you have coplanar faces that overlap. Basically coincident pixels in the overlapping faces are "fighting" to be displayed: the last pixel in the z-buffer "wins". You can read about the problem here: https://en.wikipedia.org/wiki/Z-fighting. It's a tough problem to solve generally. Draw order isn't really used in 3D, and it wouldn't make a difference anyway, as the problem relates to precision of the depth buffer, and not the order of drawing geometries..
Without knowing what you're doing, it's hard to suggest a remedy, short of adding elevations. You have imagery and area features that don't have elevations as your working data, right? You could try unchecking the "Display 3D Vector Features in Space Above/Below Terrain Surface" and checking "Draw 3D Vector Features Reflected on Terrain Surface" That will cause the area features to be "burned" into the imagery on the 3D side rather than being rendered as geometric objects.
Try that and let me know if it helps.
Best regards,
~Jeff -
Yes, it is the z value conflict, though even if i assign a z value to the geometry it doesn't seem to make a difference. It should be a easy fix and other 3D apps I'mve used assign a simple priority flag with a numeric level value to tell the graphics what to draw over what. I believe x-plane does something similar as well. Does GM not have any way to assign draw order in the 3D view?
-
Global Mapper has no way to define 3D draw priorities. I'm not really sure how that would work. What other 3D applications have you used where you can assign draw priorities? How does that work when you have overlapping / intersecting objects? I know that we can disable depth buffer testing for particular objects, but that's not a general priority system. Sounds like a research project to me.
You should be able to alleviate the issue by giving your objects vertical offsets used in 3D. To do this, you need to add an attribute named "3D_ZOFFSET" to each of your features, and give each a value greater than 0. You may need to experiment with this value, and an appropriate value will depend on the scale of your scene. I'd start with 1, and if that works, fine, but if not, try 5, 10, etc. Let me know if this doesn't work.
Best regards,
~Jeff -
Jeff, thanks for the tip. I wasn't previously aware of that attribute. At extremes (eg 10m), it appears much the same as the 'height' attribute. I tried it with some housing outlines overlaying aerial photography in a flat plane (no terrain data) and as small a value as 0.1 was enough to remove 'flimmer'. In the example below the graphic issue was more of a graining of the house areas, but you can see that there is none on the indicated rectangle. Also, unchecking 'Extrude 3D Areas to Surface', in 3D View Properties, helped to remove any edge artefacts.I expect the results will vary depending on the relative heights of the 3D camera, the base plane and the Z value, but your suggestion seems to provide a good result.
-
Hi Bill,
Glad that it helped you out. You're right; there's no simple way to determine a 3D_ZOFFSET value that works for everything, so some tinkering may be required. Hopefully it helped our original poster's problem as well.
Cheers,
~Jeff
Categories
- 12.8K All Categories
- 5.7K Features Discussion
- 346 Downloading Imagery
- 1.3K Elevation Data
- 385 Georeferencing Imagery Discussion
- 639 GM Script Language
- 54 User Scripts
- 115 GPS Features
- 417 Projection Questions
- 829 Raster Data
- 1.3K Vector Data
- 6.6K Support
- 179 Announcement and News
- 922 Bug Report
- 559 SDK
- 1.2K Suggestion Box
- 3.7K Technical Support
- 573 Other Discussion
- 131 GIS Data Sources
- 27 Global Mapper Showcase
- 241 How I use Global Mapper
- 108 Global Mapper Forum Website