openrm-users

[Openrm-users] Changing RMimage in a texture

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

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?

-Aditya

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

[Wes B. <ewb...@r3...>]

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

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
>
>
>

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

[Wes B. <ewb...@r3...>]

R. Aditya Kadambi wrote:
> 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?

Correct.

> 
> 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);

Yes, that will work.

> 
> Doesn't work
> ---------------
> 
> RMtexture * texture;
> rmNodeGetSceneTexture(myTextureNode, &texture);
> rmTextureSetImages(texture, &volumeImage, 1, RM_FALSE);
> rmNodeSetSceneTexture(myTextureNode, texture);

The difference between the non-working code and dyntmap.c is your code
has the rmNodeSetSceneTexture() call. It is not needed.

The texture is already assigned to the node, you only need update its
image data with rmTextureSetImages().

Internally, OpenRM checks compares some keys to determine if it needs to
build a new texture object (first case) or update image data (second
case, which is the one you want). What is puzzling is why the image data
isn't updated in the second case after you assign an already assigned
texture again as a scene parameter.

Looking at the relevant code just now, I see that the 3D texture case
has a bug in it. The 2D texture case will work OK in case #2 (your
doesn't work case), but not for 3D textures (but it should). dyntmap.c
uses 2D textures.

Sorry about that!

Let me make the fix and put up a 1.8.0-alpha-v3 tarball in the next day
or two for you to try out.

tx,
wes

> 
> -Aditya
> 
> On Mon, Jul 27, 2009 at 6:04 PM, Wes Bethel <ewb...@r3...
> <mailto: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
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> ------------------------------------------------------------------------------
> Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
> trial. Simplify your report design, integration and deployment - and focus on 
> what you do best, core application coding. Discover what's new with 
> Crystal Reports now.  http://p.sf.net/sfu/bobj-july
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Openrm-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openrm-users

-- 
Wes Bethel -- R3vis Corporation -- voice (415) 806-6531 -- www.r3vis.com

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

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

On Tue, Jul 28, 2009 at 6:52 PM, Wes Bethel <ewb...@r3...> wrote:

>
>
> R. Aditya Kadambi wrote:
> > 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?
>
> Correct.
>
> >
> > 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);
>
> Yes, that will work.
>
> >
> > Doesn't work
> > ---------------
> >
> > RMtexture * texture;
> > rmNodeGetSceneTexture(myTextureNode, &texture);
> > rmTextureSetImages(texture, &volumeImage, 1, RM_FALSE);
> > rmNodeSetSceneTexture(myTextureNode, texture);
>
> The difference between the non-working code and dyntmap.c is your code
> has the rmNodeSetSceneTexture() call. It is not needed.
>
> The texture is already assigned to the node, you only need update its
> image data with rmTextureSetImages().
>
> Internally, OpenRM checks compares some keys to determine if it needs to
> build a new texture object (first case) or update image data (second
> case, which is the one you want). What is puzzling is why the image data
> isn't updated in the second case after you assign an already assigned
> texture again as a scene parameter.
>
> Looking at the relevant code just now, I see that the 3D texture case
> has a bug in it. The 2D texture case will work OK in case #2 (your
> doesn't work case), but not for 3D textures (but it should). dyntmap.c
> uses 2D textures.
>
> Sorry about that!
>
> Let me make the fix and put up a 1.8.0-alpha-v3 tarball in the next day
> or two for you to try out.
>
> tx,
> wes


Thanks, Wes. I will try it out.

-Aditya