Warp wrote:
> 
> > Subdividing a mesh and displacing in normal direction is not camparable to
> > distorting an isosurface function
> 
>   Why not?
> 

For example subdividing a mesh can not generate surfaces separated from
the main object.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 03 Aug. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <3D518140.E58214B1@gmx.de>,
 Christoph Hormann <chr### [at] gmxde> wrote:

> For example subdividing a mesh can not generate surfaces separated from
> the main object.

That wouldn't exactly be subdividing, but it certainly is a process that 
could be done to a mesh.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote:
>> > no trouble with faceting
>> 
>>   He is using an image to create the heightfield...

> And what does that have to do with faceting?

  An image has a limited resolution and thus it will produce faceting.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote:
> It should be possible to get the desired effect using an intersection of 
> a height field and a box.

  Well, do I have to say more?-)

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Christopher James Huff wrote:
> 
> > For example subdividing a mesh can not generate surfaces separated from
> > the main object.
> 
> That wouldn't exactly be subdividing, but it certainly is a process that
> could be done to a mesh.

I don't think so (apart from tesselating the isosurface of course)

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 03 Aug. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

On Wed, 07 Aug 2002 15:03:21 -0500, Christopher James Huff
<chr### [at] maccom> wrote:

>It should be possible to get the desired effect using an intersection of 
>a height field and a box.

I know it _should_ and it works in some cases, but it doesn't always
work. The old trick used was to clip the HF with an open cylinder and
union it with the cylinder clipped by the HF. However, there's no open
box except for an open prism, and that produced artifacts that sturm
didn't fix. It didn't work with clipping or intersecting it with a
regular box either, nor with a semi-open box clipped by a plane.

Do you really think I am _that_ new to POV? :)

It just occurred to me I didn't try intersecting it with a mesh box.
Back to the drawing table.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

In article <3d518426@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

> > And what does that have to do with faceting?
> 
>   An image has a limited resolution and thus it will produce faceting.

Not on an isosurface. You might get a lumpy appearance from the 
interpolation, but not faceting. And that lumpy effect is preferable to 
black edges or faceting in some cases.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

In article <jp33lu4h4sf8knpgf3l3ltugem5shjpp0i@4ax.com>,
 Peter Popov <pet### [at] vipbg> wrote:

> I know it _should_ and it works in some cases, but it doesn't always
> work. The old trick used was to clip the HF with an open cylinder and
> union it with the cylinder clipped by the HF. However, there's no open
> box except for an open prism, and that produced artifacts that sturm
> didn't fix. It didn't work with clipping or intersecting it with a
> regular box either, nor with a semi-open box clipped by a plane.
> 
> Do you really think I am _that_ new to POV? :)
> 
> It just occurred to me I didn't try intersecting it with a mesh box.
> Back to the drawing table.

I said a box and I meant the built-in "box" primitive.

I just tried it and it works fine. Under what conditions doesn't it 
work? Are you making sure the box sides are "inside" the height field? 
The artifacts you describe sound like coincident surface problem, or the 
box surface being coincident with the height field in/out boundary. 
Either use a slightly smaller box or slightly larger height field.

I really wish you could just put "open false" in the height field 
block...maybe I'll code that up as a patch someday. It should really 
default to on, but having it off by default would preserve backwards 
compatibility.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

On Wed, 07 Aug 2002 20:19:08 -0500, Christopher James Huff
<chr### [at] maccom> wrote:

>I said a box and I meant the built-in "box" primitive.

Yes, first thing I tried.

>I just tried it and it works fine. Under what conditions doesn't it 
>work? 

When viewed from certain angles? Maybe when the look_at point is
inside the thing? I'll have to test this more comprehensively but I'm
currently using the computer for other things (yeah, real life :( )

>Are you making sure the box sides are "inside" the height field? 

Of course, although I tried it the other way around as well since it
shouldn't matter.

>The artifacts you describe sound like coincident surface problem, or the 
>box surface being coincident with the height field in/out boundary. 
>Either use a slightly smaller box or slightly larger height field.

The HF is scaled 1.1, should be more than enough.

>I really wish you could just put "open false" in the height field 
>block...maybe I'll code that up as a patch someday. It should really 
>default to on, but having it off by default would preserve backwards 
>compatibility.

Yes, I've wished for that as well. Kudos if you get it working.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

In article <8ik4luscie2tt0p7u7grroorrjghs0dkau@4ax.com>,
 Peter Popov <pet### [at] vipbg> wrote:

> >I just tried it and it works fine. Under what conditions doesn't it 
> >work? 
> 
> When viewed from certain angles? Maybe when the look_at point is
> inside the thing? I'll have to test this more comprehensively but I'm
> currently using the computer for other things (yeah, real life :( )

I suspect you mean "location", since look_at couldn't possibly cause the 
problem. That shouldn't matter...POV should only care what surfaces are 
in what volumes. I put the camera inside and it renders fine. "Certain 
angles" is a possibility that I can't duplicate, but I don't see any 
reason for it to happen. My tests work from above, from below, from the 
side, and from inside. Could you post the code you are using?


> >Are you making sure the box sides are "inside" the height field? 
> 
> Of course, although I tried it the other way around as well since it
> shouldn't matter.

No, it matters quite a bit. Since the height field doesn't have sides, 
POV can only check that the sides of the box are inside the height 
field. If they are outside, they are ignored with no height field 
surface to replace them.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message