Re: [Openrm-users] Changing RMimage in a texture

[R. A. K. <rak...@gm...>]

Hi Wes;

Yes, I am doing it in the way dyntmp.c does.

It shouldn't matter if it is 2D or 3D texture, right?

Let me illustrate what works (meaning the new texture appears in the next
frame) and what doesn't.

Works
--------

RMtexture * texture;
texture = rmTextureNew(3);
rmTextureSetImages(texture, &volumeImage, 1, RM_FALSE);
rmNodeSetSceneTexture(myTextureNode, texture);

Doesn't work
---------------

RMtexture * texture;
rmNodeGetSceneTexture(myTextureNode, &texture);
rmTextureSetImages(texture, &volumeImage, 1, RM_FALSE);
rmNodeSetSceneTexture(myTextureNode, texture);

-Aditya

On Mon, Jul 27, 2009 at 6:04 PM, Wes Bethel <ewb...@r3...> wrote:

> R. Aditya Kadambi wrote:
>
>> Hi;
>>
>> The guide says that to change an image (RMimage) in a texture, you need to
>> do it in two steps.
>>
>> 1. Get a pointer to texture using rmNodeGetSceneTexture.
>> 2. Set the new RMimage to this texture using rmTextureSetImages.
>>
>> This should take care of it for the Node during the next rmFrame call.
>>
>> However, it doesn't seem to work. I tried another approach. My RMimage is
>> the same as far as all the dimensions is concerned. The data is different.
>>
>> 1. Create a new texture using rmTextureNew
>> 2. Set the new RMimage to this texture using rmTextureSetImages
>> 3. Set this texture as a scene parameter to the node using
>> rmNodeSetSceneTexture.
>>
>>
>> I really don't see why the first approach shouldn't work? Any ideas?
>>
>
> Hi,
>
> The first approach is what is used in the dyntmap.c OpenRM demo program --
> it seems to work perfectly in that context.
>
> The second approach will also work, but is a bit more heavy-handed in its
> use of resources.
>
> By "not work," do you mean your newly assigned texture doesn't appear in
> the next frame?
>
> Taking a quick look at this code (rmTextureSetImages), it seems reasonably
> robust: you can reuse the same RMimage object but laden with updated pixel
> data and assign it using rmTextureSetImages and it should display fine on
> the next frame.
>
> I'd suggest taking a look at the dyntmap.c example, which uses the
> technique you're having trouble with, and see how it is different from what
> your app does.
>
> tx,
> wes
>
>
>