|
 |
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
|
|
