 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi all,
I've just started playing around with isosurfaces in MP0.6a, and have been
a little confused about what keywords are/aren't alowed when defining
functions. In particular, I wanted to use the rand() function, but I get
the error "float factor expected but rand found instead". As far as I
know, rand() returns a float factor, so this error doesn't make sense to
me. Are function expressions parsed differently than other pov code so
that they only allow a particular subset of the available functions?
Here's an example of what I'm struggling with:
#declare rand_seed = seed(0)
#declare f1 = function { (x + rand(rand_seed))^2 + y^2 + z^2 - 1 }
I would expect this to define a sphere of radius one positioned at a random
point between zero and one on the x-axis.
I've played around with noise3d(), which is an alternate solution, but
noise3d() appears to be similar to the bozo pattern where points which are
close together are less random than those far apart, and I am looking for a
way to get random positioning independent of proximity.
Thanks for your help.
Ken
P.S. Another question I had, which I am getting the impression is a
feature which is not yet avaiable, was how to define functions which accept
variables like the builtin functions do. Is this possible, or does have to
be done by building the function in a precompiled library?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken Cecka wrote:
>
> Hi all,
>
> I've just started playing around with isosurfaces in MP0.6a, and have been
> a little confused about what keywords are/aren't alowed when defining
> functions. In particular, I wanted to use the rand() function, but I get
> the error "float factor expected but rand found instead". As far as I
> know, rand() returns a float factor, so this error doesn't make sense to
> me. Are function expressions parsed differently than other pov code so
> that they only allow a particular subset of the available functions?
> Here's an example of what I'm struggling with:
>
> #declare rand_seed = seed(0)
> #declare f1 = function { (x + rand(rand_seed))^2 + y^2 + z^2 - 1 }
>
I also recently had this problem and managed it this way:
#declare rand_seed = seed(0)
#declare Rnd1 = rand(rand_seed)
#declare f1 = function { (x + Rnd1)^2 + y^2 + z^2 - 1 }
I think it's just a limitation of the isosurface parser, maybe it could be
changed, but this way works quite well.
Christoph
--
Christoph Hormann <chr### [at] gmx de>
Homepage: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
> I also recently had this problem and managed it this way:
>
> #declare rand_seed = seed(0)
> #declare Rnd1 = rand(rand_seed)
> #declare f1 = function { (x + Rnd1)^2 + y^2 + z^2 - 1 }
>
> I think it's just a limitation of the isosurface parser, maybe it could be
> changed, but this way works quite well.
It's not very intuitive however and probably should be changed
at the parser level if at all possible.
One question does arise is how much does a random number do in
a static equation. If you were running it through a loop I could
understand using it but I see no real advantage to it the way
that Ken illustrated it.
--
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3a0b8584$1@news.povray.org>, Ken Cecka <cec### [at] homecom>
wrote:
> I've just started playing around with isosurfaces in MP0.6a, and have
> been a little confused about what keywords are/aren't alowed when
> defining functions. In particular, I wanted to use the rand()
> function, but I get the error "float factor expected but rand found
> instead". As far as I know, rand() returns a float factor, so this
> error doesn't make sense to me. Are function expressions parsed
> differently than other pov code so that they only allow a particular
> subset of the available functions?
Yes. Instead of calling the functions immediately, the function is read
and used to create a data structure that can be quickly evaluated
multiple times during rendering. The rand() function would be useless
here, it would just return a new value *every time the function was
evaluated*, making it impossible for the isosurface algorithm to find a
surface.(though it still could be useful for some patterns and if
functions are allowed to be called in scene code)
Not all functions which return floats are allowed, there is a list of
allowed keywords in the documentation. (5.2.12. New keywords / operators
for the isosurface patch)
To do what you want, declare a variable with the random number and use
that variable in the function. This will calculate *one* random number
and use it in the function, instead of calculating a new one every time
the function is used.
> P.S. Another question I had, which I am getting the impression is a
> feature which is not yet avaiable, was how to define functions which
> accept variables like the builtin functions do. Is this possible, or
> does have to be done by building the function in a precompiled
> library?
It is currently impossible without modifying the source. And be aware
that the built in functions probably won't make it into POV 3.5.
--
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 <3a0b8584$1@news.povray.org>, Ken Cecka <cec### [at] homecom>
wrote:
> I've played around with noise3d(), which is an alternate solution,
> but noise3d() appears to be similar to the bozo pattern where points
> which are close together are less random than those far apart, and I
> am looking for a way to get random positioning independent of
> proximity.
The noise3d() function is identical to bozo, spotted, and bumps, though
using noise3d() is probably a bit faster than a pigment function with
one of those patterns.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
>
> It's not very intuitive however and probably should be changed
> at the parser level if at all possible.
>
> One question does arise is how much does a random number do in
> a static equation. If you were running it through a loop I could
> understand using it but I see no real advantage to it the way
> that Ken illustrated it.
>
I used it in a macro of my IsoWood include generating several random oriented
planes in the isosurface function. The macro is called with a random seed as
parameter. Of course that's a quite rare construction.
Christoph
--
Christoph Hormann <chr### [at] gmxde>
Homepage: http://www.schunter.etc.tu-bs.de/~chris/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
> One question does arise is how much does a random number do in
> a static equation. If you were running it through a loop I could
> understand using it but I see no real advantage to it the way
> that Ken illustrated it.
>
The example I gave was just for simplicity. Not particularly useful. What
I'm really using it in is an attempt at a rock wall. I looked at David
Wilkinson's "Wot no superellipsoids?" brick wall and played with that a
bit, but I want to make a rock wall with more random shapes and positions.
What I've got so far is:
#declare f1 = function {
z^8 + //bounds the brick depth
(cos(y))^8 + //repeating across +/- y
(cos((x + ( //repeating across +/- x
2 * pi * noise3d(0, floor(y / pi), 0) //each row gets shifted randomly
))/2))^30 -
0.9 //leave room for mortar
}
Using noise3d, the shifts between rows tend to form up in patterns,
gradually shifting one direction, then back the other. I'd rather have
those shifts be completely random. Based on Chris Huff's explanation, it
sounds like rand() won't do this for me since it will only be calculated
onec for the whole function. So I'll have to play with exagerating the
shifts produced by noise3d(), or come up with some other pseudo-random
effect that I can generate on my own.
Ken
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 10 Nov 2000 12:29:41 -0800, Ken Cecka <cec### [at] homecom> wrote:
>The example I gave was just for simplicity. Not particularly useful. What
>I'm really using it in is an attempt at a rock wall. I looked at David
>Wilkinson's "Wot no superellipsoids?" brick wall and played with that a
>bit, but I want to make a rock wall with more random shapes and positions.
>What I've got so far is:
>
>#declare f1 = function {
> z^8 + //bounds the brick depth
> (cos(y))^8 + //repeating across +/- y
> (cos((x + ( //repeating across +/- x
> 2 * pi * noise3d(0, floor(y / pi), 0) //each row gets shifted randomly
> ))/2))^30 -
> 0.9 //leave room for mortar
>}
>
Ken, my latest isofunction for brick walls etc. is much simpler and might be a
better starting point for you. I posted the source in p.b.s-f as <Isosurface
mesh>.
(And thanks to Cristoph for for showing me how to use a random function in an
isosurface)
David
----------------------
dav### [at] hamiltonitecom
http://hamiltonite.com/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3a0c5d3a$1@news.povray.org>, Ken Cecka <cec### [at] homecom>
wrote:
> Using noise3d, the shifts between rows tend to form up in patterns,
> gradually shifting one direction, then back the other. I'd rather have
> those shifts be completely random.
Perhaps you would have better luck with a pigment function...crackle, or
granite...
> Based on Chris Huff's explanation, it sounds like rand() won't do
> this for me since it will only be calculated onec for the whole
> function.
Not quite. You currently have to declare a value outside the function
and use it, so doing that will calculate it once. If rand() ever becomes
available inside functions, it will be calculated every time the
function is evaluated, which will make it useless for isosurfaces.
(though still useful for patterns, to give a "grainy" effect)
> So I'll have to play with exagerating the shifts produced by
> noise3d(), or come up with some other pseudo-random effect that I can
> generate on my own.
Try only evaluating noise3d() at certain points, and scale it very small
so the "patterns" are smaller than the rocks.
--
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
|
|
| |
| |
|
|
|
|
| |
|
|
