Re: [cgkit-user] running it non-interactively

[Matthias B. <mat...@gm...>]

will wrote:
> The helloworld sphere works find in the viewer; a simple "render.py
> hello.py" crashes with a segment fault.

Can you post the stack trace of that one? What is hello.py? Is this the
demo1.py script from the web site or the source archive?

You may have encountered the same issue that some other people have
noticed before. It only seems to happen on Ubuntu systems, I have never
been able to reproduce these segfaults on Fedora systems, OSX or Windows
(so I couldn't really investigate it).

> I want to run the snowflake in the example.  I have both Aqsis and
> Pixie installed, and after trial and error I found these library
> paths to work:
> 
> cgkit.cri.loadRI("/usr/lib/libaqsis_ri2rib.so") 
> cgkit.cri.loadRI("/usr/local/Pixie/lib/libri.so")
> 
> the first, aqsis, when run with viewer.py says:

The snowflake example uses the RenderMan interface directly which means
you run your script directly and not via the viewer or render tool.
Another thing to note, when you use Aqsis' ri2rib library, then it does
really just that, it turns the RenderMan commands into RIB requests.
This is why you saw the RIB output when you ran your script and it's
also why you saw those "Unknown procedural function" messages in the RIB
stream. The snowflake example uses the RiProcedural() call which passes
a function to the renderer that gets called by the renderer while it's
rendering the image. But when you archive a scene into a RIB stream,
then that procedural won't work because it needs the function during
rendering (from a RIB you can only use a few predefined procedurals).
So in the case of Aqsis, you shouldn't use ri2rib for that example but
the library that contains the actual renderer (I'm not sure what it's
called on Linux, probably libaqsis_core.so).

> When run directly without viewer.py, it just segfaults.  Invoking it
> with gdb shows this stack:
> 
> #0  0x00007ffff56ef7e4 in __cxa_allocate_exception () from
> /usr/lib/libstdc++.so.6 #1  0x00007ffff63044c7 in
> __getitem__(support3d::vec3<double>*, int) () from
> /usr/local/lib/python2.6/dist-packages/cgkit/_core.so #2
> 0x00007ffff630b7d8 in
> boost::python::objects::caller_py_function_impl<boost::python::detail::caller<double
> (*)(support3d::vec3<double>*, int),
> boost::python::default_call_policies, boost::mpl::vector3<double,
> support3d::vec3<double>*, int> > >::operator()(_object*, _object*) ()
>  from /usr/local/lib/python2.6/dist-packages/cgkit/_core.so #3
> 0x00007ffff5e5cc2e in
> boost::python::objects::function::call(_object*, _object*) const ()
> from /usr/lib/libboost_python-py26.so.1.40.0 #4  0x00007ffff5e5ced8
> in ?? () from /usr/lib/libboost_python-py26.so.1.40.0 #5
> 0x00007ffff5e64753 in
> boost::python::detail::exception_handler::operator()(boost::function0<void>
> const&) const () from /usr/lib/libboost_python-py26.so.1.40.0 #6
> 0x00007ffff62ecd67 in
> boost::detail::function::function_obj_invoker2<boost::_bi::bind_t<bool,
> boost::python::detail::translate_exception<support3d::ENotImplementedError,
> void (*)(support3d::ENotImplementedError const&)>,
> boost::_bi::list3<boost::arg<1>, boost::arg<2>,
> boost::_bi::value<void (*)(support3d::ENotImplementedError const&)> >
> >, bool, boost::python::detail::exception_handler const&,
> boost::function0<void>
> const&>::invoke(boost::detail::function::function_buffer&,
> boost::python::detail::exception_handler const&,
> boost::function0<void> const&) () from
> /usr/local/lib/python2.6/dist-packages/cgkit/_core.so

Hm, it crashes in __getitem__(support3d::vec3<double>*, int)() which is
in wrappers/py_vec3.cpp and simply looks like this:

double __getitem__(vec3d* self, int idx)
{
  switch(idx)
  {
  case 0: return self->x;
  case 1: return self->y;
  case 2: return self->z;
  default: throw EPyIndexError("index out of range");
  }
}

As the last call in the stack trace is "allocate exception" thing, it
looks like the above function got called with an invalid index and it
tried to throw an exception which failed for some reason. What looks
suspicious is that the earlier entries in the stack trace also mention
some exception stuff. Maybe it was already handling an exception...?
Anyway, without being able to reproduce this, I can't really investigate
the problem myself. It would be interesting to know what exactly
triggered the getitem call. The previous calls in the stack trace are
from Boost.Python. Can you try to figure out which Python call triggers
this error? Maybe you should rather use your snowflake example (assuming
this is the same problem) as that one involves less code.

> Running with the pixie lib directly just segfaults.
> 
> Running viewer.py with pixie as the lib actually renders the
> snowflake 

As mentioned above, running the snowflake with viewer.py isn't really
any useful. It just runs your RenderMan code which renders the image and
then the viewer would pop up an OpenGL window with an empty scene.
As far as the bug is concerned though, there is no difference between
running the snowflake directly or via the viewer tool. It should either
crash in both cases or run properly in both cases.
Are you sure you haven't several versions of Python on your system? Can
you please double check that you don't mix Python versions. Which Python
versions gets run when you use the viewer tool? (you can use the -v
option) Is it the same one you use when running Python directly?

> (really quite slowly; is the snowflake deceptively
> expensive or is this what I should brace myself for with all
> rendermen?) 

On a 4 year old MacBook Pro, it takes about 10 seconds using Pixie. You
can increase the subdivision threshold in the subdiv() function (the
0.005 in the if expression).

> So, what is it that I actually want to use cgkit/renderman for??
> This:
> 
> * I want to generate a world, renderer it to an (ideally in-memory)
> bitmap, do some manipulation, then rinse and repeat.  Unattended, no
> viewer needed, low quality rendering is fine. 

It depends on the details on how much work it is, but in general, it's
possible, yes. The "in-memory" bit might need a custom display driver
though.

> * I also want to know
> if shapes intersect one another (that would be illegal in my model,
> and it'd be nice if the render end can determine this for me rather
> than me needing to do complex polygon intersection logic

Well, a renderer renders an image, it's not really meant to do
computational geometry. (You might be able to "abuse" RenderMan in this
case though. The standard includes the CSG feature (=doing boolean
operations on geometry) which is implemented by Aqsis. So you could
render an intersection and check if the output contains any pixels or
not. If it does, the geometries intersect otherwise they don't. But
that's probably not the most efficient way to do this...).

Cheers,

- Matthias -