RenderMan & RISpec >> Nesting context rules ?

by Rich » Thu, 16 Oct 2003 16:47:18 GMT

Im trying to make my RenderMan implementation strict, such that if you
attempt to begin/end or nest elements at invalid locations it throws an
error.

As a result I have a problem. The V3.2 spec (pages 18/19) suggest that any
Ri*Begin/Ri*End construct can be nested... but I thought that

* RiFrame* can only appear at the top level (if at all), and thus cant be
nested. (implicitly inside a RiBegin/RiEnd block)

* RiWorld* can only appear once within a RiFrame block or once within a RIB
stream. Thus it can only appear in a single frame block or the implied
generic frame.

* All other Ri*Begin/End blocks can appear anywhere any number of times as
long as they dont overlap, and this is what pages 18/29 refer to.

Assuming Ive got the right end of the stick with the above statements, am I
missing a part of the document which states this MUST be so? I could do with
knowing if this is optional (but recommended) or mandatory.

Many thanks

Rich



RenderMan & RISpec >> Nesting context rules ?

by Andreas Pidde » Thu, 16 Oct 2003 21:04:21 GMT



Hi Rich,

AFAIK your are right on the whole
o Yes, Frames only within RiBegin/End Level.
o World blocks cannot contain other world blocks, but Frames can contain
more than one world block (e.g. for shadow maps)
o Not all, e.g. solid blocks make only sense in world or object blocks.
And "primitive" blocks cannot contain any other solid blocks (see Solid
and Spatial Set Operations in V3.2 spec. itself)

In the Companion there is a helpful matrix of which blocks can be nested
in each other and which interface calls are valid in there, haven't
found such at V3.2. There's a bit more possible in modern
implementations, see also sig99.course.25.pdf (link is in the RenderMan
Repository), New RenderMan Interface features, esp. objects and check
against V3.2. However, it's a good idea to implement a matrix for
checking: Interface call (or block) A can occur in block B, so you can
change things quickly.

Hope this helps,
Andreas

Similar Threads

1. Inline Rules or Paragraph Rules in Corel Draw

2. nesting FX states

I'm reading a presentation from GDC 2004 on using effect files.  It suggests
to nest fx files so that common states can be moved out of inner loops.

So what I have done, in addition to my other fx files, I have one global fx
file, which stores seldomly changed states and global parameters.  However,
when I change a state it does not get updated:

globalFX->SetInt(hCullMode, cull);
globalFX->CommitChanges();

DrawStuff();

This is, of course, enclosed in a Begin, BeginPass, ..., EndPass, End block,
where hCullMode is a handle to the fx parameter gCullMode, which sets the
cullmode render state in pass 0:
extern uniform DWORD gCullMode;

technique GlobalFXTech
{
pass P0
{
// States
CullMode = <gCullMode>;
[...]

However, CommitChanges is not updating the render state!  On the other hand,
if I modify the state directly, it does work:


gDevice->SetRenderState(D3DRS_CULLMODE, D3DCULL_NONE);

DrawStuff();

So why isn't CommitChanges working!?


3. nested transformations?

5. [Q] Polygon hierarchy, consistant orientation, nesting, sweepline algo.

6. nested if statements

Hi,

is it possible to nest if statements in gnuplot?

the help seems to cover only

 if <> else if <> else

what I need is a fuller

 if <> if <> else <> else <>



If there this is not supported then maybe the help could be more
explicit.

Are there any tricks to over come this , assumed, short coming?

TIA.

7. nested if then else

8. Scrambled graphics with nested buffered components at custom GUI

Hi,
I have implemented a custom GUI library with buffered components.
I used EvC 4.0 (SP4) and this library did work very well, while
compiled for a WinCE 4.2 system. After an Upgrade to WinCE 5.0,
the component's graphics get randomly scrambled and sometimes
disappear at all. I already found a quick fix (by using DIB's instead of 
DDB's),
but with the DIB's, text antialiasing doesn't work anymore, so this isn't 
really
an acceptable solution. Unfortunately the problem is a little complex, so I 
will
post the 4 related methods and their dependencies in the following (left out
as much unimportant stuff as possible).

Actually I was used to code in java, so maybe I just screwed up using
the structures in a miserable way. I really hope someone can help me out.

Thomas


Wnd::OnPaint()
{
    CPaintDC dc = CPaintDC(this);
    DrawChildren(&dc);
    ...
}

DrawChildren(CDC* dc)
{
    // initialize
    CDC memDC;
    HBITMAP offscreenBmp;
    HGDIOBJ oldObj;

    memDC.CreateCompatibleDC(dc);
    offscreenBmp = CreateCompatibleBitmap(dc->GetSafeHdc(),...);
    oldObj = memDC.SelectObject(offscreenBmp);

    // draw the children
    for(...)
    {
        curChild->DrawElement(&memDC);
    }

    // BitBlt memDC into dc
    dc->BitBlt(...,&memDC,...)

    // cleanup
    memDC.SelectObject(oldObj);
    memDC.DeleteDC();
    DeleteObject(offscreenBmp);
}

DrawElement(CDC* dc)
{
    // initialize
    CDC memDC;
    CBitmap* bmp;
    CBitmap* oldBmp;

    memDC.CreateCompatibleDC(dc);
    if (IsCached(...))
    {
        // the cached CBitmaps are stored in a map
        bmp = GetCachedBitmap(...)
    }else{
        bmp = CreateCachedBitmap()
        if(HasChildren(...)
        {
            // recursive call of above function
            DrawChildren(&memDC);
        }else{
            // simply paint the component into the memDC
            FinallyDrawElement(&memDC);
        }
    }
    oldBmp = memDC.SelectObject(bmp);

    // BitBlt nested DC into parent DC
    dc->BitBlt(...,&memDC,...)

    // clean up
    memDC.SelectObject(oldBmp);
    memDC.DeleteDC();
}

CreateCachedBitmap()
{
    HDC hDC = ::GetDC(AfxGetMainWnd()->GetSafeHwnd());
    HBITMAP myBmp = CreateCompatibleBitmap(hDC, ...);
    // This was my quick fix: HBITMAP myBmp = CreateDIBSection(hDC,...);
    ReleaseDC(NULL, hDC);
    SetCached(true);
}