POV-Ray : Newsgroups : povray.macintosh : [Q] POV-Ray in command line : Re: [Q] POV-Ray in command line Server Time
19 May 2024 05:11:11 EDT (-0400)
  Re: [Q] POV-Ray in command line  
From: Francois LE COAT
Date: 31 Jan 2021 08:14:10
Message: <6016ad22$1@news.povray.org>

I had a talk with Bald Eagle, that is present in this newsgroup, about
the transformations of POV-Ray, in order to render all the eight
parameters I'm obtaining. I could also use OpenGL, because it may be
more appropriate for "real-time". But POV-Ray is more realistic, and
will be more and more convenient for "real-time" photographic rendering.

The WEB page that I mentioned will be modified, because it doesn't
represent all what I wanted to explain about what I'm doing.

All this is written in C/C++ using POV-Ray and OpenCV, but I also use
shell scripts, mainly `tcsh`. And I use extensively the macOS Macports
environment, that allows to use `xv`, ImageMagick, `ffmpeg` etc. And
of course POV-Ray and OpenCV library, regularly updated.

All of this would be totally impossible to develop without the Unix
environment, simply. It also works under GNU/Linux, with the same tools.

BayashiPascal writes:
> Francois LE COAT wrote:
> Thank you very much for the web page, it looks like a very interesting 
> 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
> 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
> 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 t
he C
> programming language to generate the Pov-ray scripts and launch there r
> In that case, using a graphic library like, for example, OpenGL to rend
er images
> directly in the C program instead of using Pov-ray would allow you to g
et 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 wrote:
>> To explain what I'm doing I've done a WEB page that is not yet finishe
>> <https://hebergement.universite-paris-saclay.fr/lecoat/demoweb/tempora
>> 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 
>> <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 renderin
gs is
>>> automated in some way but you're getting your data used to create the
>>> script in real time, one image after the other, waiting new data to r
ender 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 
wait until
>>> you acquired the whole data for the 2000 images and implement a solut
ion as
>>> we've suggested in previous posts to render images at the end of acqu
>>> But may be you need to render the image as soon as its data are acqui
red and use
>>> the rendered image to acquire the next data ?
>>> Your video really sparks my curiosity. I'm also working on project us
>>> 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 reconstruct
ion from
>>> data acquired by a drone ?
>>> I also understand that finding a solution, which I have no idea of, t
o the
>>> finder problem may be more practical to your use case, but, as jr, I 
>>> believe there may be a work around. The image you render looks simple
, and given
>>> the real time constraints (either during acquisition, rendering proce
ss or
>>> rendered image post processing) you seem to have, maybe Pov-ray is si
mply not
>>> the appropriate tool to your use case ?
>>> Hoping to be helpful,
>>> Pascal

Thanks for your help.




Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.