 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I need some help with generating terrain with isosurfaces. Render
times are intolerably slow! I am getting a max_gradient of over 25000,
which is too high IMHO. The function in question is:
#declare F_Relief = function {
pigment {
image_map { tga "relief.tga" interpolate 2 }
rotate 90*x
}
}
#declare F_Terrain = function { y - F_Relief(x,y,z).gray }
Any idea why the max gradient would be that high? I ended up making a
mesh out of the tga in Rhino instead, but I want to learn to do this
right.
Any help will be greatly appreciated.
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vip bg
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Peter Popov <pet### [at] vipbg> wrote in
news:0u5tkuoupvgafcrgfurg3g7a5btgo3sh9q@4ax.com
> I need some help with generating terrain with isosurfaces. Render
> times are intolerably slow! I am getting a max_gradient of over 25000,
> which is too high IMHO. The function in question is:
1. maybe try bluring HF map ?
2. mabye there is problem with reding this map, i.e. if it was a 16-bit
gray, *maybe* it can lead to strange results.
btw, it's a greate example for my iso-optimization future ;)
--
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5 Aug 2002 11:34:13 -0400, "Rafal 'Raf256' Maj" <raf### [at] raf256com>
wrote:
>1. maybe try bluring HF map ?
I want the detail - I didn't spent two hours generating a
high-resolution terrain in World Machine just to kill it with a 20
pixel gaussian blur :)
>2. mabye there is problem with reding this map, i.e. if it was a 16-bit
>gray, *maybe* it can lead to strange results.
I don't think so - it reads just fine as a height field or image map.
>btw, it's a greate example for my iso-optimization future ;)
Looking forward to it (with a grain of salt, if you don't mind)
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Peter Popov <pet### [at] vipbg> wrote in
news:fk7tkus0s3vikru6khhkja2j97diatip1a@4ax.com
> I don't think so - it reads just fine as a height field or image map.
>>btw, it's a greate example for my iso-optimization future ;)
> Looking forward to it (with a grain of salt, if you don't mind)
well - now I'm just going to simulate this patch, because I don't like
modyfing not my C code, especialy as huge as Pov's :)
patch coded into POV probalby willbe ready in 1..6 months (imho)
You may try to simulate it now - divide iso into several small iso's in
union. Then, if You are lucky - some small iso's will have low
max_gradient, and only few fragmeents will need high max_gradient.
But, if You have meany spikes all over the map - it will not help :/
send to me scene + .png (mailto:pov### [at] raf256com) maybe I can help
other idea is ofcourse to use standart HF.
Or maybe - bound ISO with HF (maybe scalled a litle)
--
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Peter Popov wrote:
>
> #declare F_Relief = function {
> pigment {
> image_map { tga "relief.tga" interpolate 2 }
> rotate 90*x
> }
> }
>
> #declare F_Terrain = function { y - F_Relief(x,y,z).gray }
>
> Any idea why the max gradient would be that high? I ended up making a
> mesh out of the tga in Rhino instead, but I want to learn to do this
> right.
Try 'interpolate 4'. IIRC interpolate 2 does not lead to a continuous
function, therefore the high gradient.
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 Mon, 05 Aug 2002 18:09:05 +0200, Christoph Hormann
<chr### [at] gmxde> wrote:
>Try 'interpolate 4'. IIRC interpolate 2 does not lead to a continuous
>function, therefore the high gradient.
*slam*
/me stupid :( I completely forgot about that.
Thanks, I'll try that (for the sake of the experiment).
Now, any idea about some sane RMF parameters? I'm aiming towards a
water look.
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Peter Popov wrote:
>
> [...]
>
> Now, any idea about some sane RMF parameters? I'm aiming towards a
> water look.
>
Searching the newsgroups for 'f_ridged_mf or ridgedMF' finds:
Subject: Re: iso - ridged mf question
Date: Mon, 12 Mar 2001 19:35:40 +0200
Newsgroups: povray.unofficial.patches
From: Vahur Krouverk <vah### [at] aetecee>
news://news.povray.org/3AAD08EC.ED0A6178@aetec.ee
http://news.povray.org/3AAD08EC.ED0A6178@aetec.ee
Subject: How high? - Iso question
Date: Thu, 12 Apr 2001 15:12:37 +0100
Newsgroups: povray.unofficial.patches
From: "Tom Melly" <tom### [at] tomandlucouk>
news://news.povray.org/3ad5b7d6@news.povray.org
http://news.povray.org/3ad5b7d6@news.povray.org
Subject: water tunnel water source
Date: Mon, 30 Apr 2001 08:43:27 +0200
Newsgroups: povray.text.scene-files
From: Christoph Hormann <chr### [at] gmxde>
news://news.povray.org/3AED098F.811CBF30@gmx.de
http://news.povray.org/3AED098F.811CBF30@gmx.de
Subject: RidgedMF clouds
Date: Tue, 20 Jun 2000 22:26:11 -0700
Newsgroups: povray.text.scene-files
From: SamuelT <STB### [at] aolcom>
news://news.povray.org/395051F3.13CA5AB5@aol.com
http://news.povray.org/395051F3.13CA5AB5@aol.com
Subject: Re: ridgedMF-Mountain - params?
Date: Thu, 3 Aug 2000 14:34:55 +0200
Newsgroups: povray.newusers
From: "Marc-Hendrik Bremer" <Mar### [at] t-onlinede>
news://news.povray.org/39896757@news.povray.org
http://news.povray.org/39896757@news.povray.org
Subject: Isowater
Date: Sun, 5 Nov 2000 14:37:40 -0000
Newsgroups: povray.text.scene-files
From: "Kevin Ellis" <kev### [at] libertysurfcouk>
news://news.povray.org/3a0570b4@news.povray.org
http://news.povray.org/3a0570b4@news.povray.org
Subject: ridged multifractal w. slope-dependent texture
Date: Thu, 18 Jan 2001 04:18:47 -0600
Newsgroups: povray.text.scene-files
From: "Bob H."
<per### [at] aolcom?subject=PoV-News:%20&body=Relating%20to%20POV-Ray:>
news://news.povray.org/3a66c2b7@news.povray.org
http://news.povray.org/3a66c2b7@news.povray.org
And maybe try:
http://www-public.tu-bs.de:8080/~y0013390/pov/rmf.html
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Try 'interpolate 4'. IIRC interpolate 2 does not lead to a continuous
> function, therefore the high gradient.
interpolate 2 does lead to a continuous function. It doesn't have a
continuous derivative, but it is continuous, so there should be no infinite
max gadient.
Perhaps the high gradient is appearing at the very edge of the image? Check
that your isosurface's contained_by box doesn't exceed the edges of the
image.
Seeing the code may help, also... and perhaps the image too if that doesn't.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime wrote:
>
> > Try 'interpolate 4'. IIRC interpolate 2 does not lead to a continuous
> > function, therefore the high gradient.
>
> interpolate 2 does lead to a continuous function. It doesn't have a
> continuous derivative, but it is continuous, so there should be no infinite
> max gadient.
Do you write this because you have used 'interpolate 2' a lot with
isosurfaces and had no problems or because you *think* it has to be
continuous. At least the last time i tested (some beta version of 3.5)
'interpolate 2' did not lead to usable results.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Of course this raises the question why do you want to use an isosurface
to create a heightfield at all?
The only thing I can think of is that you want to use non-linear
transformations on the heightfield. Creating a mesh instead of an isosurface
will lead to enormously faster render times, and you can move the vertex
points at will, which simulates non-linear transformations.
I think there are macros in the official distribution for this (I don't
remember if they allow transformations, but if they don't, you can make
your own version of the macro with vertex transformations).
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3d503959@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> Of course this raises the question why do you want to use an isosurface
> to create a heightfield at all?
> The only thing I can think of is that you want to use non-linear
> transformations on the heightfield. Creating a mesh instead of an isosurface
> will lead to enormously faster render times, and you can move the vertex
> points at will, which simulates non-linear transformations.
Less memory, no trouble with faceting or other triangle problems.
> I think there are macros in the official distribution for this (I don't
> remember if they allow transformations, but if they don't, you can make
> your own version of the macro with vertex transformations).
There are height field generator macros, they don't really have any
advantage over the height_field primitive except that there are
cylinderical and spherical versions available. (and I like the smoothing
better)
You still have the "no overhangs" restriction, for example. However, the
code is there, so you could modify it to do whatever you want.
--
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...
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> Of course this raises the question why do you want to use an isosurface
> to create a heightfield at all?
Using image maps in isosurfaces can be very useful if you want to add a
fine structure to a rough geometry defined by an image.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann <chr### [at] gmxde> wrote:
> Using image maps in isosurfaces can be very useful if you want to add a
> fine structure to a rough geometry defined by an image.
You could do that with a mesh as well, and get a much faster rendering. :)
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> > Using image maps in isosurfaces can be very useful if you want to add a
> > fine structure to a rough geometry defined by an image.
>
> You could do that with a mesh as well, and get a much faster rendering. :)
>
That's quite difficult and it would take incredible amounts of memory.
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 6 Aug 2002 17:02:17 -0400, Warp <war### [at] tagpovrayorg> wrote:
> Of course this raises the question why do you want to use an isosurface
>to create a heightfield at all?
Because I want to have the sides of the HF as well. I spent a whole
afternoon trying to resurrect the old HF clipping trick that I used so
often in the past, but I just can't get it to work anymore.
The render times are not impossible with a 16-bit grayscale PNG image
as a source and interpolate 4. The render time for my last picture was
just over 16 hours with two such isosurfaces, one of them refractive
and filled with media, and nested in a refractive CSG object, and well
over 5000000 photons. 16hr is not that bad for such a monster,
especially on a puny computer like my 400 MHz K6.
I ditched the idea and used a ridged multifractal function instead,
just because I couldn't make the HF I wanted in WorldMachine.
Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG e-mail : pet### [at] tagpovrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann <chr### [at] gmxde> wrote:
> That's quite difficult and it would take incredible amounts of memory.
Subdividing a mesh is not difficult at all, and it does not take
"incredible amounts of memory", just the extra memory needed for the
extra vertex points and triangles.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Peter Popov <pet### [at] vipbg> wrote:
> Because I want to have the sides of the HF as well.
Sorry, but I didn't understand this.
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
>
> [...]
>
> Subdividing a mesh is not difficult at all, and it does not take
> "incredible amounts of memory", just the extra memory needed for the
> extra vertex points and triangles.
>
Subdividing a mesh and displacing in normal direction is not camparable to
distorting an isosurface function and it can take enormeous amounts of
memory to generate a mesh of such a resolution.
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 <3d5084d3@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> 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?
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann <chr### [at] gmxde> wrote:
> Subdividing a mesh and displacing in normal direction is not camparable to
> distorting an isosurface function
Why not?
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3d516e82@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> > Because I want to have the sides of the HF as well.
>
> Sorry, but I didn't understand this.
The sides of the POV height_field primitive are open, it is just a
sheet. He wants them to be closed, something that I've wanted before too.
It should be possible to get the desired effect using an intersection of
a height field and a box.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
