liquidgalaxy / liquid-galaxy Goto Github PK

LG rigs are generally controlled by a SpaceNavigator mouse not a keyboard and 
mouse.

There are some modes of Google Earth eg. StreetView and Panoramic image mode 
that ignore the SpaceNavigator controller. This is a pain!


Workaround: If the LG view master is a machine which is not part of the 
panoramic display rig, for example a laptop. Then modes like StreetView can be 
setup to mostly work. The rig nodes flip into "StreetView" (has to be done 
manually at the moment), while the master stays in normal view mode maintaining 
SpaceNavigator control. The Master can travel around as normal while the slave 
views follow showing panoramic StreetView imagery.

Liquid Galaxy rigs take up physical space in the real world it would be good to 
mirror that space in the Google Earth world.

eg. a 3m diameter rig shouldn't be able to have a view which is completely 
inside an object less than 3m in size.

To do this the view clipping plane, the point at which objects are sheared as 
they 'pass thru the screen', would need to be set per rig.

Being about to modify this clipping plane distance for different scenarios 
would be a useful feature.

Andrew

Hi guys - just an update on that issue (#4 now closed) I was having with the 
slave view being rolled.

Actually the slave vector IS pointing in the right direction after the 
yaw-pitch-roll's are applied relative to the view master... so what I thought 
was a bug, isn't really. 

However, to be useful after the slave view is pointing in the right direction 
an addition "roll" operation is needed to reorient the view.

So, basically yaw/pitch/roll let's you point the slave in any direction 
relative to the master, but you need to be able to re-orient final view to 
finish things off. Perhaps there is an additional config for the slaves that 
can be used in the drivers.ini to do this?

Cheers, Andrew

ViewSync contains 'view' information as well as some state data eg. planet.

We should investigate separating what is needed for view linking to create the 
panoramic view from any "state" data.

* streamline the UDP datagram by removing information that is unnecessary

* look at using binary (BCD) packet format rather than ASCII representation of  
number. Would reduce the packet size by a good amount, could be negotiated by 
the view master?

* come up with a better method for sharing and sync'ing "state" information 
between Google Earth instances. eg. the change of Planet should be treated like 
someone turning on/off particular Layers, or choosing View->Sun. Related to 
another Issue here.

Andrew

QueryTxt allows a control station to drive the search field on the view master 
machine. This is used to "fly" the rig view to different destinations by 
entering a search term or using a pre-populated list (screensaver mode).

The rig 'flys' to the new location using the master machine Google Earth 
"Fly-To Speed" setting.

It would be very useful to have the additional ability to immediately jump to 
the new location (equivalent to setting the Fly-To Speed to Fast).

Suggesting a "jumptoview=" as an enhancement of the current "flytoview=" 
command in QueryTxt.

Potentially this would have flow-on benefits for syncronising views (picking 
different masters) among a set of geographically separated LG rigs.

Andrew

Earth continues to spontaneously crash on Liquid Galaxy.  This January we did 
some troubleshooting and resolved to wait until we upgraded to Ubuntu 11.04 and 
its newer version of glibc.  After upgrading, the crashes are much less 
frequent, but they persist.

An example is included in this comment, though there are a few other variations 
as well.

lg@lg1:~/.googleearth/crashlogs$ cat ./crashlog-4e14bc3d.txt
Major Version 6
Minor Version 0
Build Number 0003
Build Date May 17 2011
Build Time 00:40:40
OS Type 3
OS Major Version 2
OS Minor Version 6
OS Build Version 38
OS Patch Version 0
Crash Signal 6
Crash Time 1309981757
Up Time 836.742

Stacktrace from glibc:
./libgoogleearth_free.so(+0xab953)[0xf7728953]
./libgoogleearth_free.so(+0xabad3)[0xf7728ad3]
[0xf7791400]
/lib32/libc.so.6(abort+0x17e)[0xf52362ce]
/lib32/libc.so.6(+0x61277)[0xf5269277]
/lib32/libc.so.6(+0x6b511)[0xf5273511]
/lib32/libc.so.6(+0x6bcae)[0xf5273cae]
./libQtCore.so.4(_Z5qFreePv+0x1d)[0xf73e609d]
./libQtCore.so.4(_ZN10QByteArrayaSERKS_+0x53)[0xf73eedd3]
./libQtCore.so.4(_ZN10QByteArray6appendERKS_+0xe0)[0xf73eeed0]
/opt/google/earth/free/libviewsync.so(_ZNK5earth8viewsync15ViewSyncMessage8ToStr
ingEv+0x4e)[0xea6d385e]
/opt/google/earth/free/libviewsync.so(_ZN5earth8viewsync14UDPMessageSink5WriteER
KNS0_15ViewSyncMessageE+0x21)[0xea6d3bc1]
/opt/google/earth/free/libviewsync.so(_ZN5earth8viewsync6Sender11OnBeginDrawERKN
S_4evll11UpdateEventE+0x224)[0xea6d4c44]
/opt/google/earth/free/libevll.so(_ZN5earth7EmitterINS_4evll14UpdateObserverENS1
_11UpdateEventENS_19EmitterDefaultTraitIS2_S3_EEE8DoNotifyEPNS_10SyncNotifyIS2_S
3_S5_EEMS2_FvRKS3_ESB_+0x8a)[0xef604b0a]
/opt/google/earth/free/libevll.so(_ZN5earth4evll17RenderContextImpl15NotifyBegin
DrawEv+0x147)[0xef5cbcc7]
/opt/google/earth/free/libevll.so(_ZN5earth4evll13VisualContext6RenderEjRKNS1_10
PhotoStateE+0x123)[0xef6f5e03]
/opt/google/earth/free/libevll.so(_ZN5earth4evll13VisualContext4DrawEj+0x2d8)[0x
ef6f7c48]
/opt/google/earth/free/libevll.so(_ZN5earth4evll17RenderContextImpl4drawEv+0x18f
)[0xef5fba1f]
./librender.so(_ZN12RenderWidget10paintEventEP11QPaintEvent+0x37)[0xf4a8ee67]
./librender.so(_ZN5earth6render11RenderTimer4FireEv+0x1d)[0xf4a7e86d]
./libbase.so(_ZN5earth5Timer8dispatchEv+0x33)[0xf4feb9e3]
./libbase.so(_ZN5earth11QtFramework18CommandCustomEvent8dispatchEv+0x23)[0xf5023
0a3]
./libbase.so(_ZN5earth11QtFramework11customEventEP6QEvent+0x40)[0xf5020910]
./libQtCore.so.4(_ZN7QObject5eventEP6QEvent+0x42f)[0xf74fec4f]
./libQtGui.so.4(_ZN19QApplicationPrivate13notify_helperEP7QObjectP6QEvent+0xac)[
0xf6a5569c]
./libQtGui.so.4(_ZN12QApplication6notifyEP7QObjectP6QEvent+0x426)[0xf6a60666]
./libQtCore.so.4(_ZN16QCoreApplication14notifyInternalEP7QObjectP6QEvent+0x78)[0
xf74ecba8]
./libQtCore.so.4(_ZN23QCoreApplicationPrivate16sendPostedEventsEP7QObjectiP11QTh
readData+0x30b)[0xf74ee00b]
./libQtCore.so.4(_ZN16QCoreApplication16sendPostedEventsEP7QObjecti+0x2d)[0xf74e
e0fd]
./libQtGui.so.4(+0x1f7b51)[0xf6b0fb51]
./libQtCore.so.4(_ZN10QEventLoop13processEventsE6QFlagsINS_17ProcessEventsFlagEE
+0x49)[0xf74ebb39]
./libQtCore.so.4(_ZN10QEventLoop4execE6QFlagsINS_17ProcessEventsFlagEE+0x102)[0x
f74ebd12]
./libQtCore.so.4(_ZN16QCoreApplication4execEv+0xaf)[0xf74ee1bf]
./libQtGui.so.4(_ZN12QApplication4execEv+0x27)[0xf6a55177]
./libgoogleearth_free.so(_ZN5earth6client11Application3runEv+0x605)[0xf7732ba5]
./libgoogleearth_free.so(+0xaa40b)[0xf772740b]
./libgoogleearth_free.so(earthmain+0x247)[0xf7728587]
./googleearth-bin[0x804872b]
/lib32/libc.so.6(__libc_start_main+0xe7)[0xf521ee37]
./googleearth-bin[0x8048671]

The attached diff fixes several spelling errors in place names, and updates the 
Burj Dubai which is now known as the Burj Khalifa.

With the Weather-> Clouds Layer enabled the rain/snow visual effect is great 
but stops after 1 minute if the view isn't updated.

It looks very weird with "frozen" rain drops and snow!

I'd like a setting that allowed the weather effects run continuously regardless 
of whether the view is changing or not. It's not as if we need to preserve any 
system resources, as Google Earth is the only application running on a Liquid 
Galaxy system.

Andrew

Choosing "View->Sky" switches all the displays to Sky mode, however the view is 
not displayed correctly across the system.

It would be fantastic to have Sky working for those Liquid Galaxy setups in 
Museums. Would be of great benefit to displays in Observatories and 
Planetariums.

No workaround at the moment.

(also reported to google earth bugs - putting it here because LG users will see 
it a lot!)

Fly to base of the Eiffel Tower, Paris.
Start looking up into the tower (so it is the only building in view).
Now toggle the Weather->Cloud layer on.

The building disappears when the clouds come on *doh*

Happens on any building, best seen with tall structures.
It does the same on Mac/Linux/Windows GE 6.0.2, has done this for as long as 
I've used GE.

The auto-generated Mountain tours in Google Earth are great.

However the default angle of pitch (seems about 30degrees?) is generally too 
high for the wide-panoramic view in Liquid Galaxy setups. Also the default 
rotation speed is too fast for an immersive setup... makes people want to throw 
up!

An angle which was lower, showing more horizon, would be better.

Having a drivers.ini setting for the "auto-tour default pitch", so it could be 
set at different angle on the master instance of Google Earth. Or at least 
high/low.

And another setting for "auto-tour rotation speed", perhaps just as a fraction, 
eg. 0.1 = 10x slower.


Where to find Mountain tours -
"tick" Layers -> Borders and Labels -> Labels -> Mountains
Go to a mountain, click on the mountain icon, then select "Fly on a Tour".

We seem to get a lot of requests from people trying to set a Liquid Galaxy on a 
flat video wall. This isn't what the original ViewSync mods to Google Earth 
were designed for!

I can't imagine it would be hard to modify ViewSync to also be used for 2D wall 
compositing.

Could use ViewSync/horizFov to set the total "wall" field-of-view?

Would need to add ViewSync/totalX=X & ViewSync/totalY=Y to set number of 
screens in the video wall, and a ViewSync/thisX=y and ViewSync/thisY=y to set 
the display for individual GE.

To start with assume all the screens are the same size, and evenly divide up 
the view by the number of X & Y screens.

eg. for the top left screen in a 2x2 tile, which has a horizFov of 35 degrees, 
the config would be...

ViewSync/horizFov=35
ViewSync/totalX=2
ViewSync/totalY=2
ViewSync/thisX=0
ViewSync/thisY=0

The normal Liquid Galaxy pitch/yaw/rollOffsets would be ignored.

Should also have a bezel X & Y width factor.

Andrew

NetworkLink KML's are a very useful way of getting data into Liquid Galaxy.

Unfortunately each display (a Google Earth instance) act's independently as far 
as the RefreshInterval.

This means that seamless panoramic views of a dynamic KML datasets are not 
possible because individual displays are syncing at different times. 

eg. Zurich real-time Air Traffic 3D.

http://www.idp.zhaw.ch/de/engineering/idp/forschung/transport-and-traffic-engine
ering/real-time-air-traffic-in-3d.html

Although this looks great, the planes update at different times, all on 
separate 1 second refreshes. Planes get cut-off between LG displays.

Workaround: none known.

Proposed solution: somehow lock KML refreshes to a clock tick?

To reproduce:
1. Create a new touchscreen BookmarkGroup with a slug called something other 
than "earth", "moon", or "mars".
2. Try selecting its icon on the legacy touchscreen interface.
3. Curse when it does not appear and Javascript errors come out instead.

The toggleExpand() and noneExpand() JavaScript functions handle showing and 
hiding the touchscreen bookmark menus.  But they're woefully unable to handle 
menus for groups other than "earth", "moon", "mars", and "layers".

http://code.google.com/p/liquid-galaxy/source/browse/display_control/templates/t
ouchscreen_legacy.html?repo=lg-cms#29

http://code.google.com/p/liquid-galaxy/source/browse/display_control/static/touc
hscreen_legacy/javascript.js?repo=lg-cms#165

Please refactor this functionality any elegant and scalable way you see fit.

Also try adding a functional test so Selenium may confirm this works.

More a would-be-nice feature request than anything else.

Would be great to toggle on/off the top menu-bar in fullscreen mode, the same 
way Tools menu can be.

The one thing that every Liquid Galaxy rig has (up till now) is a grey streak 
along the top of all the monitors... which just doesn't look very good.

We probably want it so if the mouse/pointer is moved up to the top of the 
screen the menu reappears, as well as a key combination and right-click menu 
option.

With X11/Linux there is a workaround using a window placement app like 
Devilspie to force the menu-bar to be off the screen.

Cheers, Andrew.

Hi, In GE6 there is a new ground-level streetview mode... which is pretty cool!

There are two ground-level modes - Street View and the Building View.

Building View is the same as the 'standard' view and besides new control i/face 
doesn't offer anything new for LiquidGalaxy.

However Street View loads up the Street View pano's, which works brilliantly on 
LiquidGalaxy!

But we don't have any easy way to switch all the LG display machines 
automatically between the two modes.

You can manually do it on each machine, but obviously that can be cumbersome.

Perhaps we could extend the viewsync packet?

If I recall the last parameter determines the "planet", eg. "moon",
"mars", "sky", with the empty string "" meaning "earth".

By adding "streetview" to the list, the LG slave machines could then switch to 
the Earth/Streetview mode.
The empty string "" would then mean Earth/BuildingView.

As the master machine toggled between StreetView/BuildingView that state would 
then be replicated on the view slaves.

Happy to discuss this in more detail.

Cheers, Andrew

University of Western Sydney

If a queries.txt entry has a roll in it, eg. the Sydney one has a roll of a 
couple of degrees, and the user uses that as the starting point for exploring. 
Then their view will be slightly rolled forever! Until they select other POI or 
do a search which resets the roll to 0.

So, we should make sure none of the queries.txt entries have <roll>num</roll> 
in them.

Andrew

Hi guys - just an update on that issue (#4 now closed) I was having with the 
slave view being rolled.

Actually the slave vector IS pointing in the right direction after the 
yaw-pitch-roll's are applied relative to the view master... so what I thought 
was a bug, isn't really. 

However, to be useful after the slave view is pointing in the right direction 
an addition "roll" operation is needed to reorient the view.

So, basically yaw/pitch/roll let's you point the slave in any direction 
relative to the master, but you need to be able to re-orient final view to 
finish things off. Perhaps there is an additional config for the slaves that 
can be used in the drivers.ini to do this?

Cheers, Andrew

This is probably an 'enhancement' for the GE client, not just applicable for 
Liquid Galaxy setups.

Being able to dynamically change the 'camera frustum' in GE dynamically from 
ViewSync would enable head-tracking as well as stereoscopic 3D in LG rig.

You can't tell me anyhow who's used Liquid Galaxy hasn't thought about using 
3d-capable LCD's and head-tracking gear so you can "look around" the window 
frames... well without frustum control you can't do that! You need two slightly 
off-axis views. GE always assumes the view camera is looking directly at the 
scene ie. everything is perpendicular to view plane, in real life the only 
thing directly perpendicular/on-axis is your nose!

(http://cs.anu.edu.au/~Hugh.Fisher/3dteach/stereo3d-devel/vrprog-view.html)

It appears 'something' may already be in the GE app, but not user controllable?
http://groups.google.com/group/kml-support-advanced/browse_thread/thread/c5b357d
e4867eee6/30e20ba9a195ac6b

I'm no 3D/VR expert so some of the terminology may be way off, but i can still 
see the need.

Cheers, Andrew.

Need zoom offset setting to compensate for different display sizes in the 
drivers.ini file

Panoramic imagery in Google Earth eg. 360cities doesn't work viewed across 
entire rig.

If the 360Cities layer is enabled, entering the panographs on the master 
machine DOES NOT automatically enter the Pano on the slave displays and sync 
the views on each node.

I'd think this would be one of the obvious use cases for a panoramic display 
system like Liquid Galaxy.

You can view the low-res preview immersively within LG, but it's hardly 
inspiring!

Currently no workaround.

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?


What version of the product are you using? On what operating system?


Please provide any additional information below.

The standard way to tell an X11 application where to place it's windows is with 
the geometry parameter. 

See http://www.xfree86.org/current/X.7.html#sect6

It would be great if google earth app for Linux would honour this and allow the 
main window to placed at specified location and size. This is particularly 
useful in multi-screen setups where you may want to only run GE on the second 
or third screen. Or to go 'fullscreen' on the second screen but not on the 
first, etc.

eg. google-earth --geometry 1280x1024+1280+0 would place GE fully on the second 
screen of a 2 head 1280x1024 setup.

For Linux/X11 there are workarounds, with placement apps like Devilspie which 
can force the layout of X11 windows. 

Cheers, Andrew.

[deleted issue]

G'day - I think ViewSync/rollOffset is being interpreted incorrectly.

Example Setup - I want the View Master to appear like a GPS tracker and always 
views "down" (think Google Maps rather than Earth).

So, the View Master points at the ground (ie. towards centre of earth). And the 
set of View Slaves rollOffset by X degrees (say 30degrees each) and then pitch 
up 90degrees relative to the master to show a horizon line.

On the Slave when ViewSync/rollOffset is 0.0 and pitchOffset=90 this looks 
fine. Master points at ground, Slave shows horizon line (with same compass 
bearing as Master).

However on the next Slave, say rollOffset=30.0, the rollOffset seems to be 
applying twice. The slave is moved around the compass (good), but then the view 
is also rolled on itself (bad)!

The simplest way to show this... setup master pointing at ground and North 
being "up" the screen.

Setup Slave with "yawOffset=0.0 rollOffset=90.0 pitchOffset=90.0"

When the views are synced, the compass on the Slave will point towards East 
(this is correct), but the view is then rolled 90 degress off horizontal.
See attached image for an example of what happens.

Cheers, Andrew.

When viewing indoor Street View imagery eg. Art Galleries, Museums, etc. on a 
Liquid Galaxy rig the views are sync'd pretty much okay, but when zooming to 
look at details there is distortion between the LG displays.

Also sometimes the navigation between 'bubbles' can be a bit jumpy and appear 
disconnected. It's not as seamless as the outdoor Street View. The disconnected 
effect is probably exacerbated by the lake of depth information which the 
outdoor imagery has and which helps connect them together.

I will need to attach a screenshot/video of what happens.

Using a SpaceNavigator to fly-down to and navigate around at street-level works 
well.
And the auto-switching from 'normal view' to 'streetview/building' mode works 
okay.

However the height that the ground-view kicks in is a little bit eager 
especially when using the "StreetView" imagery.

There's a lot of distortion of the 3D Streetview pano "bubble" until the viewer 
get's down to the sweet spot.

Being able to control the 'diameter' for when the StreetView bubble comes into 
view would be nice.

Same problem for when leaving the StreetView bubble, seems it's only switches 
off when you leave the full diameter of the bubble. At which point the imagery 
is pretty much nonsensical.

Happy to provide images/videos of this happening.

Cheers, Andrew.

Prerequisite to reviewing this change:

https://www.youtube.com/watch?v=IVpOyKCNZYw#t=80

What steps will reproduce the problem?

-> run lg-info on a LG with display nodes that have broken/frozen nvidia cards

What is the expected output? 

====Thermal====

42-a:
Attribute 'GPUCoreTemp' (42-a:0.0): 42.

42-i:
Attribute 'GPUCoreTemp' (42-i:0.0): 36.

42-g:
Attribute 'GPUCoreTemp' (42-g:0.0): 41.
[...]
42-d:
Attribute 'GPUCoreTemp' (42-d:0.0): 42.

42-f:
Attribute 'GPUCoreTemp' (42-f:0.0): 39.

What do you see instead?

====Thermal====

42-a:
Attribute 'GPUCoreTemp' (42-a:0.0): 42.

42-i:
Attribute 'GPUCoreTemp' (42-i:0.0): 37.

42-g:
Attribute 'GPUCoreTemp' (42-g:0.0): 41.

42-b:

<hangs here forever>


this problem exists on NVIdias that have following errors in dmesg:

[27297.939038] NVRM: os_schedule: Attempted to yield the CPU while in atomic or 
interrupt context
[27299.937346] NVRM: os_schedule: Attempted to yield the CPU while in atomic or 
interrupt context
[27301.955020] NVRM: os_schedule: Attempted to yield the CPU while in atomic or 
interrupt context
[27303.953323] NVRM: os_schedule: Attempted to yield the CPU while in atomic or 
interrupt context
[27305.951766] NVRM: os_schedule: Attempted to yield the CPU while in atomic or 
interrupt context
[27307.950072] NVRM: os_schedule: Attempted to yield the CPU while in atomic or 
interrupt context
[27309.967749] NVRM: os_schedule: Attempted to yield the CPU while in atomic or 
interrupt context
[27311.966057] NVRM: os_schedule: Attempted to yield the CPU while in atomic or 
interrupt context
[27313.964505] NVRM: os_schedule: Attempted to yield the CPU while in atomic or 
interrupt context
[27315.962810] NVRM: os_schedule: Attempted to yield the CPU while in atomic or 
interrupt context
[27318.071443] NVRM: os_schedule: Attempted to yield the CPU while in atomic or 
interrupt context
[27320.069748] NVRM: os_schedule: Attempted to yield the CPU while in atomic or 
interrupt context
[27322.068140] NVRM: os_schedule: Attempted to yield the CPU while in atomic or 
interrupt context
[27324.066454] NVRM: os_schedule: Attempted to yield the CPU while in atomic or 
interrupt context
[27711.584456] NVRM: Xid (0000:01:00): 56, CMDre 00000000 00000080 00000000 
00000005 00000027

This isn't a LG specific issue.

The new "inside" Street View imagery eg. museums and art galleries, is great. 
However, if you have the 3D Building layer turned on the models hide the blue 
lines which indicate where the SV imagery is.

For example, go to the "London National Gallery", with 3D Buildings turned off.
Pick up the peg man and you will see internal imagery available which you can 
easily navigate to.
Try doing the same thing with "3D Buildings" turned on.

Cheers, Andrew.

What steps will reproduce the problem?

1 In Google Earth check View->Grid
2 Fly down to low altitude and then tilt horizon up.

At a point a crazy mess of grid lines appears on the horizon.

Workaround: none.

Expected Output: grid line should 'flow' over the surface... not thru it.

visually pretty crappy!

A quick fix would be to stop drawing lat/long lines when the font labelling 
disappears (maybe?)

Would prefer to have nice accurate grids following the terrain though.

Happens with GE6 on Windows and Mac. Linux not tested.

Not just a Liquid Galaxy thing...

The auto-generated tours for Mountains in GE is pretty good.

Can we please have the same thing for buildings?

UI example:

Search for "Eiffel Tower, Paris"
Fly to Tower.
Click on Tower.
Get the pop up.
Click "Fly on a Tour".

http://xkcd.com/792/ recommends implementing weekly CoD4 tournaments.  CoD is 
not Free software, so we chose Cube2:Sauerbraten instead, adding viewsync 
features to support immersive play in the liquid galaxy.

See http://code.google.com/p/liquid-galaxy/wiki/OtherApplications for details 
and a youtube video (scroll to the bottom).

Not an issue more an update for QuickStart page, but I'm not sure where to send 
wiki updates!

FYI the Mac OS X drivers.ini usually lives in - 

/Applications/Google Earth.app/Contents/MacOS/drivers.ini

Actually I haven't tried ViewSync yet to/from Mac yet, but assume it'll work 
okay with 5.2 GE.

Cheers, Andrew.

GE Client is great and all but we are really missing a programmable API.

The only API that exists for Earth is the Javascript API that requires Google 
Earth to be run as a browser plugin.

Most (all?) Liquid Galaxy systems are running Linux, there isn't a Google Earth 
Plugin available for Linux.

We really need the plugin working to bring the amazing plugin content into 
these immersive Google Earth environments.

A Linux plugin is a fairly popular request, just adding "Liquid Galaxy" weight? 
:)

See http://code.google.com/p/earth-api-samples/issues/detail?id=117

What steps will reproduce the problem?
1. visit a place with multiple floors and walk around. You can try to visit 
CERN computer centre for example.

What is the expected output? What do you see instead?
Should have all the screens showing the same panoid, but each single screen is 
jumping randomly between the floors.

What version of the product are you using? On what operating system?
Linux with latest sources to date.

Please provide any additional information below.
the real issue is that the synchronization mechanism is not taking into account 
the floor, so at the end I think it will go to the google earth devs.

[deleted issue]

G'day - another enhancement request.

Being able to send viewsync updates to remote (or local) systems via multicast 
is something that would be useful.

Use case examples:

1. linking multiple Liquid Galaxy setups together which are on different 
locations on different networks. 

2. sending out views to multiple remote GE clients, say distributing around a 
campus network or distributed classroom environment.

We use multicast for collaboration over AccessGrid (www.accessgrid.org) it 
relies on multicast to deliver video/audio & other application data to sites 
involved in realtime collaboration activity.

Multicast addresses are in the address range 224.0.0.0 - 239.255.255.255
The packets normally have an user defined time-to-live (ttl) ie. how many hops 
they can travel as a maximum.

I don't think this would take much work to add to the existing ViewSync send 
and receive code.

Possible additional drivers.ini settings, and examples...

ViewSync/muticast_address = 239.255.1.1 (this would be used on the master and 
slaves)
ViewSync/multicast_ttl = 127 (needed just on the master)
ViewSync/port = 21567 (used just the same way)

Or you could use the existing ViewSync/hostname and add ViewSync/ttl.

If GoogleEarth was multicast-aware it would be an app that would have an 
immediate application as a collaborative tool in AccessGrid facilities.

A workaround is to have a service acting as a UDP-to-multicast relayer/bridge. 
The View Master sends the UDP packets to that listener and it would be 
responsible for re-sending the packet using a configured multicast address. At 
the other end the reverse would be needed. Actually I'm assuming the ViewSync 
packets are sent via UDP I haven't checked.

Cheers, Andrew.

IT Research Support / ITS / University of Western Sydney

Some of the fantastic content in GE is locked away from Liquid Galaxy users.

1. We need a method to trigger or open the KML(?) popup/bubbles for those rigs 
without a mouse.

2. When the popup or bubble is displayed it needs to move around the rig, from 
screen to screen. Not stay trapped withing a single GE instance.

Andrew

I'd been reading all the closed and opened posts, trying to figure out what is 
my issue.

We setup a 5-screen LG project, computers are setup in this way

SL01 LS02 MASTER SL03 LS04

and yawOffSet degrees are
74 36.5 0 -36.5 -74

horizFov is 36.5 as LG wiki adviced. We tested first in 3 laptops and the 
attached external displays and rotate the projection. Now that we are using 5 
WS with NVIDIA Quadro K620 videocard, we are not able to sync the zoom in the 5 
screens. You could see attached image.

We'd tried the formula to calculate degree per each screen, everythings should 
be running ok. 

By the way, we just have set-up the Google Earth but haven't applied yet the LG 
code.

Any ideas will be appreciated.

The atmospheric weather effects (rain, snow, haze) in GE are pretty cool. But 
they are tied to the radar layer which is only available in some parts of the 
world, I think? Well, I haven't seen the weather effects over Australia. 

For "demo" purposes it would be great to be able to control these effects in a 
Liquid Galaxy rig.

Cheers, Andrew.

I am using a triple head, 3 screens and extended desktop to allow an immersive 
experience in Street View (Maps) -- not as cool as LG...-- but is working fine 
for the available budget of the ngo i'm working with.

I'm trying to add the 'full screen' button on the script but I can't find a 
solution. Chrome's full screen mode doesn't provide the same experience as the 
menu bar and dock keeps showing up on mouse hover.

I appreciate any help and guidance!

all the best

This is probably an 'enhancement' for the GE client... not just applicable for 
Liquid Galaxy setups.

Being able to dynamically change the 'camera frustum' in GE dynamically from 
ViewSync would enable head-tracking as well as stereoscopic 3D in LG rig.

You can't tell me anyhow who's used Liquid Galaxy hasn't thought about using 
3d-capable LCD's and head-tracking gear so you can "look around" the window 
frames... well without frustum control you can't do that! You need two slightly 
off-axis views. GE always assumes the view camera is looking directly at the 
scene (everything is perpendicular to view plane).

It appears 'something' may already be in the GE app, but not user controllable?
http://groups.google.com/group/kml-support-advanced/browse_thread/thread/c5b357d
e4867eee6/30e20ba9a195ac6b

I'm no 3D/VR expert so some of the terminolgy may be way off! but i can still 
see the need!

Cheers, Andrew.

What steps will reproduce the problem?
1.  Use Liquid Galaxy in a Cave or HyperWall Configuration
2.  Navigate in and out of Space / High Altitude and Street View
3.  Notice the "angle" appears to change between one and the other

What is the expected output? What do you see instead?
If I am in Cave Configuration, with monitors wrapped around (and potentially 
above / below) me, I would expect to always have a view of everything around, 
even if that is Space / Stars above or behind me, and the world as I zoom in.  
The high level / space view seems to be more HyperWall oriented than Cave 
oriented.

Conversely, If I have my monitors configured for a huge HyperWall, I would 
expect it to always stay as such, no matter how many monitors I have in front 
of me in a grid or row along the wall, instead we get a wrap-around based on 
the ViewSync/*Offset values.


What version of the product are you using? On what operating system?
Google Earth: 6.0.3.2197
Ubuntu 10.04 64-bit Desktop (Linux 2.6.32.0)


Please provide any additional information below.
I believe this is a limitation of the parameters allowed in the telemetry.  
Right now there are only Three Degrees of Freedom available:
ViewSync/pitchOffset
ViewSync/yawOffset
ViewSync/rollOffset
I believe the high up / space orientation is using these more like subtle XYZ 
Offsets, not PYR Offsets, and then the closer you get to the earth / Street 
View, it converts these to be more / completely PYR Offsets (PYR being Pitch / 
Yaw / Roll).

Having Six Degrees of Freedom (XYZ + PYR) at all times would ensure we can 
configure as versatile usage as possible.


FYI - I am responsible for a Liquid Galaxy installation at NASA - Johnson Space 
Center.  If I have missed somewhere that we can control the panel / camera 
position with better fidelity than I have so far, please let me know.  
Otherwise, my experience on other robotics + VR projects leads me to believe we 
need full XYZ + PYR offset definitions in the packet, so we can position panels 
(displays / camera origins) anywhere we want.

Good day!

Ummm..I've build LG by 3 computers(1 Desktop & 2 Laptops)& it works fine on 
March.

Also I've build LG via two VM (1 Desktop + 2 VM) and it works,too.

But after a long time I'm not using it.I'm very surprised that all of them 
can't work right now...

Can someone give me some suggestion or teach me how to do? It will be a great 
thanks!

Oh! I'm running it on Win7 64bit !!

enhancement request.

(1) It'd be nice to be able to dynamically control the displayed layers on the 
view slaves from the view master (besides tweaking .ini files and restarting 
the GE clients).

(2) When a layer is opened up in the master it'd be nice to have this layer 
automatically distributed to the slaves (if it's not a layer already on the 
slave). Or at least be able to send a message to the GE clients saying "go get 
this kmz/kml from this URL".

Actually... does the GE client respond to a Unix signal to re-read it's config? 
That might be a workaround for those using Unix systems.

Cheers, Andrew.

[deleted issue]