|
 |
On 6/9/21 11:46 AM, jr wrote:
> hi,
>
> William F Pokorny <ano### [at] anonymous org> wrote:
>> ...
>> Yep, rtr is cool and I hope use it (or similar) for more than demos -
>> eventually.
>> ...
>> Just need to work out how to capture each rendered frame to an image file...
>
> may be 'xwd' (and 'xwud') can help? not sure how you'd automate the syncing
> though.
>
Yeah, maybe. A long while back now, I did play a little with xwd - stand
alone just snapping a paused preview window. Hit some issue that looked
to be related to quantization or a shift of color values. I could not
quickly sort it and I dropped the work - work that's been on the floor a
long while now. In truth it's 'play' down my list at the moment -
though(1) ;-).
I 'believe' in rtr much of the work needed to create an output image is
still done for each frame, perhaps I just need to figure out how to
pause and trigger a write to unique output files. Oh, and some way to
run through all the cameras only once I guess.
Bill P.
(1) - Banging around my head of late is the idea that with functions we
can perhaps create a collection of inbuilts that query generic
environmental information and return a 'change-this' result(1a) which
could be used during the render of each frame. With >= v3.8 we have
stuff like user_defined cameras, pigments and densities(media)... We
have longer had stuff like isosurfaces, parametrics. Supposing such a
collection of inbuilt functions, might we be able to change quite a lot
more stuff frame to frame in rtr? Arbitrarily fly about a scene with a
couple user defined camera definitions which are no longer static?
(1a) - Expect too might need f_delay, f_pause_resume like inbuilt
functions rather than just functions that might query the state of
values in some file say. Guess f_delay might be useful all by itself.
Post a reply to this message
|
|
