On 22 Jan 2002 12:14:13 -0500, Warp <war### [at] tagpovrayorg> wrote:

> It's not actually a heightfield bug. It's a more general phenomenon. If the
> angle between the normal vector returned by the object (any object) and the
> incoming ray is <90 degrees, then the normal vector is inverted.
> The normal vector of this smooth triangle points always upwards, never
> downwards, and thus it should never get colored red. But the inversion
> phenomenon of the normal causes the artifact.

I can be completly offtopic but could be normal determined by order of vertices
in triangle?

ABX

Post a reply to this message

<abx### [at] babilonorg> wrote:

>I can be completly offtopic but could be normal determined by order of vertices
>in triangle?

Then the renderer would have to trust that the order is correct, and
that is the task of either the export utility or the scene that
generates it. In any case the user shouldn't be doing the renderer's
job.


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

Post a reply to this message

On Thu, 24 Jan 2002 14:21:17 +0200, Peter Popov <pet### [at] vipbg> wrote:
> > I can be completly offtopic but could be normal determined by order of vertices
> > in triangle?
>
> Then the renderer would have to trust that the order is correct

not exactly
I proposed this becouse I always generate meshes from triangles builded in one
direction (ok, almost always). I helps me a lot in generating smooth normals.
Old behaviour could be supported just with #version 3.1; afaik there is no
export utylity for 3.5 so I suppose all utilities adds #version to exported
scripts.

> In any case the user shouldn't be doing the renderer's job.

But renderer can't decide as I understand.

ABX

Post a reply to this message

: I can be completly offtopic but could be normal determined by order of vertices
: in triangle?

  I didn't understand this.

  The problem is not determining the normal. The problem is just that if
the angle between the incoming ray and the normal vector returned by the
object have an angle <90 degrees, the normal is inverted.
  This works just fine in most cases (and it has to be done this way). The
only problem happens with smooth triangles and smooth heightfields in certain
cases.
  As for lighting, this problem goes away by making the object
double-illuminated (because then it doesn't matter which way the normal
is pointing). However, as for the slope pattern, the solution is not so simple
(double_illuminate is used only for lighting and can't be used for slope
pattern calculation).

  By the way: In a heightfield the problem with the slope y pattern goes
away if you "mirror" the color_map around 0.5 (of course it doesn't work if
the slope is anything else than y), besides making the heightfield
double-illuminated.
  With smooth meshes which use the slope pattern there's no currently fix,
AFAIK.

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

On 24 Jan 2002 07:51:51 -0500, Warp <war### [at] tagpovrayorg> wrote:
> The problem is not determining the normal. The problem is just that if
> the angle between the incoming ray and the normal vector returned by the
> object have an angle <90 degrees, the normal is inverted.

I see, sorry then.

ABX

Post a reply to this message

> I can be completly offtopic but could be normal determined by order of vertices
> in triangle?

From memory:
In 3.1 code, the short answer is NO, at least for mesh, 
because the mesh code is free to reorder the vertices of any single triangle.(*)
So even if you carefully generate all your triangles with a +side and -side, 
once in the mesh structure it might be impossible to get back to the original
order. It's often simpler to use a smooth_triangle which allow to explicitely
specify a normal for each vertex (but take more memory, of course).

(*) and it does it, according to its own private criteria.
-- 
Non Sine Numine
http://grimbert.cjb.net/

Post a reply to this message

<abx### [at] babilonorg> wrote:

>not exactly
>I proposed this becouse I always generate meshes from triangles builded in one
>direction (ok, almost always).

Yes, but that's you. You're not the average Joe User.

>But renderer can't decide as I understand.

Yet :)


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

Post a reply to this message

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

> Then the renderer would have to trust that the order is correct, and
> that is the task of either the export utility or the scene that
> generates it. In any case the user shouldn't be doing the renderer's
> job.

No. There is no way for the renderer to reliably determine the correct 
normal, and such a mechanism would break many meshes that use the 
winding to determine it. It normally isn't a problem anyway, since POV 
renders both sides of the triangle.
And it isn't related to the height field problem, which has more to do 
with the interpolation of smooth triangle normals.

-- 
 -- 
Christopher James Huff <chr### [at] maccom>

Post a reply to this message

In article <3C501EB7.263F96C0@atosorigin.com>,


> In 3.1 code, the short answer is NO, at least for mesh, 
> because the mesh code is free to reorder the vertices of any single 
> triangle.(*)
> So even if you carefully generate all your triangles with a +side and -side, 
> once in the mesh structure it might be impossible to get back to the original
> order. It's often simpler to use a smooth_triangle which allow to explicitely
> specify a normal for each vertex (but take more memory, of course).

Not true. The mesh stores the vertex *vectors* separately, the triangles 
then refer to that list. The triangles still know what order the 
vertices are in.

Proof? Use interior_texture on a mesh. The height-field macros make good 
examples...

-- 
 -- 
Christopher James Huff <chr### [at] maccom>

Post a reply to this message

"Christopher James Huff" wrote:
> Proof? Use interior_texture on a mesh. The height-field
> macros make good examples...

And after I fixed the height-field macros you even get the interior texture
on the *inside*, contrary to how it was before... ;)

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Jan 20)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message