 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jr" <cre### [at] gmail com> wrote:
>...I thought why aren't the basic image_map pigments in
> an array? (perhaps in a separate include file) then the macro (and other code)
> only need to deal with indices. eg. (just typed, any errors mine):
>
> #declare myImgMaps = array {
> pigment {image_map {jpeg "building windows 7 HO.jpg" interpolate 2}},
> ...
> };
>
> so you'd refer to 'myImgMaps[0]' etc.
>
The main trouble is with the texture{image_pattern{ syntax.
In its general form for 'masking' use...
texture{
image_pattern{
png "my_holdout_mask_image_1.png" interpolate 2 // the mask
texture_map{TEX_MAP_FOOBAR} // or just texture{...}, the texture to mask
}
}
.... the syntax of
png "my_holdout_mask_image.png" interpolate 2
is a difficult 'thing' to pre-#declare (in case you want to substitute different
images there.) It's not quite a full pigment specification. In other words,
#declare XYZ = png "my_holdout_mask_image.png" interpolate 2
doesn't even work as a #declare, it produces a fatal error, "not a valid Rvalue"
or something like that. I imagine that trying to put it into an array might have
the same problem, because entering entries in an array is like #declaring them.
Although, I may not have tried it before, I don't remember. (I tried a BUNCH of
ways around this problem, several years ago.) I could be wrong though!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
"Kenneth" <kdw### [at] gmailcom> wrote:
> "jr" <cre### [at] gmailcom> wrote:
> >...I thought why aren't the basic image_map pigments in
> > an array? (perhaps in a separate include file) then the macro (and other code)
> > only need to deal with indices. ...
>
> The main trouble is with the texture{image_pattern{ syntax.
>
> In its general form for 'masking' use...
>
> texture{
> image_pattern{
> png "my_holdout_mask_image_1.png" interpolate 2 // the mask
> texture_map{TEX_MAP_FOOBAR} // or just texture{...}, the texture to mask
> }
> }
>
> .... the syntax of
> png "my_holdout_mask_image.png" interpolate 2
> is a difficult 'thing' to pre-#declare (in case you want to substitute different
> images there.) It's not quite a full pigment specification.
ok. and an array of image_patterns? how many of those? (2* 34? more?)
(have never used 'image_pattern' but if it can be declared, it can be stuffed
into arrays)
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jr" <cre### [at] gmailcom> wrote:
> > .... the syntax of
> > png "my_holdout_mask_image.png" interpolate 2
> > is a difficult 'thing' to pre-#declare (in case you want to substitute different
> > images there.) It's not quite a full pigment specification.
>
> ok. and an array of image_patterns? how many of those? (2* 34? more?)
>
> (have never used 'image_pattern' but if it can be declared, it can be stuffed
> into arrays)
>
Just 34 of them (so far.) SO, I *could* make 34 complete image_patterns, stick
them into an array-- which hopefully will accept them and greatly reduce the
subsequent memory load-- then call *those* in the repeating
texture{image_pattern{... later.
Those 34 image_patterns will necessarily need their '2nd part' included as well,
the texture to be masked, TEX_MAP_FOOBAR. I may have to make 34 of *those*,
because they also randomly vary (in 34 ways), yet need to 'match up' with the
'1st part' of each image_pattern, the hold-out-mask. (The way my code is
constructed at present, it's all handled in a completely different and somewhat
code-efficient way, simply because of that thorny image_pattern syntax. Thus the
current macro use-- which isn't ideal, memory-wise.)
Not an insurmountable task, and might be worth the effort... which is solely to
reduce the scene's memory load and parse time. My Windows 7 machine has only 7GB
of ram(!), so disc-swapping currently begins to happen if I try to make, say,
10000 buildings.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
You're either going to use memory, or spend a lot of time reading in the image
data during parse time.
If you want to save on memory usage, you could likely assign the image_map file
to the same identifier name every time, and that might keep the memory usage
down.
With regard to using the png + filename in an array, you no longer need to
specify the file type - POV-Ray will automagically detect that.
http://news.povray.org/povray.advanced-users/message/%3C5ba3b5f9%241%40news.povray.org%3E/#%3C5ba3b5f9%241%40news.povra
y.org%3E
http://news.povray.org/povray.animations/thread/%3Cweb.5c037ac5c84714c0730e3a270%40news.povray.org%3E/
You can also assign full pigment statements to array elements, thus ensuring
that they have the complete and correct syntax, and then reference those
fully-formed image_maps by name/index.
#declare _Array [1] = pigment {image_map {"Filename.png"} }
#macro macroName ()
blah
blah
pigment {_Array [1]}
blargety
blech
#end
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
> Just 34 of them (so far.) SO, I *could* make 34 complete image_patterns, stick
> them into an array-- which hopefully will accept them and greatly reduce the
> subsequent memory load-- then call *those* in the repeating
> texture{image_pattern{... later.
If you're going to use the image map to render something, then AFAIK, it needs
to be in memory, so the render engine can refer to the pixel values in order to
calculate the rendered image result. So I don't think there's any way around
decreasing the memory except for using smaller images. Even using something
like jpg instead of png might not work, since the jpg has to be decompressed.
And if that's done on the fly, and not all at once, then you're taking a hit on
render time.
> code-efficient way, simply because of that thorny image_pattern syntax. Thus the
> current macro use-- which isn't ideal, memory-wise.)
The macro is stored in memory - the referenced contents of the macro are not -
until the macro is invoked.
Since it's just ASCII text, even a smalll book wouldn't take up a prohibitive
amount of memory in comparison to the image data.
> Not an insurmountable task, and might be worth the effort... which is solely to
> reduce the scene's memory load and parse time. My Windows 7 machine has only 7GB
> of ram(!), so disc-swapping currently begins to happen if I try to make, say,
> 10000 buildings.
Buy more RAM - I ignored the people who said I couldn't put 16 GB of RAM in my
laptop after researching the issue. Been running fine for years.
You can also do that thing where you use a (cheap) USB drive to boost your
memory - no idea how fast/slow that is, but it will save on the HDD thrashing.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
> ...
> Buy more RAM ...
+1
> You can also do that thing where you use a (cheap) USB drive to boost your
> memory - no idea how fast/slow that is, but it will save on the HDD thrashing.
second h/d and place all '/tmp/' and working directories on it (faster i/f than
USB).
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 10/4/2020 um 9:46 schrieb Kenneth:
> Yes, that is true in most cases-- probably 99% of cases! But my scene makes use
> of a repetitive (and randomly-configured) texture{image_pattern...) as a
> 'hold-out mask' for creating the many building windows' reflections; one texture
> is used to mask another texture. The best way-- the only way(?)-- that I could
> come up with to make it work in my scene was to use a rather odd-looking macro
> for substitution in the texture{image_pattern...}. Like this, one of 34 similar
> examples of my macro at present...
>
Just do not use the "texture_map" construct (as you say it has an odd
syntax making it impossible to pre-declare the used image maps), use
"pigment_pattern" instead. Like so:
#declare C_map_01 = pigment {image_map {png "cutout01" }};
#declare T_01 = texture {
pigment { whatever ... }
finish { whateever ... e.g with reflection }
}
#declare T_02 = texture {
pigment { whatever... }
finish { whateever ... e.g. without reflection }
}
#declare T_01 = texture {
pigment_pattern {C_map_01}
texture_map {
[0 T_01]
[1 T_02]
}
}
You can use this construct within macros, switch clauses or wherever you
want to and the image files are loaded only once - while reducing memory
usage and parse time.
I myself visit these NG only every few months and with most "veterans"
gone some wisdom seems to be lost. But 15 years ago it was common
knowledge to use pigment_map for all kind of things like finish maps,
opaticity maps, emission maps and what have you.
-Ive
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
> The main trouble is with the texture{image_pattern{ syntax.
>
> In its general form for 'masking' use...
>
> texture{
> image_pattern{
> png "my_holdout_mask_image_1.png" interpolate 2 // the mask
> texture_map{TEX_MAP_FOOBAR} // or just texture{...}, the texture to mask
> }
> }
[snip]
Sorry, I posted somewhat wrong syntax in that example (the placement of the
curly brackets). I was hastily writing 'on the fly' :-O It should be:
texture{
image_pattern{
png "my_holdout_mask_image_1.png" interpolate 2 // the mask
}
texture_map{TEX_MAP_FOOBAR} // or just texture{...}, the texture to mask
}
.... which makes the following idea partially wrong:
[snip]
> SO, I *could* make 34 complete image_patterns, stick
> them into an array-- which hopefully will accept them and greatly reduce the
> subsequent memory load-- then call *those* in the repeating
> texture{image_pattern{... later.
>
> [WRONG:] Those 34 image_patterns will necessarily need their '2nd part'
> included as well, the texture to be masked, TEX_MAP_FOOBAR.
Nope, the '2nd part' is not enclosed in the image_pattern{...}.
Well, the whole idea will not work anyway (or *maybe* it would in an array?)--
an image_pattern{...} block cannot be #declared. Same error as before, "not an
RValue." I guess it's the same behavior as trying to #declare a bare
image_map{...}, which likewise doesn't work.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ive <ive### [at] lilysoftorg> wrote:
>
> Just do not use the "texture_map" construct (as you say it has an odd
> syntax making it impossible to pre-declare the used image maps), use
> "pigment_pattern" instead. Like so:
[snip]
Thank you, Ive! That is a very elegant workaround for the problem, and I will
make use of it.
When I started working on this scene years ago, I'm sure that I looked at
pigment_pattern, image_pattern, texture_map etc in the documentation, when
trying to formulate my idea for masking the buildings' windows to add
reflections. What threw me off was a little sentence in pigment_pattern. "Note:
This pattern uses a pigment to get the gray values. If you want to get the
pattern from an image, you should use the image_pattern". Since my scene used
image_maps of real windows, off I went there-- which then gave an example of
using the image_pattern as a MASK. Just what I wanted! But I didn't realize that
the image_pattern's 'syntax #declare problem' was unique to itself (well,
different from the pigment_pattern). And unfortunately, there's no explicit
mention of 'masking' ability in the 'pigment_pattern' docs, or an example like
your code. I thought the only way to do it was with the image_pattern. In
hindsight, I suppose I should have realized that your code trick would have been
a workable alternative-- but it didn't occur to me to 'read between the lines',
so to speak.
Your example code would be a great addition to the docs at 'pigment_pattern'.
Thanks again!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> If you're going to use the image map to render something, then AFAIK, it needs
> to be in memory, so the render engine can refer to the pixel values in order
> to calculate the rendered image result. So I don't think there's any way
> around decreasing the memory except for using smaller images.
Yes, all my images are small in file size. Some are tiny! But I've come to
realize that it's the repetitive use of the 'hold-out mask' images that cause my
scene's parse time and memory use to skyrocket; those image are the ones that I
haven't (yet) been able to pre-#declare, due to the image_pattern's syntax
problem. But I've's pigment_pattern workaround will solve that.
I did a really simple memory-use experiment this week, with 10,000 image_mapped
boxes in a #while loop-- nothing fancy-- to see how BOTH parse time and memory
were affected. Using a single image_map, and *without* pre-#declaring the image,
the parsing took a LOT of time (with constantly increasing memory use as the
image had to be 're-processed' for each iteration.) By pre#declaring the image,
the entire parse/render occured in mere seconds, with a much-reduced memory
load.
> Even using something
> like jpg instead of png might not work, since the jpg has to be decompressed.
> And if that's done on the fly, and not all at once, then you're taking a hit
> on render time.
Yep, I agree. Sad to say, when I started working on this scene, I used jpg's,
and have continued that way ever since. The reason being, that my OLD version of
Photoshop has wonky problems with correct png gamma when saving an edited image.
So no png's. But otherwise I LOVE my old version of PS; it's just easier to use
(for me) than GIMP.
>
> The macro is stored in memory - the referenced contents of the macro are
> not - until the macro is invoked.
> Since it's just ASCII text, even a small book wouldn't take up a prohibitive
> amount of memory in comparison to the image data.
Ah, thanks for the clarification.
>
> Buy more RAM -
Ha! But that would defeat my purpose of trying to get me scene to run in, uh,
256K :-P
> I ignored the people who said I couldn't put 16 GB of RAM in my
> laptop after researching the issue. Been running fine for years.
THAT'S interesting. Yeah, AFAIK, my Win 7 box has an 8MB limit(?), so I never
thought of trying to increase it. So, my computer wouldn't actually explode,
right??
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
