Hi Robert,
Appearantly, I was using some pieces of code that didn't like to work
together. My imagestream can now resize at runtime, so my problem seems to
be solved. Without any locking or so, strange but true.
The code is actually very simple now:
At startup:
void NISImageStream::ConnectToServer(const std::string nisname) {
<stripped>
imageStreamReceiver = new ImageReceiver(serverHostname, serverPort,
protocol, 1500/*packetSize*/);
// No need to allocate an image here, this can be done at runtime
}
Each frame:
bool resizedImage;
if(imageStreamReceiver->Receive(resizedImage)) {
if(resizedImage) {
std::cout << "Received different size image (" <<
imageStreamReceiver->image->Width() << "x" <<
imageStreamReceiver->image->Height() << "), applying to 3D
engine\n";
// Must use setImage(), this is working. Using the combination
allocateImage() + setData() does not work!
osg::ImageStream::setImage(imageStreamReceiver->image->Width(),
imageStreamReceiver->image->Height(), 1,
GL_RGB,
GL_RGB,
GL_UNSIGNED_BYTE,
imageStreamReceiver->image->Data(),
osg::Image::NO_DELETE, // important to keep the image after
creation so that it can be filled later
1);
}
osg::Image::dirty();
}
Now I see that it is important, to avoid rescaling of each frame, to use
textures with the extension GL_TEXTURE_RECTANGLE, so with
TextureRectangle. Right?
In order to use this extension I need to use absolute texture coordinates
(image dimensions), as far as I can see? This complicates using different
sizes of texture images in the stream.
Is there a way to use 'normal' texture coordinates with range 0.0 - 1.0
for a TextureRectangle?
thanks, best regards
Raymond
> Hi,
>
>> Changing image size on the fly could be a bit problematic w.r.t the
>> threading - i.e. one threading is reading the image assuming a certain
>> size, then you change the size delete memory and reallocate leading at
>> the same time so you'd need to introduce a mutex on read and write
>> access to the osg::Image, we made need to modify osg::Image or
>> osg::ImageStream to achieve this.
>
> Yes, I understand. But I would expect a crash or so. Aren't reading and
> writing already guarded, writing new data *is* done in my_render_frame()?
>
> Anyway, I will go ahead and add locking to Image, since I believe this is
> the place to do this. I will let you know.
>
>> Double buffering would be one way around this - the writing thread
>> writes to its own image, and the reading thread reads from its own
>> image, then onces both are finished you can swap. This would still
>> need mutexing.
>
> Raymond
>
>>
>> Robert.
>>
>> On 8/9/06, Raymond de Vries <[EMAIL PROTECTED]> wrote:
>>> Hi,
>>>
>>> I have my streaming video texture plugin ready, so thanks Robert for
>>> your
>>> support. For this I have followed the strategy in ReaderWriterXine.cpp
>>> where:
>>> - allocateImage() is done in the open() routine (so once)
>>> - setImage()/setData() for each new frame
>>>
>>> Now I am working on changing the image size during streaming. I've
>>> skipped
>>> the image allocation in the open() routine and now trying to allocate a
>>> new image for the imagestream (allocateImage()) in my_render_frame()
>>> (just
>>> before setImage(), line 180 in ReaderWriterXine.cpp). This does not
>>> work,
>>> however.
>>>
>>> Anyone thought where should I allocate a new image with different size?
>>>
>>> thanks a lot
>>> Raymond
>>>
>>>
>>> _______________________________________________
>>> osg-users mailing list
>>> [email protected]
>>> http://openscenegraph.net/mailman/listinfo/osg-users
>>> http://www.openscenegraph.org/
>>>
>> _______________________________________________
>> osg-users mailing list
>> [email protected]
>> http://openscenegraph.net/mailman/listinfo/osg-users
>> http://www.openscenegraph.org/
>>
>
>
> _______________________________________________
> osg-users mailing list
> [email protected]
> http://openscenegraph.net/mailman/listinfo/osg-users
> http://www.openscenegraph.org/
>
_______________________________________________
osg-users mailing list
[email protected]
http://openscenegraph.net/mailman/listinfo/osg-users
http://www.openscenegraph.org/
