Greetings to all.

With all the ongoing talk on requested new features in POV 3.5 , I
thought I could share my ideas, too. I am starting a new thread as
this is OT from the "POV 3.5 Ideas" thread started May 27 by Chris
Huff.

The first request I have is for a new pattern types. It should work in
a way similar to crackle, but the user should be able to explicitly
position the centers of attraction. These points must lie within the
unit cube and this 3D pattern will be tiled in 3D to fill up the whole
space. For example, if you specify these points:

<0,0,0>, <0.5,0.5,0.5>

you should get a pattern similar to a body-centered cubic crystal
lattice (like that of Fe, iron). These:

<0,0,0>, <0.5,0.5,0>, <0.5,0,0.5>, <0,0.5,0.5>

should give a face-centered cubic lattice.

If you take a look at my Biofractal picture I posted a couple of weeks
ago, you will see a rather weird application of the crackle pattern.
There's media inside the julia fractal with a crackle density, the
color map of which has a very slim opaque band from 0 to 0.05 and the
rest is clear. You can clearly notice the crackle pattern "lattice".
It can sometimes be useful to have this done in a non-random,
user-specified way, for example in modeling crystalline structures.

This pattern should have a 2D version, too. It should consist of
"prisms" that extend parallel to one of the coordinate axes, say z,
just like wood, marble, image_map are actually 2D patterns extended
along the z axis.

I suggest the names lattice3 and lattice2 respectively. I can also
suggest syntax, but I want to see if this idea will get anywhere at
all.

The next request I have is for a new warp type - the "twist" or
"twirl" or "whirlpool" warp. Basically, it will create a local
whirlpool effect on a pattern. The center of the whirlpool should be
specified by the user, as well as an optional repeat vector and
turbulence, as in the black_hole warp. Next the vector normal to the
plane of "whirling" should be specified. The maximum angle of
displacement (when distance to the whirlpool center approaches zero)
should be specified, too. The radius of influence, identical to that
of the black_hole warp, should be specified, as well as the strength
falloff function. A pseudo-code formula is provided below:

distance = vlen (currentPoint-whirlCenter);
if (  distance <= whirlRadius )
  realPatternValue =  getPatternValue ( vaxisrotate (currentPoint -
  whirlCenter, whirlNormalVector, whirlMaxAngle * falloffFunction (
  distance ) ) + whirlCenter );

If this is unclear (it is messy for sure), please feel free to ask me.

The last (for now) request I have is for a new pattern modifier. It
should specify the falloff function of any property that falls off
with distance. This light intensity throughout the cross-section of a
spotlight or cylindrical light, black_hole strength falloff, light
falloff, light attenuation by distance or media and fog, rainbow
falloff angle, and any others that I can't think of from the top of my
head.

Any continuous function should be a valid falloff function. In halos
we had linear, cubic and poly, but sin, cos, exp, log,  pow and others
should be allowed, too. Some functions may require additional
modifiers, such as log base or sine frequency multiplier and phase.

Any number of falloff function modifiers could be used, the final
result being the product of the individual results of all of them.

I think there are many possible uses for this modifier. For example, a
radial pattern with a twist warp and falloff functions sin and linear
will result in something looking like a Mayan sun. Or, if two point
light sources use sine functions for their distance falloff, we can
observe an interference pattern on a screen. The artistic applications
of this may exceed the scientific and/or photorealistic ones, but art
is a major application of POV (as well as having fun :) )

As usual, any suggestions, comments, criticism etc. are welcome.

Best regards to all.

Peter Popov
ICQ: 15002700

Post a reply to this message

These seem like relatively simple and potentially useful features. One thing
about the twirl warp, tho. You seem to imagine the effect as a cylindrical
one, i.e. it extends infinitely in the direction perpendicular to the "twirl
plane". This might have unwanted effects, like the warp appearing on the
other side of the object.
My head isn't working in 3D right now; couldn't this warp be spherical, like
the black hole, with the twirl applied from all directions towards the
center?
Ouch, I hurt my brain trying to imagine that...

Margus

Post a reply to this message

>I suggest the names lattice3 and lattice2 respectively. I can also
suggest syntax, but I want to see if this idea will get anywhere at
all.<
Why not crystalline and prismatic?

All of these are good ideas, and I hope someone will put them into a
patch to be included in POV 3.6 or 4.0 or whatever. (If it is too late
for 3.5. I have heard very little information on the progress of that
version. Any hints?)

Post a reply to this message

On Thu, 3 Jun 1999 02:34:30 +0300, "Margus Ramst" <mar### [at] peakeduee>
wrote:

>These seem like relatively simple and potentially useful features. One thing
>about the twirl warp, tho. You seem to imagine the effect as a cylindrical
>one, i.e. it extends infinitely in the direction perpendicular to the "twirl
>plane". This might have unwanted effects, like the warp appearing on the
>other side of the object.

You are right. 

How about... if all falloff functions can have an optional axis
specified? The values will then fall off in one direction, i.e. the
equipotential surfaces will be planes as opposed to spheres. All we
need is take a projection of the vector from the center of the
"whatever we are modifying the falloff of" to the point in question
and project it onto the axis (do a dot product with the normalised
axis vector)? 

>My head isn't working in 3D right now; couldn't this warp be spherical, like
>the black hole, with the twirl applied from all directions towards the
>center?

Maybe. If the plane of twirling is the plane through the center of the
twirl and perpendicular to the plane defined by the current camera ray
and twirl center.

>Ouch, I hurt my brain trying to imagine that...

I suppose it won't work in 3D as expected. I'll think some and if I
Can come up with anyting I'll render it into a df3

>Margus


Peter Popov
ICQ: 15002700

Post a reply to this message

On Wed, 02 Jun 1999 21:23:38 GMT, Peter Popov wrote:
>The next request I have is for a new warp type - the "twist" or
>"twirl" or "whirlpool" warp. Basically, it will create a local
>whirlpool effect on a pattern.

Oddly enough, the 3.0 source had some of the support code for a 
so-called "spiral" warp, but it was never implemented.  The code 
was removed in 3.1.

All of these ideas, with the possible exception of the falloff
stuff, are very easy to implement.  The crystalline lattice 
could be implemented as yet another patch to the crackle 
pattern - I would say a syntax something like 

crackle {
  centers {2, <0,0,0>, <.5,.5,.5>}
}

but with a better keyword than "centers", of course.  I had thought 
at one time of making crackle 2d as well, but with the planar warp in 
the new superpatch such a thing is redundant.

Post a reply to this message

Note that the isosurface function can be used to create pigment patterns
too. This is a very promising and interesting possibility that few people
seem to have investigated so far (I didn't either). New built-in pattern
types like those already in the superpatch would be nice of course.

Gilles

Ron Parker wrote:

> Oddly enough, the 3.0 source had some of the support code for a
> so-called "spiral" warp, but it was never implemented.  The code
> was removed in 3.1.
>
> All of these ideas, with the possible exception of the falloff
> stuff, are very easy to implement.  The crystalline lattice
> could be implemented as yet another patch to the crackle
> pattern - I would say a syntax something like
>
> crackle {
>   centers {2, <0,0,0>, <.5,.5,.5>}
> }
>
> but with a better keyword than "centers", of course.  I had thought
> at one time of making crackle 2d as well, but with the planar warp in
> the new superpatch such a thing is redundant.

Post a reply to this message

Peter Popov wrote in message <3755fdc2.38371480@news.povray.org>...
>
>You are right.
>
>How about... if all falloff functions can have an optional axis
>specified? The values will then fall off in one direction, i.e. the
>equipotential surfaces will be planes as opposed to spheres. All we
>need is take a projection of the vector from the center of the
>"whatever we are modifying the falloff of" to the point in question
>and project it onto the axis (do a dot product with the normalised
>axis vector)?
>

Thet might do the trick on more-or-less planar surfaces. But when the
surface has steep curvature, I imagine you would see a strange pattern since
the amount of twirl is different at different heights. Hmm... The spiral
would start curving back towards the original position as the twirl falls
off... I think.

>
>Maybe. If the plane of twirling is the plane through the center of the
>twirl and perpendicular to the plane defined by the current camera ray
>and twirl center.
>

Reread the sentence and say it isn't confusing :) I believe I'm rephrasing
what you said, but here's how I imagine it. The twirl plane would be defined
by 3 points: camera location, warp center and current intersection point.
Twirl axis - the normal vector of this plane.
The question is, how would this behave in an animation?


Margus

Post a reply to this message

On Sat, 5 Jun 1999 00:09:52 +0300, "Margus Ramst" <mar### [at] peakeduee>
wrote:

<snip>

>Thet might do the trick on more-or-less planar surfaces. But when the
>surface has steep curvature, I imagine you would see a strange pattern since
>the amount of twirl is different at different heights. Hmm... The spiral
>would start curving back towards the original position as the twirl falls
>off... I think.

OK, I will try to cook up an example using the GIMP to animate a twirl
effect and I'll make a .df3 out of it. We'll see what happens. I'd
attack the POV code since this patch doesn't seem that hard, but the
semester just ended and exams are on their way now, so...

>>Maybe. If the plane of twirling is the plane through the center of the
>>twirl and perpendicular to the plane defined by the current camera ray
>>and twirl center.
>>
>
>Reread the sentence and say it isn't confusing :) I believe I'm rephrasing
>what you said, but here's how I imagine it. The twirl plane would be defined
>by 3 points: camera location, warp center and current intersection point.
>Twirl axis - the normal vector of this plane.

No, the _plane_ of twirling is perpendicular to this 3-points-defined
plane, not the _normal vector_ of the twirl.

>The question is, how would this behave in an animation?

Dunno. It will mostly trry to face the camera, methinks. Will look a
little as if the image has been post-processed.

>Margus



Peter Popov
ICQ: 15002700

Post a reply to this message

On 3 Jun 1999 09:27:09 -0500, par### [at] fwicom (Ron Parker) wrote:

>Oddly enough, the 3.0 source had some of the support code for a 
>so-called "spiral" warp, but it was never implemented.  The code 
>was removed in 3.1.

Nooo... don't tell me they gave it up! :(

>All of these ideas, with the possible exception of the falloff
>stuff, are very easy to implement.

The falloff stuff requires too much fiddling, you are right. Mainly
the parser part, I think. I have to look at the code once again.

>The crystalline lattice 
>could be implemented as yet another patch to the crackle 
>pattern - I would say a syntax something like 
>
>crackle {
>  centers {2, <0,0,0>, <.5,.5,.5>}
>}

Well, I think it should have a new syntax as it will have several
parameters that don't fit into crackle at all. I'll post a sample
syntax later today.

>but with a better keyword than "centers", of course.  I had thought 
>at one time of making crackle 2d as well, but with the planar warp in 
>the new superpatch such a thing is redundant.  

Cracke2d would be much faster than planar warped crackle 3d , don't
you think?


Peter Popov
ICQ: 15002700

Post a reply to this message

Peter Popov wrote in message <375a9e93.26520084@news.povray.org>...
>
>No, the _plane_ of twirling is perpendicular to this 3-points-defined
>plane, not the _normal vector_ of the twirl.
>


But there can be an infinite number of such planes. You mean the one facing
the camera?
OK, but this would still look weird if the surface is at a shallow angle
towards the camera, i.e. the axis of rotation is near-parallel to the
surface. Since the warp would actually still be cylindrical, this would
result in a blocky gradient displacement of colur, not a "whirlpool"
pattern.
I believe a user-defined axis of twirl would be the best way to go; I can
think of no efficient way of taking into account surface topography when
applying a basically 2D pattern to a 3D surface.

Margus

Post a reply to this message

On 3 Jun 1999 09:27:09 -0500, par### [at] fwicom (Ron Parker) wrote:

<snip>
>All of these ideas, with the possible exception of the falloff
>stuff, are very easy to implement.  The crystalline lattice 
>could be implemented as yet another patch to the crackle 
>pattern - I would say a syntax something like 
>
>crackle {
>  centers {2, <0,0,0>, <.5,.5,.5>}
>}
>
>but with a better keyword than "centers", of course.  I had thought 
>at one time of making crackle 2d as well, but with the planar warp in 
>the new superpatch such a thing is redundant.  

The syntax I suggest is the following:

lattice3
{
  Number_of_vertices, <vertex1> [, <vertex2>] ... [<vertex_max>]
  [frequency <vector>]
  [falloff_function [falloff_modifiers]]
}

Number_of_vertices is a float specifying the number of vertices per
lattice cell. 

vertex1, vertex2 ... vertex_max are the 3D position vectors of the
lattice vertices. They should be situated within the unit cube. To
ensure this, the x, y and z components of a vector are calculated in
modulo 1, i.e. only the part of the number to the right of the decimal
point is considered, and 1 is added to negative numbers. For example
5.22357512 becomes 0.22357512 and -0.651 becomes 0.349 . This
calculation is invisible to the user and make the syntax easier to use
as it allows the user to place vertices wherever he/she likes.

The optional frequency vector specifies how many times the lattice
pattern should fit into the unit cube in each of the directions. This
is not the same as scaling the pattern by this amount if the
components of the frequency vector aren't all the same.

The optional falloff function should specify what law is applied to
map distance from the nearest vertex (edge? How exactly does crackle
work? I think it's vertex) to position in the map (color_map,
texture_map, /etc)


Peter Popov
ICQ: 15002700

Post a reply to this message

Here're some places one might want to use the falloff function
modifier:

spotlight and cylindrical light - to modify the tightness function
light fading - to modify the variation of intensity with distance
atmospheric attenuation - same as light fading
interior attenuation - same as light fading
in patterns - all instances where waveform modifiers can be used
black_hole warp - to modify the dependance of strength on distance

Anyone here who thinks these make sense?


Peter Popov
ICQ: 15002700

Post a reply to this message

On Sat, 05 Jun 1999 17:51:27 GMT, pet### [at] usanet (Peter Popov)
wrote:

>The optional falloff function should specify what law is applied to
>map distance from the nearest vertex (edge? How exactly does crackle
>work? I think it's vertex) to position in the map (color_map,
>texture_map, /etc)

It uses the difference between the distance to the closest point and
the distance to the second-closest point, which is twice the distance
from the edge equidistant between the two points.

You're right, a 2d version would be quite a bit faster, as it wouldn't
have to precalculate as many centers for each point.  The crystalline
version you propose would be faster yet, as it wouldn't have to
calculate any centers at all after the parsing stage.

Post a reply to this message

On Sat, 05 Jun 1999 18:03:21 GMT, par### [at] mailfwicom (Ronald L.
Parker) wrote:

>It uses the difference between the distance to the closest point and
>the distance to the second-closest point, which is twice the distance
>from the edge equidistant between the two points.

or it would be, if only the component along the line between the point
were used.  As it is, it's a little more complicated than that but I
don't think I've ever been able to see the difference.  In any case,
it's roughly proportional to the distance from the edge.

Post a reply to this message

On Sat, 5 Jun 1999 20:35:15 +0300, "Margus Ramst" <mar### [at] peakeduee>
wrote:

>>No, the _plane_ of twirling is perpendicular to this 3-points-defined
>>plane, not the _normal vector_ of the twirl.
>>
>
>
>But there can be an infinite number of such planes. You mean the one facing
>the camera?

Maybe the one passing through the point of the surface and the center
of the twirl?

It's getting too complicated here. That was just an idea that popped
into my mind. And you are right, this way it will look weird.

>I believe a user-defined axis of twirl would be the best way to go; I can
>think of no efficient way of taking into account surface topography when
>applying a basically 2D pattern to a 3D surface.

Please see povray.binaries.images for three examples of what I imagine
a twirl warp would look like. And I agree, user defined axis is the
only way. As of surface topography, you can either neglect it or use
uv mapping. How should media issues be addressed in this context, I
don't know. Perhaps someone else does.

>Margus


Peter Popov
ICQ: 15002700

Post a reply to this message

Hmm, this has probably been thought of already, but a tile_texture
keyword might be nice. It would repeat the texture in the cube from
<0,0,0> to <1,1,1> through space, flipping every other one around to
make a nice tiling pattern.(not smoothly tiling, but it would make a
nice effect with some textures.) Also a tile_texture2 which would use
different squares for each tile or tile group, so the exact same thing
doesn't repeat every time. I know it is possible to do this with the
current version, but having a keyword to do it would be nice and
probably faster rendering.
Also, allow the box to be defined.

texture {SandStone
    tile_texture2
}
or:
texture {SandStone
    tile_texture < 0, 0, 0>, < 1, 2, 2>
}

Post a reply to this message

On Sun, 06 Jun 1999 12:13:03 -0500, Chris Huff
<Chr### [at] compuservecom> wrote:

>Hmm, this has probably been thought of already, but a tile_texture
>keyword might be nice. It would repeat the texture in the cube from
><0,0,0> to <1,1,1> through space, flipping every other one around to
>make a nice tiling pattern.(not smoothly tiling, but it would make a
>nice effect with some textures.) Also a tile_texture2 which would use
>different squares for each tile or tile group, so the exact same thing
>doesn't repeat every time. I know it is possible to do this with the
>current version, but having a keyword to do it would be nice and
>probably faster rendering.

I'm not sure about the 'faster rendering' part.  Maybe a little, but
not any noticeable amount.  Why not just make a macro?

#macro Tile_Texture( Repeat_Vector ) 
  warp {repeat Repeat_Vector.x*x flip x}
  warp {repeat Repeat_Vector.y*y flip y}
  warp {repeat Repeat_Vector.z*z flip z}
#end

Post a reply to this message

If the layered textures could be layered as well I'd be one happy camper.
You know, try to put a layered texture into a layered texture and you get
no permission to do so. Guess there are several nuances like this people
would want to see eradicated.


Chris Huff wrote:
> 
> Hmm, this has probably been thought of already, but a tile_texture
> keyword might be nice. It would repeat the texture in the cube from
> <0,0,0> to <1,1,1> through space, flipping every other one around to
> make a nice tiling pattern.(not smoothly tiling, but it would make a
> nice effect with some textures.) Also a tile_texture2 which would use
> different squares for each tile or tile group, so the exact same thing
> doesn't repeat every time. I know it is possible to do this with the
> current version, but having a keyword to do it would be nice and
> probably faster rendering.
> Also, allow the box to be defined.
> 
> texture {SandStone
>     tile_texture2
> }
> or:
> texture {SandStone
>     tile_texture < 0, 0, 0>, < 1, 2, 2>
> }

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/homepage.htm
 mailto://inversez@aol.com?Subject=PoV-News

Post a reply to this message