Head-In-CAVE Detection in a Cluster

[Todd Furlong]

All,

I'm working on a feature request to detect when a head tracker has left a CAVE so that we can substitute a good head tracker location instead of letting things get weird when the head-tracked person steps out.

In my draw method, I'm able to get all the active surface viewports from vrj::DisplayManager and do a point/plane test with the head to determine inside/outside.  However, I don't think this will extend to a cluster because I'll only get local viewports from the display manager, right?

I thought about trying to co-opt the cluster barrier class in order to get inside/outside information from the wall nodes by timing out on a barrier wait to determine an outside-the-CAVE status of the participating nodes, but that seems overly complicated and not very robust.

So, now I'm wondering this: At the application level, do I have access to the config system so that I can get a representation of all walls of a cluster?  I'd only need it on the master node, which should have all that data loaded.  If nobody knows, I'll keep digging, but I wanted to put it out there in case there's a quick answer to be had.

Thanks,

Todd

[Doug McCorkle]

Todd,

You do not have access to the wall information on the master node unfortunately. We have wanted this information as well but for other purposes but could not figure out a good way to make this happen. If you add all of your walls to a simulator viewport that is rendered on the master then you would have this information. This is about the only option we came up with for this problem.

Doug

> --
>
> ---
> You received this message because you are subscribed to the Google Groups "vrjuggler-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vrjuggler-dev...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[Todd Furlong]

Doug,

I've done some investigating, and I think we can get wall info from the configuration manager on the master node at least.  This test code - put in the init method -  finds definitions for all the nodes in a cluster.  The file dumped out by it includes the surface viewport descriptions for the cluster nodes, so I think we can access the wall info we need.

// Dump active config to a file
jccl::ConfigManager *configMgr = jccl::ConfigManager::instance();
configMgr->lockActive();
jccl::Configuration *config = configMgr->getActiveConfig();
config->save("/home/todd/testconfig.jconf");

-Todd

  

[Doug McCorkle]

Todd,

In this implementation then you are planning on parsing the xml to grab the data? I thought you were trying to do this all with in memory classes that are resident on the master node.

Doug

[Todd Furlong]

The configuration manager does the XML part of the parsing, but yes I'm looking to parse.  I just verified that the slave nodes have access to this config data as well, so that's a nice bonus -- each node can do its own inside/outside detection.

Each surface viewport has its own copy of the corner data, but the config system is the only place where we can get the full overview of the cluster, so I think it's correct to get it from there.  It could certainly be easier to access, but I think the means to access that data would most likely be a duplication of the approach I'm taking.

We can skip the config->save shown above and instead do:

config->getByType("cluster_node", elements);

That will get us ConfigElementPtr's for each cluster node, and then we can call getChildElements on each of those and look for "display_window", then "surface_viewport", and then finally we can get the corner locations as surface viewport properties.

-Todd

[Doug McCorkle]

On Oct 11, 2013, at 2:02 PM, Todd Furlong <furl...@gmail.com> wrote:

> The configuration manager does the XML part of the parsing, but yes I'm looking to parse. I just verified that the slave nodes have access to this config data as well, so that's a nice bonus -- each node can do its own inside/outside detection.
>
> Each surface viewport has its own copy of the corner data, but the config system is the only place where we can get the full overview of the cluster, so I think it's correct to get it from there. It could certainly be easier to access, but I think the means to access that data would most likely be a duplication of the approach I'm taking.
>
> We can skip the config->save shown above and instead do:
> config->getByType("cluster_node", elements);
>
> That will get us ConfigElementPtr's for each cluster node, and then we can call getChildElements on each of those and look for "display_window", then "surface_viewport", and then finally we can get the corner locations as surface viewport properties.

You are correct. We have done that for other window data. I did not realize all of the cluster_node elements were on all of the nodes. That is useful.

Doug