Re: [openvrml-develop] Re: Problems with normal vectors beeing not normalized

[Braden M. <br...@en...>]

On Wed, 2006-02-01 at 21:31 +0100, Michael Sögtrop wrote:
> Hi Braden,
> 
> > >  Are such per
> > > face normal vectors calculated somewhere?
> > 
> > No. Nor is it obvious to me that they should be. I don't 
> > understand why per-vertex normal generation wouldn't satisfy 
> > your requirement. (But then, perhaps I don't understand the 
> > visual effect you're looking for.) 
> G
> My problem is that the complete modell looks pefect, except very
> simple flat faces (e.g. a ball looks ok, but a simple flat cube looks
> wrong). Because the faces are flat, there are no normals given for the
> vertices of these faces in the VRML file, because they are redundant
> for flat faces.

They're only redundant if the runtime can be relied upon to generate
desirable ones. I do not mean to excuse OpenVRML's failure to make any
attempt to generate normals--clearly it should; however, not specifying
them in the model *is* deferring to the particulars of an
implementation.

>  It should be this case:
> 
> > If the normal field is NULL, the
> > browser shall automatically generate normals, using creaseAngle
> > to determine if and how normals are smoothed across shared
> > vertices (see 4.6.3.5, Crease angle field).

Right. The spec doesn't say whether the generated normals should be
per-vertex or per-face. The comment in OpenVRML assumes that they would
be generated per-vertex.

I'm no expert on normal generation; but it's my impression that, in
general, per-vertex normals are preferred as they yield better shading.

> The normals are not smoothed (the face is rendered with flat color as
> it should be) but the normal vector is not normalized.

"Not normalized"? I don't know what you mean by that. "Not normalized"
generally means that the components haven't been adjusted to be
proportional to 1. But the case here is that OpenVRML isn't supplying
OpenGL with normals because it hasn't generated them.

> Shall I just send a screenshot?

It would be better to file a bug on SourceForge and attach a screenshot
there. Note that there is already a task related to this:

        <http://sourceforge.net/pm/task.php?func=detailtask&project_task_id=24101&group_id=7151&group_project_id=2579>

But you can't attach files to tasks; so we can have a bug, too.

What I'm trying to get from you, though, is an explanation of why
implementing per-vertex normal generation wouldn't solve your problem. I
think it would. You seem to be asking for different code paths for
normal generation depending on the value of normalPerVertex. The VRML97
spec doesn't appear to require that. Nonetheless, if there's a
compelling case for it, it could be added.

-- 
Braden McDaniel                           e-mail: <br...@en...>
<http://endoframe.com>                    Jabber: <br...@ja...>