Hello all,

I am developing an application which involves a virtual environment. I want to
have a (set of) virtual camera(s) and objects in a scene, and all of these are
going to be changed semi-interactively (doesn't have to be real-time.) I like
to use povray to achieve this. Let me ask my question with a pseudo-code. I
like to have a coding structure that looks like this:

****** Code Starts ******
#include "povray_api.h"

int main_loop(void) {
  povray_scene scene;
  cam_id1 = scene.camera_add( my_cam_params_1 );
  cam_id2 = scene.camera_add( my_cam_params_2 );

  scene.add_box( ...parameters... );
  // we add all the objects and light sources here
  // ...

  while (loop_flag) {
    scene.render(cam_id1, &image1);
    scene.render(cam_id2, &image2);

    // send the images to wherever...

    // modify the scene (change object and camera positions, etc...)

  }

}
****** Code Ends ******

I want this because the overhead of creating a pov file (scene file), calling
the "povray" executable then parsing it for every frame is significant. My
scene is simple and does not change a lot. On top of above reasons, in
principle, reprocessing a scene should be faster as well.

Would this be easily possible with povray libs? Any pointers will be
appreciated.

Cheers!

Post a reply to this message

AIV Developer wrote:
> Would this be easily possible with povray libs? Any pointers will be
> appreciated.

POV-Ray is not a library. What you want to do cannot be done with any 
existing POV-Ray.

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> AIV Developer wrote:
> > Would this be easily possible with povray libs? Any pointers will be
> > appreciated.
>
> POV-Ray is not a library. What you want to do cannot be done with any
> existing POV-Ray.
>
>  Thorsten

Hi Thorsten,

Thank you for the reply.

I am aware that it is not "just a library", but it appears to have several
nicely separated layers of libraries, like libbase, libbackend, etc. I was
thinking that those might be used with a simple(r) frontend written by
the users.

Anyway. In the mean time, I had more time to look into the code base
of povray. Version 3.7 seems to be too complicated to be used for my
purpose. So, I went back to the beginning. And, I found version 1.0. It
appears to include all the properties I needed (but, slightly slower) And,
its code is significantly "easy." I could manage to write my own frontend
API which provides exactly what wanted. That was a quick solution for
the project. If/when I need more advanced ray-tracing features of later
versions, I may spent more time to understand the structure of the new
code.

Cheers,
TA

Post a reply to this message

AIV Developer wrote:
> Thorsten Froehlich <tho### [at] trfde> wrote:
>> AIV Developer wrote:
>>> Would this be easily possible with povray libs? Any pointers will be
>>> appreciated.
>> POV-Ray is not a library. What you want to do cannot be done with any
>> existing POV-Ray.
>>
>>  Thorsten
> 
> Hi Thorsten,
> 
> Thank you for the reply.
> 
> I am aware that it is not "just a library", but it appears to have several
> nicely separated layers of libraries, like libbase, libbackend, etc. I was
> thinking that those might be used with a simple(r) frontend written by
> the users.

These are not libraries, they have that odd name because someone is 
compiling the individual parts as libraries and then links them together. 
They are neither libraries nor are they meant to be. It is just an artifact 
of how they are built. I guess you are looking at the Linux version as these 
names do not exist on either the Windows or Mac versions of POV-Ray. I 
realize this might be confusing, but it is the way it is ... I will see if 
it can be changed.

	Thorsten, POV-Team

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:

> These are not libraries, they have that odd name because someone is
> compiling the individual parts as libraries and then links them together.
> They are neither libraries nor are they meant to be. It is just an artifact
> of how they are built. I guess you are looking at the Linux version as these
> names do not exist on either the Windows or Mac versions of POV-Ray. I
> realize this might be confusing, but it is the way it is ... I will see if
> it can be changed.
>
>  Thorsten, POV-Team

Hi,

I think the naming is not that bad. One separates the code according to
their functions and create sub collections of routines, as is done for this
code base. It makes them more manageable. Then, naturally you call
them as lib<function>.a; library (literally!) of this and that "function."

I don't think anybody assumes that they are "independent" libraries;
I didn't (that's why I asked if that kind of use would be possible!)So, if I
may, I suggest you to keep it that way, which makes sense as software
engineering point of view.

Another suggestion (as I go over the code); it would be nice if well
separated layers (call it 'library' or whatever) use simple and clean APIs.
This becomes very important as the code gets complicated. Otherwise,
even the writer of the code will have difficulty in maintaining the code,
causing valuable man power.

Cheers,
TA

Post a reply to this message

> I am developing an application which involves a virtual environment. [...]

In case you also want to distribute that application, you should check
POV-Ray's licence. It is considered non-free by current standards (like
Debian's) and IIRC, the reason had something to do with distribution of
modified versions. Which is what your approach would be: Bisecting the
parser away and tying your application to POV-Ray by directly using the
internal interface.

This is one of the reasons I am waiting for Version 4.0.

Best regards,

  Mark Weyer

Post a reply to this message

> I am developing an application which involves a virtual environment. I want to
> have a (set of) virtual camera(s) and objects in a scene, and all of these are
> going to be changed semi-interactively (doesn't have to be real-time.) I like
> to use povray to achieve this. [...]
>
> I want this because the overhead of creating a pov file (scene file), calling
> the "povray" executable then parsing it for every frame is significant. My
> scene is simple and does not change a lot. [...]

A very partial solution: Instead of one call per camera and timepoint you can
do with one call per timepoint as follows:
Combine all cameras that you need into a single one. In principle this means
aligning the individual views into one somewhat larger view. This can be done
with user-defined cameras, as supported AIUI by MegaPov. After the MegaPov
call you would cut the output image into the pieces you actually need. Be
sure not to use jittering antialiasing, though.

In case your virtual environment allows this, maybe you can even replace the
user-defined camera by a standard camera plus a system of mirrors or such.
This would allow to use plain POVray, but it will not work for arbitrary
scenes.

Best regards,

  Mark Weyer

Post a reply to this message

Hi Mark,

I don't have any licensing issue; I don't plan to distribute the code.

Using a set of mirrors and a single camera is a great idea, because
two cameras I need are going to be simulated eyes which are at a close
distance to each other, and moves together. I'll test and compare the
render speed. Off course I don't expect two-fold gain, but any gain
is appreciable for me. As for AIUI, I'll look into that.

Thank you for the advice,
Kind regards,
TA


"Mark Weyer" <nomail@nomail> wrote:
> > I am developing an application which involves a virtual environment. I want to
> > have a (set of) virtual camera(s) and objects in a scene, and all of these are
> > going to be changed semi-interactively (doesn't have to be real-time.) I like
> > to use povray to achieve this. [...]
> >
> > I want this because the overhead of creating a pov file (scene file), calling
> > the "povray" executable then parsing it for every frame is significant. My
> > scene is simple and does not change a lot. [...]
>
> A very partial solution: Instead of one call per camera and timepoint you can
> do with one call per timepoint as follows:
> Combine all cameras that you need into a single one. In principle this means
> aligning the individual views into one somewhat larger view. This can be done
> with user-defined cameras, as supported AIUI by MegaPov. After the MegaPov
> call you would cut the output image into the pieces you actually need. Be
> sure not to use jittering antialiasing, though.
>
> In case your virtual environment allows this, maybe you can even replace the
> user-defined camera by a standard camera plus a system of mirrors or such.
> This would allow to use plain POVray, but it will not work for arbitrary
> scenes.
>
> Best regards,
>
>   Mark Weyer

Post a reply to this message

Mark Weyer wrote:
>  Which is what your approach would be: Bisecting the
> parser away and tying your application to POV-Ray by directly using the
> internal interface.

I don't think that's allowed by the modification license either. A modified
POV-Ray has to be fully-functional, and work with the same scenes as the
official version does, as far as I know/understand.

Post a reply to this message