Clamped to ground, but some lines still disappear when zoomed out

[jeaninemm]

We are working on plans for a new hiking trail going from the border
of Manhattan to Mt. Marcy in the Adirondacks. All the lines are
clamped to ground. The lines behave differently when zoomed out.

The plans are at newmedia.purchase.edu/~Jeanine/hudsontrail/
hudsontrail.kmz

Thanks in advance.

Jeanine

[ManoM]

Hi Jeanine,

I am not able to reproduce the problem on either Windows or Linux.
What version of Google Earth are you using? At what altitude do they
disappear?

ManoM

[barryhunter [KML Guru]]

FWIW, I see the same,

At about 40km the line starts to disappear - kinda like a dither
pattern, by about 60km its 75% gone, above about 100km only a few dots
left, by 230km totally gone. Same effect while tilted, with dither-
fading as move away from the camera.
Only happens when Terrain is enabled in Layers, otherwise always
visible.

4.2.0205.5730 on XP with DirectX 8

(Other layers with long streight lines (ie far less points) (but with
tesslerate and clamptoground on) show fine at the same time in the
same area)

[barryhunter [KML Guru]]

PS
http://groups.google.com/group/kml-support/web/fadescreenshot.jpg

[jeaninemm]

Good morning,

Thanks for looking into this.

The trail does show when viewed in Google Maps, and I guess that is
the important thing since, presumably, most of the people will use
that. However, I would like to understand it. Why does the
northernmost lines remain solid? Is this some interference issue?
Should I and how do I turn off layers?
This is the About Google Earth for me:

Google Earth
4.2.0198.2451 (beta)
Build Date
Sep 12 2007
Build Time
15:35:46
Renderer
DirectX 8
Operating System
Microsoft Windows XP (Service Pack 2)
Video Driver
00001002 (00006.00014.00010.06542)
Max Texture Size
2048x2048
Server
kh.google.com
User

License Key


Any general suggestions will be most appreciated.

thanks,
Jeanine

On Jan 3, 8:16 pm, barryhunter [KML Guru] wrote:
> PShttp://groups.google.com/group/kml-support/web/fadescreenshot.jpg

[ManoM]

Hi Jeanine,

Is it disappearing behind terrain? If it's clampToGround, it would do
that.

[Jonathan van Tuijl]

ManoM wrote:
> Is it disappearing behind terrain? If it's clampToGround, it would do
> that.

The line does act funky here but it's nowhere as severe as on Barry's
screenshot; a discontinuity larger than a pixel or two is rare. No
significant parts disappear or disappear more often no matter what I
do, except when they're really obscured by terrain (this requires a
tilt in the high 80s at distance).

Could this have to do with the graphics API used? Both people seeing
problems use DirectX. I use a Mac=OpenGL.

Jonathan

[barryhunter [KML Guru]]

Don't think so, it happens from directly overhead too. I just did an
tilted view to show it gets worse further from the camera.

On Jonathan suggestion changed to OpenGL mode*, and the problem
disappears :)


*Might leave it there in fact, GE seems a lot smoother, but does seem
to use more memory now :(

[jeaninemm]

Hello, all,
I am still very new to this.
Please explain terrain. Would it be the case that there is more
terrain to interfere towards the south, than up at the northern trail
head? The lines show up when I zoom in so I don't exactly have a
problem, but...for me to share this with other folks, I want it to be
clearly and easily visible.
How do I "disable terrain in layers" and is that something I want to
tell other folks to do?

thanks,

Jeanine

[jeaninemm]

Folks,
I just tried it again. Terrain was NOT clicked in the layers. When
terrain is clicked, all the lines go away. When it is not clicked, the
southern links being spotty and the northernmost (in the more unbuilt
up up state NY) being present occurs.

Jeanine

[Jonathan van Tuijl]

barryhunter [KML Guru] wrote:
> On Jonathan suggestion changed to OpenGL mode*, and the problem
> disappears :)
>
> *Might leave it there in fact, GE seems a lot smoother, but does seem
> to use more memory now :(

I'm not an expert in this area, but I've read a few times that
textures work a bit differently in OpenGL and Direct3D. Direct3D would
throw textures away in some cases whereas OpenGL wouldn't, but at the
cost of having to keep another copy (but the app doesn't need to keep
its own copy around). Or something. Here are ways to reduce this
somewhat on Mac OS X:
http://developer.apple.com/documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_texturedata/chapter_10_section_2.html

Speaking of this, Google Earth could improve a bit (if not the OpenGL
driver). With GE running I've had short freezes when VRAM filled up,
caused by a non-DMA texture transfer out of VRAM back to RAM to make
space (this occurs at about 10 MB/s on my hardware (checked with
OpenGL Driver Monitor), during which the whole machine appears to be
locked up). That should only happen if there's no copy around in RAM,
which can be caused by a PARTIAL texture upload with glTexSubImage2D,
even though the whole thing is in fact replaced (I told GE to use
256x256 textures). Has any testing been done with plain glTexImage2D
in such cases? With a good driver it shouldn't matter, but it might
improve things. Maybe experiment a bit with the Apple extensions on OS
X as well.

Note that I didn't actually check how GE handles textures. Only the
evidence like short lockups is certainly real.

I should add that terrain (I used the highest-res terrain for testing)
doesn't influence me much. Just a bit of depth thrashing.

Jonathan