| Home | Research | Interests | Notes | IMS Home |
For current projects we need a more dynamic texture implementation in Open Inventor that allows a number of ways to update a texture:
The basic Open Inventor 2.1 specification does not contain nodes that implement dynamic textures. Therefore textures with sources such as video files, live camera images or renderings of scene graphs are not supported. To implement these three types of textures efficiently, direct access to the underlying OpenGL texture is required. Unfortunatly, the Open Inventor SoTexture2 implementation hides this information deep within the associated SoDisplayList object. Therefore we propose to implement a new node hierarchy based on an abstract node class that implements the basic texture functionality and exposes the necessary texture handle and a number of subclasses that implement specific uses of the texture. This allows to implement the optimal algorithms to update these textures.
Note : I browsed some more code and found that OSS Inventor stores the texture id actually in the SoGLDisplayList class that is also stored in the SoTexture2 node anyway ! Therefore one can access the texture id directly in the SoTexture2 implementation !!!! Actually the SoGLDisplayList is extended in a pretty hacky way to include texture objects once they became available (yes you can compile the inventor code without the use of texture objects). In this case it either stores a texture object (basically the id) _OR_ a display list :). Maybe we simply derive from the SoTexture2 node and just not use the image field.
Note: I'm not sure, if the above is feasable. Our main problem is that we need to create and update a texture object from outside a render traversal ! That's the main point. Therefore we can probably use the SoGLDisplayList class but may need to create it asynchronously during initialisation.
Note : Obviously, I have no clue how this works in Coin !
The following diagram gives an overview of the new nodes :
SoVideoTexture {
SoSFEnum wrapS REPEAT # CLAMP | REPEAT
SoSFEnum wrapT REPEAT # CLAMP | REPEAT
SoSFEnum model MODULATE # MODULATE | DECAL | BLEND
SoSFColor blendColor 0 0 0
SoSFInt32 width 256
SoSFInt32 height 256
SoSFEnum component RGB24 # Y, YA, RGB16, RGB24, RGBA
}
This is the abstract superclass. It provides the same interface as SoTexture2 plus additional parameters to set the size and components of the texture which are necessary because they can not be derived from a source image at this point. The specification of these parameters here are not to early, because the user will also want to provide these for video images, because they are usually not of a power of 2 size anyway and scaling is necessary to provide better performance in rendering the textures. The alternative would be to use larger textures and appropriate texture coordinates which would make the use of the nodes more complicated for the user.
Question : Should we not allow for the optimal use with texture coordinates as well for people who want to avoid the scaling operation and are know how use them ?
SoLiveTexture {
SoSFString device ""
SoSFBool isActive TRUE
}
A texture node for providing live data. It displays the contents of a video stream provided by a live video source. the string device is a platform and device dependent configuration string that is passed on to the underlying implementation. The isActive field allows a store-and-hold operation. If isActive is TRUE the stream will update the texture continously. If isActive is FALSE the last image that was set is displayed. If isActive is FALSE from the initialisation on, a single image is captured and rendered.
SoMovieTexture {
SoSFString url ""
SoSFBool isActive FALSE
SoSFTime duration 0
SoSFTime begin 0 # or in ?
SoSFTime end 0 # or out ?
SoSFFloat position 0
SoSFBool loop FALSE
}
A texture node for providing data from a video file source. It has a more elaborate interface to control the playback of the file. The string url denotes the location of the source file (can be a URL, but will be a simple filename first). isActive denotes whether it plays the file or not. If FALSE it will use the last image displayed or the first image of the shown sequence. duration is a 'read-only' field and will be set to the duration of the media file in seconds. begin and end control a segment of the video file to be played and are set in seconds relative to the beginning of the file. If end <= begin the segment from begin to the end of the file will be played (therefore the default values will play the whole file and setting only one value will also behave rather intuitively). position will output the current position in the file as a value in the interval [0,1] within the played segment. If loop is TRUE playback will loop in the given segment, otherwise it will stop at the end and display the last image after that.
SoSceneTexture {
SoSFNode scene NULL
SoSFColor backgroundColor 0 0 0
SoSFFloat backgroundAlpha 0
}
A texture node for the rendered image of a given sub-scene-graph using the SoOffscreenRenderer to directly render into the given texture (where supported). The scene-graph is configured in the scene field. A low-priority node sensor is set on the scene field to notify the node of any changes. If these happen, it will render the new view into the texture. The backgroundColor and backgroundAlpha fields allow to easily set default values, if applicable (see component field in the super class).
We do not propose to extend the MovieTexture node of the VRML97 specification because it only allows limited control of the video playback. It allows not to select a sub-segment of a video or to pause a video, or to set it to a certain position. The startTime / stopTime interfaces are redundant because they can be implemented by some external control of playback. Our proposed SoMovieTexture node can be trivially wrapped or extended to provide the full functionality of the VRML97 MovieTexture node.