benn/lumiera_
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

WIP attempt to nail down a very simple example...

Browse source
This commit is contained in:
Fischlurch 2009-08-31 01:32:53 +02:00
parent c89726e2d8
commit ddb8805a73
4 changed files with 130 additions and 7 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
src/proc/engine/nodeinvocation.hpp
View file

@ -1,5 +1,5 @@
/*
NODEINVOCATION.hpp - Organize the invocation state within a single pull() call
NODEINVOCATION.hpp - Organise the invocation state within a single pull() call
Copyright (C) Lumiera.org
2008, Hermann Vosseler <Ichthyostega@web.de>

84
src/proc/engine/render-invocation.hpp Normal file
View file

@ -0,0 +1,84 @@
/*
RENDER-INVOCATION.hpp - initiate the rendering of a single frame
Copyright (C) Lumiera.org
2009, 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 render-invocation.hpp
** Initiate a single calculation unit within the renderengine.
** Usually, this will cause the rendering of a single frame or sub-frame.
**
** @see engine::ProcNode
** @see State
** @see node-basic-test.cpp
**
*/
#ifndef ENGINE_RENDER_INVOCATION_H
#define ENGINE_RENDER_INVOCATION_H
#include "proc/state.hpp"
//#include "proc/engine/procnode.hpp"
//#include "proc/engine/buffhandle.hpp"
//#include "proc/engine/bufftable.hpp"
namespace engine {
/**
* TODO: type comment
*/
class RenderInvocation
: public State
{
protected:
// State& parent_;
// State& current_;
RenderInvocation()
{ }
virtual State& getCurrentImplementation () { return current_; }
public: /* === proxying the State interface === */
// virtual void releaseBuffer (BuffHandle& bh) { current_.releaseBuffer (bh); }
// virtual void is_calculated (BuffHandle const& bh) { current_.is_calculated (bh); }
// virtual BuffHandle fetch (FrameID const& fID) { return current_.fetch (fID); }
// note: allocateBuffer() is chosen specifically based on the actual node wiring
};
///////////////////////////////////TODO: currently just fleshing out the API
} // namespace engine
#endif

45
tests/components/proc/engine/node-basic-test.cpp
View file

@ -24,20 +24,45 @@
#include "lib/test/run.hpp"
//#include "lib/factory.hpp"
//#include "lib/util.hpp"
#include "proc/engine/nodefactory.hpp"
#include "proc/engine/nodewiring.hpp"
#include "proc/engine/render-invocation.hpp"
#include "proc/mobject/session/effect.hpp"
#include "lib/allocationcluster.hpp"
//#include <boost/format.hpp>
#include <iostream>
//#include <iostream>
//using boost::format;
using std::string;
using std::cout;
//using std::string;
//using std::cout;
namespace engine{
namespace test {
using lib::AllocationCluster;
using mobject::session::PEffect;
namespace { // Test fixture
/**
* Mock State/Invocation object.
* Used as a replacement for the real RenderInvocation,
* so the test can verify that calculations are actually
* happening in correct order.
*/
class TestContext
: public RenderInvocation
{
//////////////TODO: facility to verify the right access operations get called
};
}
/*******************************************************************
* @test basic render node properties and behaviour.
@ -47,6 +72,20 @@ namespace test {
virtual void run(Arg)
{
UNIMPLEMENTED ("build a simple render node and then activate it");
AllocationCluster alloc;
NodeFactory nodeFab(alloc);
PEffect pEffect; /////////////////TODO how to get an simple Effect MObject for Tests???
WiringSituation setup;
ProcNode* pNode = nodeFab (pEffect, setup);
ASSERT (pNode);
TestContext simulatedInvocation;
pNode->pull(simulatedInvocation, 0);
// ASSERT we got calculated data in the result buffer
}
};

6
wiki/renderengine.html
View file

@ -3877,9 +3877,9 @@ Consequently, as we can't get away with an fixed Enum of all stream prototypes,
NTSC and PAL video, video versus digitized film, HD video versus SD video, 3D versus flat video, cinemascope versus 4:3, stereophonic versus monaural, periphonic versus panoramic sound, Ambisonics versus 5.1, dolby versus linear PCM...
</pre>
</div>
<div title="StreamType" modifier="Ichthyostega" modified="200809280108" created="200808060244" tags="spec discuss draft" changecount="9">
<div title="StreamType" modifier="Ichthyostega" modified="200908302143" created="200808060244" tags="spec discuss draft" changecount="11">
<pre>//how to classify and describe media streams//
Media data is understood to appear structured as stream(s) over time. While there may be an inherent internal structuring, at a given perspective ''any stream is a unit and homogeneous''. In the context of digital media data processing, streams are always ''quantized'', which means they appear as a temporal sequence of data chunks called ''frames''.
Media data is supposed to appear structured as stream(s) over time. While there may be an inherent internal structuring, at a given perspective ''any stream is a unit and homogeneous''. In the context of digital media data processing, streams are always ''quantized'', which means they appear as a temporal sequence of data chunks called ''frames''.
! Terminology
* __Media__ is comprised of a set of streams or channels
@ -3900,7 +3900,7 @@ A stream type is denoted by a StreamTypeID, which is an identifier, acting as an
Within the Proc-Layer, media streams are treated largely in a similar manner. But, looking closer, note everything can be connected together, while on the other hand there may be some classes of media streams which can be considered //equivalent// in most respects. Thus, it seems reasonable to separate the distinction between various media streams into several levels
* Each media belongs to a fundamental ''kind'' of media, examples being __Video__, __Image__, __Audio__, __MIDI__,... Media streams of different kind can be considered somewhat &quot;completely separate&quot; &amp;mdash; just the handling of each of those media kinds follows a common //generic pattern// augmented with specialisations. Basically, it is //impossible to connect// media streams of different kind. Under some circumstances there may be the possibility of a //transformation// though. For example, a still image can be incorporated into video, sound may be visualized, MIDI may control a sound synthesizer.
* Below the level of distinct kinds of media streams, within every kind we have an open ended collection of ''prototypes'', which, when compared directly, may each be quite distinct and different, but which may be //rendered//&amp;nbsp; into each other. For example, we have stereoscopic (3D) video and we have the common flat video lacking depth information, we have several spatial audio systems (Ambisonics, Wave Field Synthesis), we have panorama simulating sound systems (5.1, 7.1,...), we have common stereophonic and monaural audio. It is considered important to retain some openness and configurability within this level of distinction, which means this classification should better be done by rules then by setting up a fixed property table. For example, it may be desirable for some production to distinguish between digitized film and video NTSC and PAL, while in another production everything is just &quot;video&quot; and can be converted automatically. The most noticeable consequence of such a distinction is that any Bus or [[Pipe]] is always limited to a media stream of a single prototype. (&amp;rarr; [[more|StreamPrototype]])
* Besides the distinction by prototypes, there are the various media ''implementation types''. This classification is not necessarily hierarchically related to the prototype classification, while in practice commonly there will be some sort of dependency. For example, both stereophonic and monaural audio may be implemented as 96kHz 24bit PCM with just a different number of channel streams, as well we may have a dedicated stereo audio stream with two channels multiplexed into a single stream. For dealing with media streams of various implementation type, we need //library// routines, which also yield a //type classification system.// Most notably, for raw sound and video data we use the [[GAVL]] library, which defines a classification system for buffers and streams.
* Besides the distinction by prototypes, there are the various media ''implementation types''. This classification is not necessarily hierarchically related to the prototype classification, while in practice commonly there will be some sort of dependency. For example, both stereophonic and monaural audio may be implemented as 96kHz 24bit PCM with just a different number of channel streams, but we may as well get a dedicated stereo audio stream with two channels multiplexed into a single stream. For dealing with media streams of various implementation type, we need //library// routines, which also yield a //type classification system.// Most notably, for raw sound and video data we use the [[GAVL]] library, which defines a classification system for buffers and streams.
* Besides the type classification detailed thus far, we introduce an ''intention tag''. This is a synthetic classification owned by Lumiera and used for internal wiring decisions. Currently (8/08), we recognize the following intention tags: __Source__, __Raw__, __Intermediary__ and __Target__. Only media streams tagged as __Raw__ can be processed.
!! Media handling requirements involving stream type classification