 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I am wondering why it is not possible to declare a pattern. Patterns are
used so many placed, and they could easily be made completely consistent
with the way other things are declared and called in POV-Ray:
#declare MyPattern =
pattern {crackle sine_wave frequency 2 turbulence 0.5 translate 3*y}
#declare MyPigment = pigment {MyPattern color_map {[0,rgb 0.2][1,rgb 1]}}
I think it would be an obvious feature to add, and it would make many things
more simple.
For example you could declare a pattern once and then call this pattern in
both the pigment and the normal.
I have also tried to make pigment_maps where the color_maps for each entry
are different, but the patterns are identical. In such cases it would be
*very* convenient to be able to declare patterns.
Currently if you want to add turbulence or similar to a pattern without it
affecting child patterns you must either use reset_children (which will not
be in 3.5) or use the pattern in a pigment, add turbulence to this pigment,
and then convert the pigment back to a pattern again using pigment_pattern.
It seems to me like an awkward way of doing it. The two conversions could be
avoided if my pattern suggestion was implemented. It would then simply work
like this:
pigment {
pattern {spotted turbulence 0.8}
pigment_map {...}
}
In MegaPov there's a pigment function feature which converts a pigment to a
function. However, functions return floats, not vectors, so it really would
be more logic if it took a pattern as input. I suspect that the only reason
it takes a pigment as input is that patterns - for some reason - can't
currently be declared.
So, there a lots of reasons to make it possible to declare patterns.
Is there any specific reason that patterns can't be declared?
It would be *so* useful!
Rune
--
\ Include files, tutorials, 3D images, raytracing jokes,
/ The POV Desktop Theme, and The POV-Ray Logo Contest can
\ all be found at http://rsj.mobilixnet.dk (updated January 28)
/ Also visit http://www.povrayusers.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3a9fd51c@news.povray.org>, "Rune" <run### [at] iname com>
wrote:
> In MegaPov there's a pigment function feature which converts a
> pigment to a function. However, functions return floats, not vectors,
> so it really would be more logic if it took a pattern as input. I
> suspect that the only reason it takes a pigment as input is that
> patterns - for some reason - can't currently be declared.
That isn't the reason...before the spline_wave patch, the advantage of
pigments was that you could modify the pattern with a different
color_map. Now that is irrelevant, though, since you can use a
spline_wave as a float_map.
> So, there a lots of reasons to make it possible to declare patterns.
> Is there any specific reason that patterns can't be declared?
Not really...I've often thought that the syntax you describe would be
better. And this issue has been discussed before...another area that
would benefit is normals: MegaPOV now transforms the "bumps" along with
the pattern, which is often desired but sometimes not what you wanted, a
pattern{} block could be used to specify pattern-specific transforms.
I've recently figured out how to declare things, so I'll probably make
an attempt at this feature, it shouldn't be too difficult. The only
problem is that the "pattern" keyword is already used, but it's current
use is pretty unintuitive. (The "pattern" image type, which creates an
image from a pigment..."pigment_image" would be a better choice, in my
opinion. I don't think changing it would cause a lot of trouble...)
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 02 Mar 2001 15:49:24 -0500, Chris Huff wrote:
>I've recently figured out how to declare things, so I'll probably make
>an attempt at this feature, it shouldn't be too difficult. The only
Be careful. There are some gotchas with identifiers that I just found
whilst gallivanting through the code.
>problem is that the "pattern" keyword is already used, but it's current
This doesn't preclude your reusing it in a different context.
>use is pretty unintuitive. (The "pattern" image type, which creates an
>image from a pigment..."pigment_image" would be a better choice, in my
>opinion. I don't think changing it would cause a lot of trouble...)
Originally it was to have taken a pattern as argument. I don't remember
now why it wasn't written to do so, but I suspect it had something to do
with transforms and other warps not being usable at that level, or with
things like pigment_map and average that aren't strictly patterns. Maybe
I should keep a diary of these things.
Better might be to just get rid of it altogether, since there are now
lots of better ways of doing most of what it can do. Not likely to
happen now, though, for hysterical raisins.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Can you declare a "pigment_pattern"? I haven't tried that myself. By the
way, I don't like "pigment_pattern". I feel the keyword is wrong. It should
just be "pattern" because it can be used in textures, and normals. (I rarely
use materials, so I don't know if it works there too.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 2 Mar 2001 16:13:51 -0600, Tony[B] wrote:
>Can you declare a "pigment_pattern"? I haven't tried that myself. By the
>way, I don't like "pigment_pattern". I feel the keyword is wrong. It should
>just be "pattern" because it can be used in textures, and normals. (I rarely
>use materials, so I don't know if it works there too.)
it's a pigment_pattern because it's a pattern made from a pigment, not because
it's used in pigments.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <slr### [at] fwicom>, ron### [at] povrayorg
wrote:
> Be careful. There are some gotchas with identifiers that I just found
> whilst gallivanting through the code.
Anything in particular? I've been following the code for the spline {}
patch, and my interpolated transformations seem to be declaring fine...I
haven't tested them with macros or arrays, though. And I've noticed that
my #set patch doesn't work for arrays.
> >problem is that the "pattern" keyword is already used, but it's current
> This doesn't preclude your reusing it in a different context.
I know, it just bothers me that the same keyword, with a very specific
meaning, is used for widely different things. And the "pattern" keyword
just doesn't seem to fit in this case.
> Originally it was to have taken a pattern as argument. I don't remember
> now why it wasn't written to do so, but I suspect it had something to do
> with transforms and other warps not being usable at that level, or with
> things like pigment_map and average that aren't strictly patterns. Maybe
> I should keep a diary of these things.
Well, pigments have colors...but I don't recall if this "image" type can
be used outside height fields (and I can't think of any reason you
*would* use it directly...). With pigments, you can drastically modify
the shape of the surface by using different color_maps, and while you
can do the same now with ordinary patterns using the spline_wave patch,
it wasn't around then. Similar to the reason pigments are useable as
isosurface functions, but patterns aren't.
Well, there is also the fact that patterns can't be declared... ;-)
> Better might be to just get rid of it altogether, since there are now
> lots of better ways of doing most of what it can do.
There are? The only way I can think of would be to write a macro that
uses eval_pigment() to create a mesh...and that's only for height fields.
> Not likely to happen now, though, for hysterical raisins.
If it *is* modified or removed, it should be now, before there are
enough "hysterical raisins". I doubt there is anyone who has used it who
wasn't aware that it is an experimental feature of an unofficial version.
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3aa00ee0@news.povray.org>, "Tony[B]" <ben### [at] catholicorg>
wrote:
> Can you declare a "pigment_pattern"? I haven't tried that myself.
I highly doubt that it works differently from the other patterns.
> By the way, I don't like "pigment_pattern". I feel the keyword is
> wrong. It should just be "pattern" because it can be used in
> textures, and normals. (I rarely use materials, so I don't know if it
> works there too.)
It's called "pigment_pattern" because it takes a pigment and turns it
into a pattern. Makes perfect sense to me..."pattern" wouldn't, though.
(What kind of pattern? What's this pigment doing here?)
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 02 Mar 2001 16:51:41 -0500, Chris Huff wrote:
>In article <slr### [at] fwicom>, ron### [at] povrayorg
>wrote:
>
>> Be careful. There are some gotchas with identifiers that I just found
>> whilst gallivanting through the code.
>
>Anything in particular? I've been following the code for the spline {}
>patch, and my interpolated transformations seem to be declaring fine...I
>haven't tested them with macros or arrays, though. And I've noticed that
>my #set patch doesn't work for arrays.
Macros is the biggie. Identifiers as arguments to macros are passed by
reference, and the code to do that is... interesting.
>> Originally it was to have taken a pattern as argument. I don't remember
>> now why it wasn't written to do so, but I suspect it had something to do
>> with transforms and other warps not being usable at that level, or with
>> things like pigment_map and average that aren't strictly patterns. Maybe
>> I should keep a diary of these things.
>
>Well, pigments have colors...but I don't recall if this "image" type can
>be used outside height fields (and I can't think of any reason you
>*would* use it directly...).
Ah, that one I can answer (one would hope so, since I wrote the patch.) It
can be used outside height fields, and such a thing was used to create the
images you'll find at
http://www2.fwi.com/~parkerr/hfstones.jpg
http://www2.fwi.com/~parkerr/hfstone2.jpg
because I hadn't told MCB that we needed a planar warp yet. :)
>it wasn't around then. Similar to the reason pigments are useable as
>isosurface functions, but patterns aren't.
>[...]
>There are? The only way I can think of would be to write a macro that
>uses eval_pigment() to create a mesh...and that's only for height fields.
You answered your own question, there, sorta.
>> Not likely to happen now, though, for hysterical raisins.
>
>If it *is* modified or removed, it should be now, before there are
>enough "hysterical raisins". I doubt there is anyone who has used it who
>wasn't aware that it is an experimental feature of an unofficial version.
Ah, what I meant was a different sort of hysterical raisins. I can't really
elaborate here; ask me in a different place.
--
Ron Parker http://www2.fwi.com/~parkerr/traces.html
My opinions. Mine. Not anyone else's.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <chrishuff-C6F2EA.15492402032001@news.povray.org> , Chris
Huff <chr### [at] maccom> wrote:
> I've recently figured out how to declare things, so I'll probably make
> an attempt at this feature, it shouldn't be too difficult.
Be aware, you end up fixing half of POV-Ray texture code along with it.
The problem is that textures and pigments are close to the same thing in
the internal representation. Once you start fixing the Parse_Pattern
you will end up fixing the data structures for textures, media (take a
look at the "next" pointer in _patterns_). I have code going fairly far
(based on the current source code) but as said, you end up fixing so
many things (if you want to implement it well the first time) that you
would end up having to test every texture, media, pigment, normal and
pattern feature in combinations to make sure you didn't break anything.
Possible, but do you really want to do so if it is all going to be
trashed in case of a rewrite? The texture code side effects are really
one of the biggest messes you can find in the current code base :-(
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3aa0280c$1@news.povray.org>, "Thorsten Froehlich"
<tho### [at] trfde> wrote:
> Possible, but do you really want to do so if it is all going to be
> trashed in case of a rewrite? The texture code side effects are really
> one of the biggest messes you can find in the current code base :-(
I think it could be done without too much trouble or code, just parse
the pattern into a variable and implement a case in Parse_Pattern to
handle pattern identifiers that would just copy the needed data. I don't
see anything in the code that will prevent this being tacked on...but if
this is going to be in 3.5, or even if the relevant code will be cleaned
up, there isn't much of a reason to mess with it now. Especially when
the only version it would ever be included in is MegaPOVPlus, wouldn't
be used by anyone, and there are workarounds in the current version...
--
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
<><
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
