possible tsm display driver bug?

  • bill nieuwendorp

    using the tsm display driver in a shadowmap rib file

    Procedural "DelayedReadArchive" ["Cube.dat.rib"] [-1e+38 1e+38 -1e+38 1e+38 -1e+38 1e+38]
    works fine

    Procedural "RunProgram" ["myprogram" "args"] [-1e+38 1e+38 -1e+38 1e+38 -1e+38 1e+38]
    creates a corrupt tsm file

    this is the out put of the runprogram and the DelayedReadArchive

    version 3.03
    MotionBegin [0.01 5.0]
    SubdivisionMesh "catmull-clark" [4 4 4 4 4 4] [0 1 2 3 4 7 6 5 0 4 5 1 1 5 6 2 2 6 7 3 4 0 3 7] ["interpolateboundary"] [0 0] [0] [0.0]  "P" [-0.30516704917 0.141693651676 2.93547558784 -0.307167410851 0.0261980053037 0.938814580441 -1.76711881161 -1.33838176727 1.01921069622 -1.7651181221 -1.22288572788 3.01587200165 1.06177771091 -1.3159006834 3.01841950417 1.05977654457 -1.43139708042 1.02175807953 -0.400174468756 -2.79597640038 1.10215508938 -0.398173838854 -2.68048048019 3.09881591797]
    SubdivisionMesh "catmull-clark" [4 4 4 4 4 4] [0 1 2 3 4 7 6 5 0 4 5 1 1 5 6 2 2 6 7 3 4 0 3 7] ["interpolateboundary"] [0 0] [0] [0.0]  "P" [1.84086465836 0.141693651676 2.93547558784 1.83886420727 0.0261980053037 0.938814580441 0.378912866116 -1.33838176727 1.01921069622 0.380913585424 -1.22288572788 3.01587200165 3.20780944824 -1.3159006834 3.01841950417 3.20580816269 -1.43139708042 1.02175807953 1.74585723877 -2.79597640038 1.10215508938 1.74785780907 -2.68048048019 3.09881591797]
    # ÿ

    should also be noted that the the runprogram works fine with regular rendering just not in a tsm shadowmap

    • Okan Arikan

      Okan Arikan - 2007-03-17

         Hi Bill,

         This is annoying. I suspect it's an OS problem in executing the program. Can you tell me what OS you're using?

         Having all the resources (ribs+shaders+programs) and step by step instructions really help me re-create the issue (if possible).



      • bill nieuwendorp

        sorry Okan, that was kind of a cryptic bug report.

        my machine is Ubuntu linux

        I am trying to get it down to the most simplistic case for you to debug.

        cat could replace the runprogram in this case


        should display the problem I am seeing.

        probably have to replace cat with cat.exe if your using
        cat for windows

        • bill nieuwendorp

          the tar.gz file I uploaded seems to be corrupted
          this one should work


          • George Harker

            George Harker - 2007-03-18

            Hi Bill,

            I can't get this to crash for me on OSX.  I'll try under fedora when I'm infront of a linux box.

            It probably relates to the way that RunProgram procedurals are supposed to run:

            A procedural is supposed to read in a loop lines which look like

            123232.102 ["arguments here"]

            The first number is the detail, the second contains the arguments to the dso.

            At the end of each output, either RiEnd should be called, or you should output the character '\377' to stdout and fflush stdout.

            For example, this C program:

            #include <stdio.h>
            #include <unistd.h>
            #include <stdlib.h>
            #include <math.h>
            #include <ri.h>

            int main(int argc, char *argv[]){
                char buf[1024];
                    if (! fgets(buf,1024,stdin)) break;

                    float detail;
                    char fn[1024];
                    sscanf(buf,"%f [%s]",&detail,fn);
                    int i=0;
                    while(fn[i] != '\0') {
                        if(fn[i] == ']') fn[i] = 0;
                    FILE *fin = fopen(fn,"r");
                    if(fin != NULL) {
                        while(!feof(fin)) {
                    } else
                        fprintf(stderr,"Can't open file to cat \&quot;%s\&quot;\n",fn);

                    fprintf(stderr,"Quitting this riblet\n");
                fprintf(stderr,"really Quitting\n");
                return 0;

            This should perform the catrib functionality you had in your example.  Incindentally, DelayedReadArchive will be more efficient than this. 

            I think that possibly because the subprocess isn't reading from stdin, it may quit out before Pixie has finished writing to it, which might be causing the issues.

            The API we have matches PRMan but is (in my opinion) a little over complex.  It'd be nice to be able to support simple commandline apps like cat.  Perhaps we should add a custom option to do this.



            • bill nieuwendorp

              Hello George
              thanks for having a look. the actual runprogram I am using is writen in python and reads a from a 2 different binary

              files to produce the geometry one is a pointcache type file which stores all the deformed points per frame, the other is

              a binary python pickle that stores the the type and tag info for the geometry. I was trying to make a simpler case to debug by

              using cat instead since it produces the same problem here.

              After reading your response I think I have over looked that the program should be reading from stdin.

              not sure if this python program will work on anyone else's machine(needs cgkit and possibly python version 2.5).

              but for the sake of providing a complete example I have attached the files here


              one more observation if I set the PixelSamples down to 1 instead of 4 in the Spot04.rib it will complete the tsm file

              thanks again for looking

              looks like I may need to rethink the way my python script works to get this working correctly


    • bill nieuwendorp

      Ok found another example that I assume should work, but does not.


      there is a good python example there under

      3. CSG and Animation, Procedural RunProgram examples

      I assume this works in Prman?

      • George Harker

        George Harker - 2007-03-19

        I've managed to recreate the bug (happens on RHEL 3 too).

        I have a potential fix for it, but I'm just trying to understand why it's needed.

        fflush(CRenderer::deepShadowFile); can be addeed to ri.cpp:1883 (just before the fork() call inside the if()). 

        Rather wierd that it should be needed so I'd liek to understand it a bit better



      • George Harker

        George Harker - 2007-03-19

        There's a fix checked in now which will have this work.

        I need to tidy up a couple of thing that relate to how we startup subprocesses - but it should work unconditionally now.



    • bill nieuwendorp

      Thanks George and Okan for fixing this up.

      I have modified my program to run in a while loop and read the detail

      from stdin all working fine now with your fixes in cvs.

      I have one more maybe off topic question. I was trying to compile George's C example above


      g++ -I$PIXIEHOME/include catme.c -o catme

      and I get errors like

      catme.c:(.text+0x30): undefined reference to `RiBegin'

      one for every Ri call in the c file.

      so I guess I am asking how to compile the above file.

      I have tried other examples that have worked with pixie but only if they circumvent

      ri.h by using printf.

      • George Harker

        George Harker - 2007-03-22

        Hi Bill,

        You need to link against libri, which implements all the ri calls.

        g++ -I$PIXIEHOME/include catme.c -o catme -L${PIXIEHOME}/lib -lri

        should do the job.




Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks