openvrml-develop

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

[<MSo...@ya...>]

Hi Braden,

I just found that all faces that are completely flat and do not have a
normal vector given with them (at least those with more than 3
corners) seem to be affected by this problem. E.g.:

geometry IndexedFaceSet {
solid FALSE
coord Coordinate {
	point	[
		 240 1202.43 935,
		 240 1200 935,
		 240 1129.8 924.729,
		 240 1065.49 894.776,
		 240 139.996 286.866,
		 240 73.0611 255.691,
		 240 0 245,
		 240 -56.4157 245,
		 240 15.1684 273.006,
		 240 124.899 309.851,
		 240 1050.4 917.761,
		 240 1121.92 951.076,
		 240 1200 962.5,
		 240 1202.43 962.5,
		]
	}
coordIndex [
 5,9,6,-1,
 9,8,6,-1,
 6,8,7,-1,
 0,13,1,-1,
 13,12,1,-1,
 1,12,2,-1,
 12,11,2,-1,
 2,11,3,-1,
 11,10,3,-1,
 3,10,4,-1,
 10,9,4,-1,
 4,9,5,-1,
]

Can you point me to the code where the normals for such things are
calculated?

Best regards,

Michael

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.14.23/243 - Release Date:
27.01.2006
 


	

	
		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

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

[<MSo...@ya...>]

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

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

The normals are not smoothed (the face is rendered with flat color as
it should be) but the normal vector is not normalized. Shall I just
send a screenshot?

Best regards,

Michael

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.15.0/248 - Release Date:
01.02.2006
 


	

	
		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

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

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

[<MSo...@ya...>]

Hi Braden,

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

OpenVRML creates the right normal vectors in this case. The only
problem with these normal vectors is, that their length is not 1, as
it should be for a normal vector. Most shaders go wild if you supply
unnormalized normal vectors. If I tell OpenGL to normalize all normal
vectors (that is to keep their directions but to devide them by their
length) the model looks perfect. But normalizing all normal vectors is
a time consuming operations, because it requires calculating a square
root and a division for every normal vector. Since 99.99% of all
normal vectors already have a length of 1, this would be quite a waste
of computation time.

Best regards,

Michael

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.15.1/250 - Release Date:
03.02.2006
 


	

	
		
___________________________________________________________ 
Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de

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

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

On Sat, 2006-02-04 at 11:49 +0100, Michael Sögtrop wrote:

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

Okay. I think I finally found it. :-)

insertShellConvex calls indexFaceNormal, which is where the normal
generation happens.

I've just checked in a change to normalize the vec3f returned by
indexFaceNormal. Does this fix the problem?

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

[openvrml-develop] UNSBUSCRIBE

[Nuli I. <nu...@ev...>]

UNSUBSCRIBE

Michael Sögtrop wrote:

>Hi Braden,
>
>I just found that all faces that are completely flat and do not have a
>normal vector given with them (at least those with more than 3
>corners) seem to be affected by this problem. E.g.:
>
>geometry IndexedFaceSet {
>solid FALSE
>coord Coordinate {
>	point	[
>		 240 1202.43 935,
>		 240 1200 935,
>		 240 1129.8 924.729,
>		 240 1065.49 894.776,
>		 240 139.996 286.866,
>		 240 73.0611 255.691,
>		 240 0 245,
>		 240 -56.4157 245,
>		 240 15.1684 273.006,
>		 240 124.899 309.851,
>		 240 1050.4 917.761,
>		 240 1121.92 951.076,
>		 240 1200 962.5,
>		 240 1202.43 962.5,
>		]
>	}
>coordIndex [
> 5,9,6,-1,
> 9,8,6,-1,
> 6,8,7,-1,
> 0,13,1,-1,
> 13,12,1,-1,
> 1,12,2,-1,
> 12,11,2,-1,
> 2,11,3,-1,
> 11,10,3,-1,
> 3,10,4,-1,
> 10,9,4,-1,
> 4,9,5,-1,
>]
>
>Can you point me to the code where the normals for such things are
>calculated?
>
>Best regards,
>
>Michael
>
>  
>

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

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

On Sat, 2006-01-28 at 15:57 +0100, Michael Sögtrop wrote:
> Hi Braden,
> 
> I just found that all faces that are completely flat and do not have a
> normal vector given with them (at least those with more than 3
> corners) seem to be affected by this problem. E.g.:

[snip]

> Can you point me to the code where the normals for such things are
> calculated?

I think the problem is that they aren't.

openvrml::gl::viewer::insert_shell has a comment in it noting that
per-vertex normal generation is not implemented.

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