91 lines
3.5 KiB
C++
91 lines
3.5 KiB
C++
/*
|
||
MODEL-PORT.hpp - point to pull output data from the model
|
||
|
||
Copyright (C) Lumiera.org
|
||
2010, Hermann Vosseler <Ichthyostega@web.de>
|
||
|
||
This program is free software; you can redistribute it and/or
|
||
modify it under the terms of the GNU General Public License as
|
||
published by the Free Software Foundation; either version 2 of the
|
||
License, or (at your option) any later version.
|
||
|
||
This program is distributed in the hope that it will be useful,
|
||
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||
GNU General Public License for more details.
|
||
|
||
You should have received a copy of the GNU General Public License
|
||
along with this program; if not, write to the Free Software
|
||
Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
|
||
|
||
*/
|
||
|
||
/** @file model-port.hpp
|
||
** Organising the output data calculation possibilities.
|
||
** Model ports are conceptual entities, denoting the points where output might
|
||
** possibly be produced. There is an actual representation, a collection of small
|
||
** descriptor objects managed by the Fixture and organised within the ModelPortTable
|
||
** datastructure. Thus, while the actual ModelPort descriptor entities are located
|
||
** within and managed by the Fixture -- model port as a concept spans the high-level
|
||
** and low-level view. A model port can be associated both to a pipe within a timeline
|
||
** in the HighLevelModel, as well as to denote a set of corresponding exit nodes within
|
||
** the segments of the render nodes network. Model ports are keyed by Pipe-ID and thus
|
||
** are unique within the application.
|
||
**
|
||
** A model port is rather derived than configured; it emerges during the build process
|
||
** when a pipe claims an OutputDesignation and some other entity actually uses this
|
||
** designation as a target, either directly or indirectly. This match of provision
|
||
** and usage is detected by the Builder and produces an entry in the fixture's
|
||
** ModelPortTable. Because of the 1:1 association with a pipe, each model port
|
||
** has an associated StreamType.
|
||
**
|
||
** Because model ports are discovered this way, dynamically during the build process,
|
||
** at some point there is a <i>transactional switch</i> to promote the new configuration
|
||
** to be come the valid current model port configuration. After that switch, model ports
|
||
** are immutable.
|
||
**
|
||
** Model ports are to be accessed, enumerated and grouped in various ways, because each
|
||
** port belongs to a specific timeline and is used for producing data of a single
|
||
** StreamType solely. But all those referrals, searching and grouping happens only
|
||
** after the build process has discovered all model ports currently available.
|
||
** Thus we provide a MPortRef smart-pointer to ease handling of those access
|
||
** operations. The actual model port descriptors are owned and managed by
|
||
** the fixture; they are bulk allocated in a similar manner than the
|
||
** ProcNode and WiringDescriptor objects.
|
||
**
|
||
** TODO fill in more details?
|
||
** TODO where to put the ModelPortTable
|
||
**
|
||
** @see OutputDesignation
|
||
** @see OutputMapping
|
||
** @see Timeline
|
||
*/
|
||
|
||
|
||
#ifndef PROC_MOBJECT_MODEL_PORT_H
|
||
#define PROC_MOBJECT_MODEL_PORT_H
|
||
|
||
#include "proc/asset/pipe.hpp"
|
||
//#include "lib/opaque-holder.hpp"
|
||
//#include "lib/meta/typelist-util.hpp"
|
||
|
||
//extern "C" {
|
||
//#include "lib/luid.h"
|
||
//}
|
||
|
||
namespace mobject {
|
||
|
||
/**
|
||
* TODO type comment
|
||
*/
|
||
class ModelPort
|
||
: boost::noncopyable
|
||
{
|
||
|
||
public:
|
||
};
|
||
|
||
|
||
|
||
} // namespace mobject
|
||
#endif
|