 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
(1) The docs suggest that normal indices are optional. I just took a
working mesh, added *only* a normal_vectors section, and got an error
message about missing normal_indices.
(2) IMHO, you should build a complete, non-optimized mesh with all its
components (i.e., normal_indices) before optimizing it. The way it's
done in the docs leaves me totally confused as to what a normal_indices is.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:3e105c2d$1@news.povray.org Greg M. Johnson wrote:
> (1) The docs suggest that normal indices are optional. I just took
> a working mesh, added *only* a normal_vectors section, and got an
> error message about missing normal_indices.
You can only do without normal_indices if the amount of vertices and
normals is the same, as shown in the first example in "3.5.2.1 Smooth
triangles and mesh2"
> (2) IMHO, you should build a complete, non-optimized mesh with all
> its components (i.e., normal_indices) before optimizing it. The
> way it's done in the docs leaves me totally confused as to what a
> normal_indices is.
The use of normal_indices is exactly the same as the use of
face_indices, with one exception: a mesh2 with mix of flat and smooth
triangles.
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
My point (1) is due to a bug in my algo.
My point (2) is still there [albeit perhaps not a gaping hole in the docs]
as I'm confused: my mesh2 looks really wierd with the normals I invented: it
looks much better without them!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in news:3e110f57$1@news.povray.org Greg M. Johnson wrote:
> [...] my mesh2 looks really wierd with the normals I invented: it
> looks much better without them!
>
You shoudn't 'invent' them but calculate them ;)
Ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
ingo <ing### [at] tag povrayorg> wrote:
> You shoudn't 'invent' them but calculate them ;)
It's not mandatory to calculate them. You can create them manually as
well.
Usually calculating them automatically is easier, though.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm making a mesh2 version of a sphere sweep. At multiple segments along
the cubic spline, I'm building a mesh2 at a given radius from the spline and
normal to its tangent. In this case (think a simple cylinder), would the
normals be equivalent to the vertex points themselves?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Greg M. Johnson <gregj:-)565### [at] aolcom> wrote:
> I'm making a mesh2 version of a sphere sweep. At multiple segments along
> the cubic spline, I'm building a mesh2 at a given radius from the spline and
> normal to its tangent. In this case (think a simple cylinder), would the
> normals be equivalent to the vertex points themselves?
Normal vectors should always be perpendicular to the surface the mesh
is approximating.
In your case, when you are approximating a sphere sweep with a mesh,
the vertex points should be located where the surface of the sphere
sweep would be (if it was there), and the normal vector at a certain
vertex point should be perpendicular to the surface of the sphere sweep
at that point, pointing outwards.
That is, if you created a cylinder for each vertex point so that one
end of the cylinder is at the vertex point and the other end of the cylinder
is at the vertex point + the normal vector, you would get "spikes" on the
surface of the sphere sweep, which are perpendicular to this surface.
--
#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
|
|
| |
| |
|
|
|
|
| |
