Is this standard POV? How are you evaluating the pigment?

--
David Fontaine  <dav### [at] faricynet>  ICQ 55354965
My raytracing gallery:  http://davidf.faricy.net/

Post a reply to this message

In article <3AA286FF.6BBED86F@faricy.net>, David Fontaine 
<dav### [at] faricynet> wrote:

> Is this standard POV?

Yes/no...it requires MegaPOV or POV 3.5.


> How are you evaluating the pigment?

With the eval_pigment() function.

-- 
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 <3AA27C54.A661D09B@gmx.de>, Christoph Hormann 
<chr### [at] gmxde> wrote:

> I think i also understand better now how it works, more like a displace
> warp for the surface, right?

No. While I do plan to add a feature that can displace the surface in 
other ways, the surface is only displaced along it's original normal, 
just like the height_field object.

-- 
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

Chris Huff wrote:
> 
> No. While I do plan to add a feature that can displace the surface in
> other ways, the surface is only displaced along it's original normal,
> just like the height_field object.
> 

All right, now i think i got it :-)

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

> Yes/no...it requires MegaPOV or POV 3.5.

Where?! When?! Who?! What?!

> With the eval_pigment() function.

LOL!

Post a reply to this message

In article <3aa2cfdd@news.povray.org>, "Tony[B]" <ben### [at] catholicorg> 
wrote:

> > Yes/no...it requires MegaPOV or POV 3.5.
> 
> Where?! When?! Who?! What?!

MegaPOV? Where: http://nathan.kopp.com/patched.htm, When: now, Who: 
Nathan Kopp, What: an unofficial version of POV-Ray.

Oh, you meant POV 3.5? Where: http://www.povray.org/, When: when it's 
released, Who: the POV-Team, What: the next official version of POV-Ray.

I should have written it this way: "it currently requires MegaPOV but 
will work under 3.5 when it is released". Sorry to get you so exited...

-- 
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

Chris Huff wrote:

> In article <3AA286FF.6BBED86F@faricy.net>, David Fontaine
> <dav### [at] faricynet> wrote:
>
> > Is this standard POV?
>
> Yes/no...it requires MegaPOV or POV 3.5.

Okay. I was wondering how you might have eval_pigment()ed in 3.1...

--
David Fontaine  <dav### [at] faricynet>  ICQ 55354965
My raytracing gallery:  http://davidf.faricy.net/

Post a reply to this message

This look like just the thing I need for my 'spherical Mandel mountain'. -
when you've figured out the smoothing that is.

Good luck with the smoothing.

Nekar Xenos

Chris Huff <chr### [at] maccom> wrote in message
news:chrishuff-26BCD9.13120903032001@news.povray.org...
> These macros generate height field meshes from pigments from within POV.
>
> SquareHF.jpeg is an ordinary square height field, like the
> height_field {} primitive object in POV.
>
> SphereHF.jpeg is the first type of spherical height field, using a 2D
> square wrapped around a sphere with spherical coordinates.
>
> Sphere2HF.jpeg is the second type of spherical height field, generated
> by recursively subdividing an octahedron, dividing each triangle into 4
> triangles. This doesn't have the "pinching" toward the y axis like the
> first type does.
>
> I still haven't done smoothing, I'll try to figure out a good way to do
> it.
>
> --
> 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 <chrishuff-26BCD9.13120903032001@news.povray.org> Chris Huff
wrote: 

>I still haven't done smoothing, I'll try to figure out a good way to
>do it.

How about brute force, patching Warp's mesh_smoother into Povray.
mesh{
  triangle<...>
  triangle<...>
  smooth {angle 89}
}

Also for making bumpmapping and mesh deformation macros it would be 
handy if there was a way to access the vertex/normal/uv-vectors, 
indices and lists as arrays.
mesh2arr(Mesh, vv_arr, nv_arr, tl_arr, fi_arr ...etc)

Ingo

-- 
Photography: http://members.home.nl/ingoogni/
Pov-Ray    : http://members.home.nl/seed7/

Post a reply to this message

In article <Xns### [at] povrayorg>, ing### [at] homenl (ingo) 
wrote:

> >I still haven't done smoothing, I'll try to figure out a good way to
> >do it.
> 
> How about brute force, patching Warp's mesh_smoother into Povray.
> mesh{
>   triangle<...>
>   triangle<...>
>   smooth {angle 89}
> }

Well, I don't want to make these macros rely on a patch that isn't in 
MegaPOV and won't be in POV 3.5. Anyway, I think I have figured out a 
way to do it using the displacing pigment that would be even better than 
anything that could be done with the triangle data alone.

However, having "post processes" for meshes, things like subdivide, 
smooth, etc, is something that I've been thinking of for a while. 
Unfortunately, I can't even get a simple warping to work correctly...it 
appears that the mesh code was written for the mesh object, and only the 
mesh object, it isn't very friendly for other uses. Maybe there's 
something in Warp's tesselation patch that will be useful for this, 
though...

-- 
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