Hi, On 2. Oct 2010, at 18:13, Martin Lambers wrote:
>> A canvas represents one logical projection surface, e.g., a >> PowerWall, a curved screen or an immersive installa- tion. One >> configuration might drive multiple can- vases, for example an immer- >> sive installation and an oper- ator station. >> >> A segment represents one output channel of the canvas, e.g., a >> projector or an LCD. A segment has an output channel, which >> references the chan- nel to which the display device is connected. > > So instead of defining multiple wall geometries, one would now define > one wall geometry that represents the canvas and then subdivide this > into multiple segments? And the reason for this would be that the output > channel then knows which part of the complete canvas it is rendering to? > Or is there another reason to use canvas/segment definitions? The main reason in to have 2D spatial information of the individual displays (segments) forming one display (canvas). For planar canvases (aka PowerWalls) the frustum (wall) definition is simplified, since it can be specified on the canvas level, and the segment frusta are calculates using the 'canvas frustum x segment viewport'. >> A layout is the grouping of logical views. It is used by one or more >> canvases. For all given lay- out/canvas combinations, Equalizer >> creates des- tination channels when the configuration file is loaded. >> These destination channels can be refer- enced by compounds to >> configure scalable render- ing. >> >> A view is a logical view of the application data, in the sense used >> by the Model- View-Controller pattern. It can be a scene, viewing >> mode, viewing position, or any other representation of the >> application’s data. > > OK, I'm lost here. From the examples, I get the vague idea that > different layouts can group the same ressources into different > configurations, and different views can apply to different parts of a > layout. Is that right? What would this be used for? My impression is > that in most cases, you only have one fixed setup and thus do not need > any layouts or views. The main reason is to be able to display multiple views (not bound to segments) on a canvas, e.g., to compare to models side-by-side. Layouts can be switched at runtime. Views are non-overlapping and normally cover the full layout/canvas. 2-window.layout is a good example for this. Normally one would have one single-view layout per canvas. They are abused to switch different decomposition modes in some example configs. For a fixed setup you don't need canvases/layouts, the loader creates them automatically for you, based on the compound structure and walls. Have a look at the 'real' config used, which is printed in debug after loading & conversion. >> A view might have an observer, in which case its frustum is tracked >> by this observer. An observer represents an actor looking at multiple >> views. It has a head matrix, defining its position and orientation >> within the world, and an eye separation. > > There is always implicitly a default view with a default observer, > right? In our VR environment, we never define views or observers, but > tracking works anyway. So is defining observers only required for very > special applications? Right, the loader creates a default observer for you if there are none in the config. You need to configure them explicitly if you want untracked views (no observer) or multiple observers, e.g., two HMD's in one config. HTH, Stefan. _______________________________________________ eq-dev mailing list [email protected] http://www.equalizergraphics.com/cgi-bin/mailman/listinfo/eq-dev http://www.equalizergraphics.com
