 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi,
I can't use clock variable, in the case of my rendering. Here it is...
<https://www.youtube.com/watch?v=vgHOseHTGXs>
The rendered image is the yellow camera, in up-right corner. Every
2000 POV-Ray scripts are different. The 2000 POV-Ray scripts are
generated reading a data file, containing series of float numbers.
I must launch POV-Ray 2000 times, one after the other, to render 2000
different scripts. That's critical, because POV-Ray replaces the menu
bar, and add its icon to the macOS dock, 2000 times successively.
That completely blocks the usage of the Apple Finder's interface.
BayashiPascal writes:
> I don't have a solution to your finder problem but I thought a work aro
und could
> be to render your 2000 images as if it was an animation. Then you would
launch
> only one instance of Pov-ray (I think, not completely sure actually how
it works
> on Mac). Yet, I don't know if you could easily change your
> script to render the appropriate image based on the clock variable...
>
> Pascal
>
> Francois LE COAT wrote:
>> I use POV-Ray in command line under macOS Catalina and Macports,
>> and run it about 2000 times, in order to render 2000 images. My
>> issue is when you launch `povray` in command line, it opens a
>> menu bar, and displays an icon in the macOS dock ...
>>
>> Is there a command line option, that prevents POV-Ray from displaying
>> a menu bar and an icon in the dock ? Because when you launch it 2000
>> times, for 2000 images, the Apple Finder and the Macintosh become
>> unusable ... The computer keeps displaying the bar and the icon,
>> and you can't do anything else with the Macintosh. You have to wait
>> that the 2000 images are rendered ... You have to wait half an hour,
>> so that POV-Ray stops rendering.
>>
>> There must be a solution. Because you can't do anything else, before
>> POV-Ray has stopped rendering ... This is very painful ...
Thanks for your help.
Regards,
--
<http://eureka.atari.org/>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
Francois LE COAT <lec### [at] atari org> wrote:
> Hi,
>
> I can't use clock variable, in the case of my rendering. Here it is...
> ...
> The rendered image is the yellow camera, in up-right corner. Every
> 2000 POV-Ray scripts are different. The 2000 POV-Ray scripts are
> generated reading a data file, containing series of float numbers.
you don't give (m)any details about how your code is structured, so my comments
are .. a shot in the dark. :-)
if your 2000 "scripts" are simply the changing data, and you '#include' those
from a scene, then serially numbered data filenames corresponding to
'frame_number' and constructing the file name at runtime would allow you to run
a single "animation".
if you have to extract each data set one at a time, using a shell script in
conjunction with the '{pre,post}_frame_command's in the ini file might do the
trick, again, you'd only run one animation. hth.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi,
jr writes:
> Francois LE COAT wrote:
>> I can't use clock variable, in the case of my rendering. Here it is...
>> ...
>> The rendered image is the yellow camera, in up-right corner. Every
>> 2000 POV-Ray scripts are different. The 2000 POV-Ray scripts are
>> generated reading a data file, containing series of float numbers.
>
> you don't give (m)any details about how your code is structured, so my
comments
> are .. a shot in the dark. :-)
>
> if your 2000 "scripts" are simply the changing data, and you '#include'
those
> from a scene, then serially numbered data filenames corresponding to
> 'frame_number' and constructing the file name at runtime would allow yo
u to run
> a single "animation".
>
> if you have to extract each data set one at a time, using a shell scrip
t in
> conjunction with the '{pre,post}_frame_command's in the ini file might
do the
> trick, again, you'd only run one animation. hth.
>
> regards, jr.
The rendering of POV-Ray synthesis images are done in "real-time". It
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 launch
it 2000 times, to render 2000 images. The issue is that Macports
POV-Ray binary, changes the menu bar, and displays an icon in the dock.
The question is how to configure POV-Ray with the command-line, so that
it is quiet ? I think I'll have to build POV-Ray binary myself, from
Unix/Linux sources using `./configure; make; make install` it's simple !
Thanks for your help.
Regards,
--
<http://eureka.atari.org/>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
Francois LE COAT <lec### [at] atariorg> wrote:
> ...
> The rendering of POV-Ray synthesis images are done in "real-time". It
> 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 launch
> it 2000 times, to render 2000 images. ...
> The question is how to configure POV-Ray with the command-line, so that
> it is quiet ? ...
looking at the ini you posted earlier, am I correct in assuming that the
generating "POV-Ray script" produces 2000 scene files named 'pacman_mod.pov'?
also, since I cannot believe that you'd invoke a(ny) program 2000 times
manually, the script must somehow tell 2nd from 23rd run. do you run the whole
thing lot from within another script? (o/wise how do you prevent overwriting
'pacman.png'?)
are you free to modify said POV-Ray script? then, for instance, you could
change it to generate an array and include that from your scene, using
frame_number as index; though there'd likely be other, more efficient ways. (I
also assume that the newly calculated data only depends on previous)
anyway, I'm fairly certain that the "problem" can be addressed w/out resorting
to compiling a new program. :-)
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi,
jr writes:
> Francois LE COAT wrote:
>> ...
>> The rendering of POV-Ray synthesis images are done in "real-time". It
>> 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 launch
>> it 2000 times, to render 2000 images. ...
>> The question is how to configure POV-Ray with the command-line, so tha
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_mod
.pov'?
Well, I have a model "pacman.pov" from which I generate "pacman_mod.pov"
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 times
> 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 overw
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, using
> 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 partially.
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 quiet.
Thanks for your help.
Regards,
--
<http://eureka.atari.org/>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi,
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 rendering
script in real time, one image after the other, waiting new data to render 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 solution as
we've suggested in previous posts to render images at the end of acquisition.
But may be you need to render the image as soon as its data are acquired and use
the rendered image to acquire the next data ?
Your video really sparks my curiosity. I'm also working on project using
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 reconstruction 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 still
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 simply not
the appropriate tool to your use case ?
Hoping to be helpful,
Pascal
Francois LE COAT <lec### [at] atariorg> wrote:
> Hi,
>
> jr writes:
> > Francois LE COAT wrote:
> >> ...
> >> The rendering of POV-Ray synthesis images are done in "real-time". It
> >> 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 launch
>
> >> it 2000 times, to render 2000 images. ...
> >> The question is how to configure POV-Ray with the command-line, so tha
> 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_mod
> .pov'?
>
> Well, I have a model "pacman.pov" from which I generate "pacman_mod.pov"
> 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 times
>
> > 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 overw
> 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, using
> > 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 partially.
> 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 quiet.
>
> Thanks for your help.
>
> Regards,
>
> --
> <http://eureka.atari.org/>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
Francois LE COAT <lec### [at] atariorg> wrote:
> ...
> >> ...
> >> The rendering of POV-Ray synthesis images are done in "real-time". It
> >> 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.
> >> ...
> Well, I have a model "pacman.pov" from which I generate "pacman_mod.pov"
> 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.
> ...
I found the web page helpful, in the video I find it difficult to reconcile
movement of the indicator/pacman with the changes in orientation wrt the images
on the left (cf ~0:25, ~1:14). concluding thought(s). in reply to
BayashiPascal you write "The issue here, is just to make POV-Ray quiet when I'm
rendering." with respect, disagree. the issue I think, even not knowing the
particulars, is work-flow[*], is to work with POV-Ray, and its animation
provisions, rather than launching thousands of instances. hope you will find a
satisfactory solution.
regards, jr.
[*] in my head/naively I'd collect the sets of eight values in a text file (CSV
style), have a few lines of 'awk' or such to convert that to an .inc file with
an array, then run an "animation" where the scene simply displays the current
video frame and the indicator gets rendered "on top".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi,
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
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 t
he C
> programming language to generate the Pov-ray scripts and launch there r
endering?
> 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
d:
>>
>> <https://hebergement.universite-paris-saclay.fr/lecoat/demoweb/tempora
l_disparity.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 renderin
gs is
>>> automated in some way but you're getting your data used to create the
rendering
>>> 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
isition.
>>> 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
ing
>>> 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
still
>>> 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.
Regards,
--
<http://eureka.atari.org/>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
