openrm-users

Re: [Openrm-users] Viewports and rendering

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

R. Aditya Kadambi wrote:
> Hi;
> 
> I have set up my rendering window with 4 viewports. These 4 viewports
> are pretty much "independent" in terms of data sharing. So, events on
> one viewport do not affect the others. The data in that viewport changes
> and needs to be re-rendered.
> 
> I also have the ability to switch from 4-1 (4 viewports in 1 window)
> system to 1-1(1 viewport in 1 window). In the 1-1 system, the other
> images are not rendered. I do this via rmTraverseEnableMask(node, RM_FALSE).
> 
> I have noticed that the transformations/events in 1-1 is extremely fast,
> whereas in the 4-1 system, the transformations in the selected viewport
> become very slow.
> 
> Does RM have a mechanism where I can have the same speed in the 4-1
> system as in 1-1 system?
> 

Hi,

Ultimately, debugging rendering performance can be tricky business! That said, I can offer a few suggestions/guidelines/observations that may help.

Minimizing state changes through careful scene graph design/optimization. Each time you have an OpenGL state change, caused by a change in material property, transformation (like a rotation or other change in the modelview matrix, which the viewport operation will do), etc. you are introducing a hiccup into the graphics pipeline. Basically, to get the best possible performance, you want to minimize the number of state changes. The easiest way to do that is to set state at high level scene graph nodes (root nodes or those close to the root in depth). This way, what will happen at render time is that you will be issuing a few state change commands followed by a lengthy dispatch of drawable stuff to the graphics pipeline.

The viewport operation is a change to the modelview matrix, e.g., a state change. By itself, you shouldn't see any difference in performance going from one viewport to four viewports just due to that, except in "extreme" circumstances. By "extreme" I mean if you're scene consists of, say, 100M triangles. In that case, I might expect to see a few percent difference in absolute performance, but not that much.

My guess is that your scene graph may contain some unusual state change combinations that are combining in a particularly bad way when you have multiple viewports.

Having said all of that, I will also add that I've never personally tried a 4 viewport configuration myself!

Hope this helps,
wes

[Openrm-users] Viewports and rendering

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

Hi;

I have set up my rendering window with 4 viewports. These 4 viewports are
pretty much "independent" in terms of data sharing. So, events on one
viewport do not affect the others. The data in that viewport changes and
needs to be re-rendered.

I also have the ability to switch from 4-1 (4 viewports in 1 window) system
to 1-1(1 viewport in 1 window). In the 1-1 system, the other images are not
rendered. I do this via rmTraverseEnableMask(node, RM_FALSE).

I have noticed that the transformations/events in 1-1 is extremely fast,
whereas in the 4-1 system, the transformations in the selected viewport
become very slow.

Does RM have a mechanism where I can have the same speed in the 4-1 system
as in 1-1 system?

-Aditya

Re: [Openrm-users] Initializing OpenRM

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

Thanks, Luke, for experimenting and following up.

I'll make sure this information is propagated to the manual (and code
docs) during the next round of revisions.

wes

Luke Crook wrote:
> Hi Wes,
> 
> I have figured out the correct initialization steps for;
> :RM_PIPE_NO_PLATFORM using win32 OS calls, :RM_PIPE_WGL using win32 OS
> calls, and :RM_PIPE_NO_PLATFORM using the SDL library.
> 
> :RM_PIPE_NO_PLATFORM using win32 OS calls;
> #a - rmInit (mandatory)
> #b - Initialize rmPipe using rmPipeNew (mandatory)
> #1 - CreateWindow (mandatory)
> #2 - SetPixelFormat (mandatory)
> #3 - wglCreateContext (mandatory)
> #4 - wglMakeCurrent (mandatory)
> #5 - rmPipeSetContext (optional)
> #6 - rmPipeSetWindow or rmPipeSetWindowSize (mandatory)
> #7 - rmPipeMakeCurrent (mandatory)
> 
> :RM_PIPE_WGL using win32 OS calls;
> #a - rmInit (mandatory)
> #b - Initialize rmPipe using rmPipeNew etc. (mandatory)
> #1 - CreateWindow (mandatory)
> #2 - SetPixelFormat (mandatory)
> #3 - rmPipeSetWindow or rmPipeSetWindowSize (mandatory)
> #4 - rmPipeCreateContext (mandatory)
> #5 - rmPipeMakeCurrent (mandatory)
> 
> :RM_PIPE_WGL using the SDL library;
> #a - rmInit (mandatory)
> #b - Initialize rmPipe using rmPipeNew etc. (mandatory)
> #1 - SDL_SetVideoMode (Creates the window & OpenGL Context) (mandatory)
> #2 - rmPipeSetContext (optional)
> #3 - rmPipeSetWindow or rmPipeSetWindowSize (mandatory)
> #4 - rmPipeMakeCurrent (mandatory)
> 

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

Re: [Openrm-users] Initializing OpenRM

[Luke C. <lu...@ba...>]

Hi Wes,

I have figured out the correct initialization steps for;
:RM_PIPE_NO_PLATFORM using win32 OS calls, :RM_PIPE_WGL using win32 OS
calls, and :RM_PIPE_NO_PLATFORM using the SDL library.

:RM_PIPE_NO_PLATFORM using win32 OS calls;
#a - rmInit (mandatory)
#b - Initialize rmPipe using rmPipeNew (mandatory)
#1 - CreateWindow (mandatory)
#2 - SetPixelFormat (mandatory)
#3 - wglCreateContext (mandatory)
#4 - wglMakeCurrent (mandatory)
#5 - rmPipeSetContext (optional)
#6 - rmPipeSetWindow or rmPipeSetWindowSize (mandatory)
#7 - rmPipeMakeCurrent (mandatory)

:RM_PIPE_WGL using win32 OS calls;
#a - rmInit (mandatory)
#b - Initialize rmPipe using rmPipeNew etc. (mandatory)
#1 - CreateWindow (mandatory)
#2 - SetPixelFormat (mandatory)
#3 - rmPipeSetWindow or rmPipeSetWindowSize (mandatory)
#4 - rmPipeCreateContext (mandatory)
#5 - rmPipeMakeCurrent (mandatory)

:RM_PIPE_WGL using the SDL library;
#a - rmInit (mandatory)
#b - Initialize rmPipe using rmPipeNew etc. (mandatory)
#1 - SDL_SetVideoMode (Creates the window & OpenGL Context) (mandatory)
#2 - rmPipeSetContext (optional)
#3 - rmPipeSetWindow or rmPipeSetWindowSize (mandatory)
#4 - rmPipeMakeCurrent (mandatory)

Re: [Openrm-users] Initializing OpenRM

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

Hi Luke,

Unfortunately, I'm on travel right now and don't have ready access to either the code or the manual...will take a look when I'm back in CA and follow up in a couple of days.

tx,
wes

Luke Crook wrote:
> On Tue, Apr 13, 2010 at 12:59 PM, Luke Crook <lu...@ba...> wrote:
>> On Mon, Apr 12, 2010 at 1:37 PM, Wes Bethel <ewb...@r3...> wrote:
>>> Hi,
>>>
>>> This business of initializing OpenRM under Windows with 3rd party libraries is one of those boundary cases that I never really had the opportunity to test. Some guesses/answers below...
>> I'm still investigating. This time I used RM_PIPE_WGL which forces
>> OpenRM to create the OpenGL context.
>>
>>>> If in #3 above I assign hglrc as the OpenGL context to the pipe using
>>>> rmPipeSetContext, then I experience intermittent crashes. I'm a little
>>>> confused as to why this is.
>>> I'm wondering if there's a bug or some doc confusion with SDL...like maybe the window (hwnd) and OpenGL context are reversed somehow?
>>>
>> When using RM_PIPE_WGL, rmPipeSetContext has to be called or the
>> window remains blank.
>>
>> However, rmPipeSetContext has to be called using hwnd. (I pass the
>> result of CreateWindow to rmPipeSetContext).
>>
>> I fact, calling rmPipeSetContext using hwnd and not hglrc makes sense
>> as I'm not sure how to get hold of hglrc when OpenRM creates the
>> OpenGL context internally using RM_PIPE_WGL.
> 
> Sorry, scratch the above.
> 
> When using RM_PIPE_WGL (without using rmauxCreateW32Window) it seems
> that I have to call rmPipeCreateContext to have OpenRM create the
> OpenGL context. Is this correct?
> 
> After calling rmPipeCreateContext, do I still have to call rmPipeSetContext ?
> 
> - Luke
> 
> 


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

Re: [Openrm-users] Initializing OpenRM

[Luke C. <lu...@ba...>]

On Tue, Apr 13, 2010 at 12:59 PM, Luke Crook <lu...@ba...> wrote:
> On Mon, Apr 12, 2010 at 1:37 PM, Wes Bethel <ewb...@r3...> wrote:
>>
>> Hi,
>>
>> This business of initializing OpenRM under Windows with 3rd party libraries is one of those boundary cases that I never really had the opportunity to test. Some guesses/answers below...
>
> I'm still investigating. This time I used RM_PIPE_WGL which forces
> OpenRM to create the OpenGL context.
>
>>> If in #3 above I assign hglrc as the OpenGL context to the pipe using
>>> rmPipeSetContext, then I experience intermittent crashes. I'm a little
>>> confused as to why this is.
>>
>> I'm wondering if there's a bug or some doc confusion with SDL...like maybe the window (hwnd) and OpenGL context are reversed somehow?
>>
>
> When using RM_PIPE_WGL, rmPipeSetContext has to be called or the
> window remains blank.
>
> However, rmPipeSetContext has to be called using hwnd. (I pass the
> result of CreateWindow to rmPipeSetContext).
>
> I fact, calling rmPipeSetContext using hwnd and not hglrc makes sense
> as I'm not sure how to get hold of hglrc when OpenRM creates the
> OpenGL context internally using RM_PIPE_WGL.

Sorry, scratch the above.

When using RM_PIPE_WGL (without using rmauxCreateW32Window) it seems
that I have to call rmPipeCreateContext to have OpenRM create the
OpenGL context. Is this correct?

After calling rmPipeCreateContext, do I still have to call rmPipeSetContext ?

- Luke

Re: [Openrm-users] Initializing OpenRM

[Luke C. <lu...@ba...>]

On Mon, Apr 12, 2010 at 1:37 PM, Wes Bethel <ewb...@r3...> wrote:
>
> Hi,
>
> This business of initializing OpenRM under Windows with 3rd party libraries is one of those boundary cases that I never really had the opportunity to test. Some guesses/answers below...

I'm still investigating. This time I used RM_PIPE_WGL which forces
OpenRM to create the OpenGL context.

>> If in #3 above I assign hglrc as the OpenGL context to the pipe using
>> rmPipeSetContext, then I experience intermittent crashes. I'm a little
>> confused as to why this is.
>
> I'm wondering if there's a bug or some doc confusion with SDL...like maybe the window (hwnd) and OpenGL context are reversed somehow?
>

When using RM_PIPE_WGL, rmPipeSetContext has to be called or the
window remains blank.

However, rmPipeSetContext has to be called using hwnd. (I pass the
result of CreateWindow to rmPipeSetContext).

I fact, calling rmPipeSetContext using hwnd and not hglrc makes sense
as I'm not sure how to get hold of hglrc when OpenRM creates the
OpenGL context internally using RM_PIPE_WGL.

- Luke

Re: [Openrm-users] Initializing OpenRM

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

Hi,

This business of initializing OpenRM under Windows with 3rd party libraries is one of those boundary cases that I never really had the opportunity to test. Some guesses/answers below...

Luke Crook wrote:
> Hi Wes,
> 
> I have a question regarding the steps necessary to initialize OpenRM
> in win32 using RM_PIPE_NOPLATFORM, specifically Page 367 "Overview of
> RM Initialization", step 3.
> 
> I'm trying to figure out why everything works without me having to set
> the OpenGL context using rmPipeSetContext.
> 
> These are the steps my code performs;
> 
> #1 - Initialize OpenRM
> #2 - Create a new pipe
> #3 - Use the SDL library to create a new window. Internally SDL
> performs wglCreateContext, and wglMakeCurrent. I do not assign the
> OpenGL context to the pipe.
> #4 - Use rmPipeSetWindow to assign the window handle and dimensions to the pipe.
> #5 - Use rmPipeMakeCurrent to make the OpenGL context current.
> 
> If in #3 above I don't assign the OpenGL context to the pipe using
> rmPipeSetContext, then everything works.

This one is probably the most "stable" approach if you're not doing anything really advanced with multithreading.  The idea is that SDL sets the context and that OpenRM just chugs along issuing OpenGL comments later on that are processed by the "current context."

Anything else would require some deeper understanding of what SDL is doing. I'm not familiar with it, so can't even hazard a guess.

> If in #3 above I assign a null pointer as theOpenGL context to the
> pipe using rmPipeSetContext, then everything works.
> If in #3 above I assign hwnd as the OpenGL context to the pipe using
> rmPipeSetContext, then everything works.

I have no idea why this one works :) Doesn't seem like it should work at all.

> If in #3 above I assign hglrc as the OpenGL context to the pipe using
> rmPipeSetContext, then I experience intermittent crashes. I'm a little
> confused as to why this is.

I'm wondering if there's a bug or some doc confusion with SDL...like maybe the window (hwnd) and OpenGL context are reversed somehow? 

> 
> So it seems that it is not necessary to use rmPipeSetContext with
> RM_PIPE_NOPLATFORM, is this correct?

Without knowing anything else, like what your app is doing later, can't say for sure. If you're doing just vanilla single-threaded, single-window and single-context stuff (using any of the OpenRM nodes/primitives) it seems like you're probably OK.

HTH,
wes

Re: [Openrm-users] Initializing OpenRM

[Luke C. <lu...@ba...>]

On Mon, Apr 12, 2010 at 1:37 PM, Wes Bethel <ewb...@r3...> wrote:
> Luke Crook wrote:
>>
>> So it seems that it is not necessary to use rmPipeSetContext with
>> RM_PIPE_NOPLATFORM, is this correct?
>
> Without knowing anything else, like what your app is doing later, can't say for sure. If you're doing just vanilla single-threaded, single-window and single-context stuff (using any of the OpenRM nodes/primitives) it seems like you're probably OK.

Yes to the above as I am only replicating the OpenRM examples at the
moment. I'll make a note to come back to this if I start seeing weird
behaviour later.

Thanks,
- Luke

[Openrm-users] Initializing OpenRM

[Luke C. <lu...@ba...>]

Hi Wes,

I have a question regarding the steps necessary to initialize OpenRM
in win32 using RM_PIPE_NOPLATFORM, specifically Page 367 "Overview of
RM Initialization", step 3.

I'm trying to figure out why everything works without me having to set
the OpenGL context using rmPipeSetContext.

These are the steps my code performs;

#1 - Initialize OpenRM
#2 - Create a new pipe
#3 - Use the SDL library to create a new window. Internally SDL
performs wglCreateContext, and wglMakeCurrent. I do not assign the
OpenGL context to the pipe.
#4 - Use rmPipeSetWindow to assign the window handle and dimensions to the pipe.
#5 - Use rmPipeMakeCurrent to make the OpenGL context current.

If in #3 above I don't assign the OpenGL context to the pipe using
rmPipeSetContext, then everything works.
If in #3 above I assign a null pointer as theOpenGL context to the
pipe using rmPipeSetContext, then everything works.
If in #3 above I assign hwnd as the OpenGL context to the pipe using
rmPipeSetContext, then everything works.
If in #3 above I assign hglrc as the OpenGL context to the pipe using
rmPipeSetContext, then I experience intermittent crashes. I'm a little
confused as to why this is.

So it seems that it is not necessary to use rmPipeSetContext with
RM_PIPE_NOPLATFORM, is this correct?

- Luke

Re: [Openrm-users] Initializing OpenRM

[Luke C. <lu...@ba...>]

Hi Wes,

I have a question regarding the steps necessary to initialize OpenRM
in win32 using RM_PIPE_NOPLATFORM, specifically Page 367 "Overview of
RM Initialization", step 3.

I'm trying to figure out why everything works without me having to set
the OpenGL context using rmPipeSetContext.

These are the steps my code performs;

#1 - Initialize OpenRM
#2 - Create a new pipe
#3 - Use the SDL library to create a new window. Internally SDL
performs wglCreateContext, and wglMakeCurrent. I do not assign the
OpenGL context to the pipe.
#4 - Use rmPipeSetWindow to assign the window handle and dimensions to the pipe.
#5 - Use rmPipeMakeCurrent to make the OpenGL context current.

If in #3 above I don't assign the OpenGL context to the pipe using
rmPipeSetContext, then everything works.
If in #3 above I assign a null pointer as theOpenGL context to the
pipe using rmPipeSetContext, then everything works.
If in #3 above I assign hwnd as the OpenGL context to the pipe using
rmPipeSetContext, then everything works.
If in #3 above I assign hglrc as the OpenGL context to the pipe using
rmPipeSetContext, then I experience intermittent crashes (I'm a little
confused as to why this is.)

So it seems that it is not necessary to use rmPipeSetContext with
RM_PIPE_NOPLATFORM, is this correct?

- Luke

[Openrm-users] OpenRM v1.8.0-alpha-03

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

1.8.0 alpha v3 tarballs are now up at www.openrm.org/download.

>From the www.openrm.org/news page:

Summary of alpha-03 changes:

* 3D texture image updates buglet repaired.
* Sprite primtives: now support display lists.
* 3D texturing: more extensive capability checks to better support
Windows platforms.
* New addChildTest RMdemo program to benchmark performance of scene
graph updates.

Pls let me know if you run into any problems.

tx,
wes

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

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

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

[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

[Openrm-users] OpenGL >= 2.0 support

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

Hi Wes;

Will OpenRM support OpenGL >= 2.0 in future? I think it currently supports
1.3, correct? 2.0 can get shader/GLSL features which would be great to have
on the newer cards.

-Aditya

Re: [Openrm-users] minor problems

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

Nikitin Alexey wrote:
> Hi,
> 
> Thank you very much for version 1.8 
> I was able to compile quickly and linked with my project.
> 
> I would like to report a few problems that I noticed. 
> 
> * File /rmsync.c/ is not included in the project for /visualc/. 

Hi,

Thanks for pointing out that rmsync.c is not included with the visualc
workspace. That file is new between 1.6 and 1.8; I neglected to include
it -- my bad.

OpenRM 1.8 hasn't actually been "released" yet; you're working with a
distribution that is a "late alpha" or "early beta."

> 
> 
> *  Definition
> 
> typedef struct
> {
>   long sec;
>   long usec;
> } RMtime;
> 
> creates some incompatibilities with my C++ project.
> I do not understand what's case, but the repetition of /RMtime/ in the
> first line resolve the problem: 
> 
> typedef struct RMtime
> {
>   long sec;
>   long usec;
> } RMtime;
> 
> Could you be so kind to explain how to do it in right way? 

It sounds like you have a temporary workaround in hand. Another fix, and
the one I will implement, is to add rmsync.c to the rm180/rm workspace.

For what it's worth, 99% of the time, I do builds on windows using nmake
from the command line rather than the visual interface. In that
configuration, rmsync.c is compiled and everything seems to work OK.

> 
> 
> * For my program, there is exactly the same speed as it was in version 1.6.
> The speed does not depend on the video card. The processor is fully loaded.
> The problems arised when my model size exceed 10 000 balls. Perhaps the
> time is spent on the transformation of coordinates on the processor.
> Could you recommend something? 

In your scene graph, are the 10,000 spheres contained in one primitive,
or are they distributed across a bunch of primitives/nodes? In OpenRM,
the optimum configuration will be to have all the spheres in one
primitive: in that configuration, the entire collection will be cached
into an OpenGL display list.

I'd be curious to see the organization of your scene graph -- pls make a
call to rmPrintSceneGraph() and send me the output.

Thanks,
wes

[Openrm-users] minor problems

[Nikitin A. <agi...@gm...>]

Hi,

Thank you very much for version 1.8
I was able to compile quickly and linked with my project.

I would like to report a few problems that I noticed.

* File *rmsync.c* is not included in the project for *visualc*.


*  Definition

typedef struct
{
  long sec;
  long usec;
} RMtime;

creates some incompatibilities with my C++ project.
I do not understand what's case, but the repetition of *RMtime* in the first
line resolve the problem:

typedef struct RMtime
{
  long sec;
  long usec;
} RMtime;

Could you be so kind to explain how to do it in right way?


* For my program, there is exactly the same speed as it was in version 1.6.
The speed does not depend on the video card. The processor is fully loaded.
The problems arised when my model size exceed 10 000 balls. Perhaps the time
is spent on the transformation of coordinates on the processor.
Could you recommend something?

Best wishes,
Alexey

Re: [Openrm-users] Rendering 3D opaque objects over transparent objects

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

R. Aditya Kadambi wrote:
> Hi;
> 
> I was reading the OpenRM manual. It says that the order of rendering is
> 3D Opaque, 3D Transparent followed by 2D objects.
> 
> I am trying to render a 3D opaque object over a 3D transparent object.
> When I render it, I see the 3D transparent object only. I know that the
> 3D opaque object is there (by a switch, when I disable traversal of 3D
> transparent object, I see the 3D opaque object beneath). Is there a way
> to show the opaque object over the transparent object.?
> 

Hi,

You're correct -- rendering order is opaque 3D, transparent 3D, 2D.

If you have both a transparent and opaque object at the same spatial
location in the scene, the transparent one will always appear on top if
the transparent obj's z coordinates are closer to the viewer.
Additionally, the amount of transparency can affect how much of the
stuff behind it you can actually see.

The way to make the opaque object appear in front of the transparent
object is to assign its vertices z values that are closer to the viewer.

tx,
wes

[Openrm-users] Rendering 3D opaque objects over transparent objects

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

Hi;

I was reading the OpenRM manual. It says that the order of rendering is 3D
Opaque, 3D Transparent followed by 2D objects.

I am trying to render a 3D opaque object over a 3D transparent object. When
I render it, I see the 3D transparent object only. I know that the 3D opaque
object is there (by a switch, when I disable traversal of 3D transparent
object, I see the 3D opaque object beneath). Is there a way to show the
opaque object over the transparent object.?

-Aditya

Re: [Openrm-users] 1.8.0-alpha update

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

Hi Wes;

I will make the patch for 1.8-X-alpha and resend it to you.

-Aditya

On Fri, Jun 12, 2009 at 4:26 PM, Wes Bethel <ewb...@r3...> wrote:

> R. Aditya Kadambi wrote:
> > Hi Wes;
> >
> > Looks like addChildTest.c is missing in the demo programs. I just
> > compiled the demo programs without that file. All the demos work fine.
>
> Hi,
>
> Sorry about that.
>
> As for the FreeBSD patches, yes, let's include them. Were the patches to
> 1.6.X or to the 1.8.X-alpha version? Simplest thing would probably be
> for you to resend them to me.
>
> Apologies to everyone for the general neglect. Too many demands
> competing for too little attention is the general culprit. One of my
> to-do items for the summer is to flush out accrued patches and as many
> reported bugs as possible and get the 1.8.0 release out the door.
>
> tx,
> wes
>
>
>

Re: [Openrm-users] 1.8.0-alpha update

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

R. Aditya Kadambi wrote:
> Hi Wes;
> 
> Looks like addChildTest.c is missing in the demo programs. I just
> compiled the demo programs without that file. All the demos work fine.

Hi,

Sorry about that.

As for the FreeBSD patches, yes, let's include them. Were the patches to
1.6.X or to the 1.8.X-alpha version? Simplest thing would probably be
for you to resend them to me.

Apologies to everyone for the general neglect. Too many demands
competing for too little attention is the general culprit. One of my
to-do items for the summer is to flush out accrued patches and as many
reported bugs as possible and get the 1.8.0 release out the door.

tx,
wes

Re: [Openrm-users] 1.8.0-alpha update

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

Hi Wes;

Looks like addChildTest.c is missing in the demo programs. I just compiled
the demo programs without that file. All the demos work fine.

------------------------------------------------
make: *** No rule to make target `addChildTest.c', needed by
`addChildTest'.  Stop.
-------------------------------------------------

I had sent out a patch to add target for FreeBSD X86_64. Would it be
possible to add it to RM?


OK, details of the system on which I tested.

My test system is Fedora 11 with Mesa 7.5-devel.
Hardware: ATI X1950Pro


Information from OpenRM glxinfo

OpenRM Scene Graph (v1.8.0-alpha-01),
Copyright (C) 1999-2008, R3vis Corporation.

OpenGL Details:
   vendor:     DRI R300 Project
   version:    1.4 Mesa 7.5-devel
   renderer:   Mesa DRI R300 20090101  TCL DRI2
   extensions: GL_ARB_depth_texture
               GL_ARB_draw_buffers
               GL_ARB_fragment_program
               GL_ARB_imaging
               GL_ARB_multisample
               GL_ARB_multitexture
               GL_ARB_point_parameters
               GL_ARB_shadow
               GL_ARB_shadow_ambient
               GL_ARB_texture_border_clamp
               GL_ARB_texture_compression
               GL_ARB_texture_cube_map
               GL_ARB_texture_env_add
               GL_ARB_texture_env_combine
               GL_ARB_texture_env_crossbar
               GL_ARB_texture_env_dot3
               GL_MESAX_texture_float
               GL_ARB_texture_mirrored_repeat
               GL_ARB_texture_rectangle
               GL_ARB_transpose_matrix
               GL_ARB_vertex_buffer_object
               GL_ARB_vertex_program
               GL_ARB_window_pos
               GL_EXT_abgr
               GL_EXT_bgra
               GL_EXT_blend_color
               GL_EXT_blend_equation_separate
               GL_EXT_blend_func_separate
               GL_EXT_blend_logic_op
               GL_EXT_blend_minmax
               GL_EXT_blend_subtract
               GL_EXT_compiled_vertex_array
               GL_EXT_convolution
               GL_EXT_copy_texture
               GL_EXT_draw_range_elements
               GL_EXT_framebuffer_object
               GL_EXT_fog_coord
               GL_EXT_gpu_program_parameters
               GL_EXT_histogram
               GL_EXT_multi_draw_arrays
               GL_EXT_packed_depth_stencil
               GL_EXT_packed_pixels
               GL_EXT_point_parameters
               GL_EXT_polygon_offset
               GL_EXT_rescale_normal
               GL_EXT_secondary_color
               GL_EXT_separate_specular_color
               GL_EXT_shadow_funcs
               GL_EXT_stencil_two_side
               GL_EXT_stencil_wrap
               GL_EXT_subtexture
               GL_EXT_texture
               GL_EXT_texture3D
               GL_EXT_texture_compression_s3tc
               GL_EXT_texture_edge_clamp
               GL_EXT_texture_env_add
               GL_EXT_texture_env_combine
               GL_EXT_texture_env_dot3
               GL_EXT_texture_filter_anisotropic
               GL_EXT_texture_lod_bias
               GL_EXT_texture_mirror_clamp
               GL_EXT_texture_object
               GL_EXT_texture_rectangle
               GL_EXT_vertex_array
               GL_APPLE_packed_pixels
               GL_ATI_blend_equation_separate
               GL_ATI_texture_env_combine3
               GL_ATI_texture_mirror_once
               GL_ATI_separate_stencil
               GL_IBM_multimode_draw_arrays
               GL_IBM_rasterpos_clip
               GL_IBM_texture_mirrored_repeat
               GL_INGR_blend_func_separate
               GL_MESA_pack_invert
               GL_MESA_ycbcr_texture
               GL_MESA_window_pos
               GL_NV_blend_square
               GL_NV_light_max_exponent
               GL_NV_texture_rectangle
               GL_NV_texgen_reflection
               GL_NV_vertex_program
               GL_OES_read_format
               GL_SGI_color_matrix
               GL_SGI_color_table
               GL_SGIS_generate_mipmap
               GL_SGIS_texture_border_clamp
               GL_SGIS_texture_edge_clamp
               GL_SGIS_texture_lod
               GL_SUN_multi_draw_arrays

GLU Details:
   version:    1.3
   extensions: GLU_EXT_nurbs_tessellator
               GLU_EXT_object_space_tess

GLX Server Details:
   vendor:     SGI
   version:    1.2
   extensions: GLX_ARB_multisample
               GLX_EXT_import_context
               GLX_EXT_texture_from_pixmap
               GLX_EXT_visual_info
               GLX_EXT_visual_rating
               GLX_MESA_copy_sub_buffer
               GLX_OML_swap_method
               GLX_SGI_swap_control
               GLX_SGIS_multisample
               GLX_SGIX_fbconfig
               GLX_SGIX_visual_select_group

GLX Client Details:
   vendor:     SGI
   version:    1.4
   extensions: GLX_ARB_get_proc_address
               GLX_ARB_multisample
               GLX_EXT_import_context
               GLX_EXT_visual_info
               GLX_EXT_visual_rating
               GLX_MESA_allocate_memory
               GLX_MESA_copy_sub_buffer
               GLX_MESA_swap_control
               GLX_MESA_swap_frame_usage
               GLX_OML_swap_method
               GLX_OML_sync_control
               GLX_SGI_make_current_read
               GLX_SGI_swap_control
               GLX_SGI_video_sync
               GLX_SGIS_multisample
               GLX_SGIX_fbconfig
               GLX_SGIX_pbuffer
               GLX_SGIX_visual_select_group
               GLX_EXT_texture_from_pixmap

--------------------------------------------------------------------------------------

On Tue, Nov 25, 2008 at 10:35 AM, Wes Bethel <ewb...@r3...> wrote:

>
> I made a boo-boo with openrm-devel-src-1.8.0-alpha.tgz: a compile error
> somehow escaped and was present in the 01 tarball. Sorry about that.
>
> Here is a v2 tarball:
> http://www.openrm.org/downloads/openrm-devel-src-1.8.0-alpha-02.tgz
>
> While we're still in alpha, downloads for all OpenRM bits will be linked
> from http://www.openrm.org/download.shtml
>
> tx,
> wes
>
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Openrm-users mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/openrm-users
>