Hi,

Thank you very much for the web page, it looks like a very interesting research
project.

> POV-Ray is totally appropriate to show what I'm doing, because it can
> represent the eight parameters I'm obtaining from the camera movement.

Sure, Pov-ray can do that perfectly. What I meant was another rendering engine
could also do it as well, while avoiding the problem you face with Pov-ray. For
example a graphic library integrated to what you're using to launch the Pov-ray
instances would avoid creating those 2000 external processes to run Pov-ray. In
a previous comment you were writing "pac%04d.png", maybe you're using the C
programming language to generate the Pov-ray scripts and launch there rendering?
In that case, using a graphic library like, for example, OpenGL to render images
directly in the C program instead of using Pov-ray would allow you to get the
same result while avoiding the problem encountered with Pov-ray.

But, I still do not understand completely your constraints and I shall no go
further with hypothesis.

Anyway, bonne chance in your research ! :-)



Francois LE COAT <lec### [at] atariorg> wrote:
> Hi,
>
> To explain what I'm doing I've done a WEB page that is not yet finished:
>
> <https://hebergement.universite-paris-saclay.fr/lecoat/demoweb/temporal_d
> isparity.html>
>
> POV-Ray is totally appropriate to show what I'm doing, because it can
> represent the eight parameters I'm obtaining from the camera movement.
>
> I obtain the eight:
>
> - Tx horizontal translation
> - Ty vertical translation
> - Tz depth translation
> - Rx pitch angle
> - Ry yaw angle
> - Rz roll angle
> - Sx horizontal shear angle
> - Sy vertical shear angle
>
> and POV-Ray can represent those all. This already have been discussed in
> <news://povray.advanced-users> because I'm modelling the 3D motion.
>
> The issue here, is just to make POV-Ray quiet when I'm rendering...
>
> BayashiPascal writes:
> > Trying to guess what you're doing. The execution of the 2000 renderings
>  is
> > automated in some way but you're getting your data used to create the r
> endering
> > script in real time, one image after the other, waiting new data to ren
> der the
> > next image, thus don't know in advance the new parameters. Am I right ?
>
> >
> > If that's the case, and if the rendering could be delayed, you could wa
> it until
> > you acquired the whole data for the 2000 images and implement a solutio
> n as
> > we've suggested in previous posts to render images at the end of acquis
> ition.
> > But may be you need to render the image as soon as its data are acquire
> d and use
> > the rendered image to acquire the next data ?
> >
> > Your video really sparks my curiosity. I'm also working on project usin
> g
> > Pov-ray, real world data and depth images. Would you mind telling us a
> little
> > more about what you're doing ? Looks like some kind of 3D reconstructio
> n from
> > data acquired by a drone ?
> >
> > I also understand that finding a solution, which I have no idea of, to
> the
> > finder problem may be more practical to your use case, but, as jr, I st
> ill
> > believe there may be a work around. The image you render looks simple,
> and given
> > the real time constraints (either during acquisition, rendering process
>  or
> > rendered image post processing) you seem to have, maybe Pov-ray is simp
> ly not
> > the appropriate tool to your use case ?
> >
> > Hoping to be helpful,
> > Pascal
> >
> > Francois LE COAT wrote:
> >> jr writes:
> >>> Francois LE COAT wrote:
> >>>> ...
> >>>> The rendering of POV-Ray synthesis images are done in "real-time". I
> t
> >>>> depends on past data, and future parameters are unknown. I have a
> >>>> POV-Ray script from which I substitute series of float numbers, that
>
> >>>> produces 2000 different scenes, one after the other.
> >>>>
> >>>> I can't launch POV-Ray one time, to produce 2000 images. I must laun
> ch
> >>
> >>>> it 2000 times, to render 2000 images. ...
> >>>> The question is how to configure POV-Ray with the command-line, so t
> ha
> >> t
> >>>> it is quiet ? ...
> >>>
> >>> looking at the ini you posted earlier, am I correct in assuming that
> th
> >> e
> >>> generating "POV-Ray script" produces 2000 scene files named 'pacman_m
> od
> >> .pov'?
> >>
> >> Well, I have a model "pacman.pov" from which I generate "pacman_mod.po
> v"
> >> substituting the parameters at n step. Then I render this script,
> >> producing "pacman.png". And I move "pacman.png" to "pac%04d.png" with
> n.
> >>
> >>> also, since I cannot believe that you'd invoke a(ny) program 2000 tim
> es
> >>
> >>> manually, the script must somehow tell 2nd from 23rd run.  do you run
>  t
> >> he whole
> >>> thing lot from within another script?  (o/wise how do you prevent ove
> rw
> >> riting
> >>> 'pacman.png'?)
> >>
> >> It results 2000 files, from "pac0001.png" to "pac2000.png" with 2000
> >> steps. I have launched POV-Ray 2000 times, knowing parameters from
> >> 1 to n steps. Each step n I have new parameters, but I don't know n+1.
>
> >>
> >>> are you free to modify said POV-Ray script?  then, for instance, you
> co
> >> uld
> >>> change it to generate an array and include that from your scene, usin
> g
> >>> frame_number as index; though there'd likely be other, more efficient
>  w
> >> ays.  (I
> >>> also assume that the newly calculated data only depends on previous)
> >>
> >> I can't generate an array of parameters, because I know those partiall
> y.
> >> I'm drawing a trajectory, steps to steps, and I can't predict future.
> >>
> >>> anyway, I'm fairly certain that the "problem" can be addressed w/out
> re
> >> sorting
> >>> to compiling a new program.  :-)
> >>
> >> It's the simplest solution. If there's no command-line option to make
> >> POV-Ray quiet, I can build a macOS/Macports version, that will be quie
> t.
>
> Thanks for your help.
>
> Regards,
>
> --

> <http://eureka.atari.org/>

Post a reply to this message