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