|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/6/21 6:37 AM, ingo wrote:
> in news:web.6093a03922f25cb879819d986cde94f1@news.povray.org jr wrote:
>
>> $povray foo.pov +o/tmp/foo
>>
>
> But that means you also have the final image in ram?
>
> Ingo
>
https://wiki.povray.org/content/Reference:General_Output_Options#Max_Image_Buffer_Memory
set it to zero?
https://wiki.povray.org/content/Reference:General_Output_Options#Resuming_Options
i use -C when i don't care about state file
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/6/21 6:37 AM, ingo wrote:
> in news:web.6093a03922f25cb879819d986cde94f1@news.povray.org jr wrote:
>
>> $povray foo.pov +o/tmp/foo
>>
>
> But that means you also have the final image in ram?
>
The final written image too, yes. I like Ingo typically work on ram
disk. Everything is faster - if you have the ram for what you are doing
- and you bang on your physical disk(s) a lot less.
---
I hope Jérôme will double check me here, but there are two types of file
'disk caching' in play.
An image buffer which is already in ram up to some size (200mb?) which
can be set larger by option. The image file ends up on disk in one go at
the end being written from that image buffer.
We have too the continuation state file which I believe is indeed always
on disk (unless your disk is a ramdisk). Partly, I suspect it's because
this file is harder to cache in structure. It's software, so yeah,
expect it could be maintained in ram. It would be another large file in
memory and for those with limited ram (Raspberry PIs for example) this
starts to become an issue if you always do it.
An issue with v3.7 is the continue trace cannot be turned off (-cc /
Create_Continue_Trace_Log=no). This was one of the first things added to
v3.7+ after v3.7 was released. Would caching that file matter as much if
you could just turn off the state caching altogether as you can in v3.8?
---
I second your thought not enough detail about the caching got into the
documentation. At least, I've never run across it - those beta change
notes are there, but that is not where most will look for documentation
of the output file caching.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/6/21 7:35 AM, William F Pokorny wrote:
> I second your thought not enough detail about the caching got into the
> documentation. At least, I've never run across it - those beta change
> notes are there, but that is not where most will look for documentation
> of the output file caching.
i do not... y'all were just looking in the wrong place
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/6/21 7:35 AM, Ash Holsenback wrote:
> On 5/6/21 6:37 AM, ingo wrote:
>> in news:web.6093a03922f25cb879819d986cde94f1@news.povray.org jr wrote:
>>
>>> $povray foo.pov +o/tmp/foo
>>>
>>
>> But that means you also have the final image in ram?
>>
>> Ingo
>>
>
>
https://wiki.povray.org/content/Reference:General_Output_Options#Max_Image_Buffer_Memory
>
>
> set it to zero?
>
> https://wiki.povray.org/content/Reference:General_Output_Options#Resuming_Options
>
>
> i use -C when i don't care about state file
-cc
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/6/21 7:37 AM, Ash Holsenback wrote:
> On 5/6/21 7:35 AM, William F Pokorny wrote:
>> I second your thought not enough detail about the caching got into the
>> documentation. At least, I've never run across it - those beta change
>> notes are there, but that is not where most will look for
>> documentation of the output file caching.
>
> i do not... y'all were just looking in the wrong place
>
Perhaps we do disagree. :-) I was aware of the documentation to which
you pointed us.
I believe our documentation would be better if somewhere it included
everything in those beta release notes about output file caching - after
the first paragraph. Those realease notes are well written and clear
with several useful tips. I believe our documentation today describes
switches with not enough about implications and use - information in
those release to release notes.
(And yes, I meant jr where I wrote Ingo...)
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/6/21 7:51 AM, William F Pokorny wrote:
> On 5/6/21 7:37 AM, Ash Holsenback wrote:
>> On 5/6/21 7:35 AM, William F Pokorny wrote:
>>> I second your thought not enough detail about the caching got into
>>> the documentation. At least, I've never run across it - those beta
>>> change notes are there, but that is not where most will look for
>>> documentation of the output file caching.
>>
>> i do not... y'all were just looking in the wrong place
>>
>
> Perhaps we do disagree. :-) I was aware of the documentation to which
> you pointed us.
>
> I believe our documentation would be better if somewhere it included
> everything in those beta release notes about output file caching - after
> the first paragraph. Those realease notes are well written and clear
> with several useful tips. I believe our documentation today describes
> switches with not enough about implications and use - information in
> those release to release notes.
isn't that covered in changes.txt and / or revision.txt
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:6093dc4f$1@news.povray.org Ash Holsenback wrote:
> isn't that covered in changes.txt and / or revision.txt
>
Sometimes I'm a dumb user, not even intentionally. A search for pov-state
revealed nothing on the wiki and only the link to the release notes from a
search engine. The relation -CC pov-state never cam up to even knowing
there is +C. So, maybe some elaboration here and there if only mentioning
pov-state to make it searchable,
Thanks, the next run will be -CC
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:6093d49d$1@news.povray.org William F Pokorny wrote:
> The final written image too, yes.
Ok. I use RAMdisk for saving arrays etc during animations. Mainly because
by gear is over a decade old and I'm not too shure about the hard drive
anymore.
I've not figured out how to get a final image from ram to hard drive yet.
On Win10 3rd party software is required.
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/6/21 8:08 AM, Ash Holsenback wrote:
> On 5/6/21 7:51 AM, William F Pokorny wrote:
>> On 5/6/21 7:37 AM, Ash Holsenback wrote:
>>> On 5/6/21 7:35 AM, William F Pokorny wrote:
>>>> I second your thought not enough detail about the caching got into
>>>> the documentation. At least, I've never run across it - those beta
>>>> change notes are there, but that is not where most will look for
>>>> documentation of the output file caching.
>>>
>>> i do not... y'all were just looking in the wrong place
>>>
>>
>> Perhaps we do disagree. :-) I was aware of the documentation to which
>> you pointed us.
>>
>> I believe our documentation would be better if somewhere it included
>> everything in those beta release notes about output file caching -
>> after the first paragraph. Those realease notes are well written and
>> clear with several useful tips. I believe our documentation today
>> describes switches with not enough about implications and use -
>> information in those release to release notes.
>
> isn't that covered in changes.txt and / or revision.txt
>
Technically, sure... :-(
In stating this you are saying to use POV-Ray well, users must also read
/ remember 'all' of the POV-Ray recorded history in those files...
History which waffles and changes during development and over time.
History which isn't in anyway sorted/indexed and which in the long term
- for any software - is as often confusing as not to users post
release(1) and so I'd argue bordering on useless to other than
developers sometimes needing the long tangled view to understand the
state of code.
Post release, what is useful to us as users should be in the
documentation for that release even if duplicated! If in alpha/beta
releases and for users on the cutting edge - one can say that they must
read the release notes to know what's going on because it might not yet
be in the documentation.
(1) - Something I believe we got wrong moving post v3.7 release is that
we didn't restart the changes.txt and revision.txt files. This
especially true after we decided the v3.7.1 release was really a v3.8
release.
Anyhow, my opinion. We disagree. :-)
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Op 6-5-2021 om 15:51 schreef William F Pokorny:
> This
> especially true after we decided the v3.7.1 release was really a v3.8
> release.
>
Aaah! Confirmation of my long sustained suspicion! I had a number of
"older" scene files proudly arboring version 3.7.1; now I am sure those
are what I guessed was 3.8! :-)
--
Thomas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |