 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann <chr### [at] gmx de> wrote:
> In POV-Ray the way to get interpolated normal vectors (or 'smooth
> shading' if you want so) is to specify the normals, This offers more
> control than simply specifying if an edge is sharp or smooth. If there
> is a mesh with some smooth triangles and some not the most convenient
> approach would be to only subdivide the smooth ones (which of course
> requires special handling of edges between smooth and flat triangles).
Note also that two smooth triangles might not share the same normal
vectors in their shared vertices. That is, the triangles are smooth, but
their common edge has a sharp change in lighting (which is often a useful
feature).
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
>
> Xiaobin Wu wrote:
> > First of all, thanks to all that responded or tested my patch.
> >
> > I have posted the modified source. There are five files modified:
> > tokenize.cpp, mesh.h, mesh.cpp, parse.h, parse.cpp
> > ( I want to thank Andrew for testing it under Linux. )
> > Also I wish the code is only used in Pov-Ray community.
>
> Thanks for the code, a first glance at the code revealed the following
> things:
>
> - you seem to discard any normal vectors specified for the mesh - this
> might often not be what the user wants and more important using the
> normal vectors could save you quite some computations (i.e. determining
> the neighbouring triangles).
And determining if the edge between two triangles is sharp or smooth,
which is very important for subdivision surfaces.
> - i can't find a reason why it should only work for mesh2 and not mesh.
Mesh2 allows you to explicitly specify that two triangles share their
corner vertices (instead of having different vertices that happen to be
identical).
Regards,
John
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>
>> About the computations, determining the neighboring triangles is needed
>> for subdivision. So it is a must anyways.
>
> That depends on the method used. Most methods for doing on-the-fly
> subdivision (which is an interesting feature for a raytracer BTW) do not
> use the neighbouring triangles.
>
I've implemented this in my own raytracer, the neighbouring triangles are
required to satisfy boundary conditions for subdivision, unless these
conditions are specified manually (which is rather awkward). The
implementation really is quite interesting, if you are interested check
out the paper:
http://www.seanet.com/~myandper/abstract/eg03.htm
Andrew
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>
> I've implemented this in my own raytracer, the neighbouring triangles are
> required to satisfy boundary conditions for subdivision, unless these
> conditions are specified manually (which is rather awkward). The
> implementation really is quite interesting, if you are interested check
> out the paper:
> http://www.seanet.com/~myandper/abstract/eg03.htm
>
> Andrew
Sorry, A more relevant paper is:
http://portal.acm.org/citation.cfm?id=344829&dl=ACM&coll=portal
Although both these are highly relevant to a raytracing implementation of
subdivision and displacement mapping.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Some improvements have been made to
the blender export script for povray,
so now you can export mesh for pov-sub too,
and test complex material mixing:
http://jmsoler.free.fr/util/blenderfile/povanim_patch4.htm
Regards.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This is wonderful. Thanks.
<nomail@nomail> wrote in message
news:web.40a517e4156ced50ba91e9880@news.povray.org...
> Some improvements have been made to
> the blender export script for povray,
> so now you can export mesh for pov-sub too,
> and test complex material mixing:
>
> http://jmsoler.free.fr/util/blenderfile/povanim_patch4.htm
>
> Regards.
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"John VanSickle" <evi### [at] hotmailcom> wrote in message
news:40A40E63.5DDEA331@hotmail.com...
> Christoph Hormann wrote:
> >
> > - you seem to discard any normal vectors specified for the mesh - this
> > might often not be what the user wants and more important using the
> > normal vectors could save you quite some computations (i.e. determining
> > the neighbouring triangles).
>
> And determining if the edge between two triangles is sharp or smooth,
> which is very important for subdivision surfaces.
Crease edges are important. I am considering to use the Pixar's semi-crease
rule.
So you can specify an integer on an edge which indicates "how" smooth
it is. 0 means smooth, infinity means sharp and integers in between will
create semi-sharp ridges. The syntax will look like
crease_edge_list {
v1 v2 crs_value
...
}
Reference: Subdivision surfaces in character animation, by Tony DeRose, etc.
I found this practically essential and relatively easy to use. Also this way
the
manual normals can be saved for bump mapping purposes. (i.e. smooth
geometry with artrificial normals on it)
> Mesh2 allows you to explicitly specify that two triangles share their
> corner vertices (instead of having different vertices that happen to be
> identical).
Exactly.
Xiaobin
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
> Note also that two smooth triangles might not share the same normal
> vectors in their shared vertices. That is, the triangles are smooth, but
> their common edge has a sharp change in lighting (which is often a useful
> feature).
I have this in mind. Thanks. I called it bump mapping or artificial normals,
which shouldn't affect the shape.
I remember one of the nicest example is a coin modeled by a simple
cylinder but with artificial normals on its sides. Since its sihouette is
always from the cylinder, you can never tell its sides are actually flat!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <40a593f3@news.povray.org>, "Xiaobin Wu" <xwu### [at] ciseufledu>
wrote:
> "Warp" <war### [at] tagpovrayorg> wrote in message
> > Note also that two smooth triangles might not share the same normal
> > vectors in their shared vertices. That is, the triangles are smooth, but
> > their common edge has a sharp change in lighting (which is often a useful
> > feature).
>
> I have this in mind. Thanks. I called it bump mapping or artificial normals,
> which shouldn't affect the shape.
I don't think you quite understood. For example, think of a deformed
box. It has edges that should not be smoothed out, but which are actual
geometry, not faked by tweaking the normals.
> I remember one of the nicest example is a coin modeled by a simple
> cylinder but with artificial normals on its sides. Since its sihouette is
> always from the cylinder, you can never tell its sides are actually flat!
I'm not sure what this has to do with subdivision...normal perturbation
in POV is specified as part of the texture. Some objects will return
"false" normals...smooth triangles, smoothed height fields, etc.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christopher James Huff" <cja### [at] earthlinknet> wrote in message
news:cjameshuff-2CC397.15040617052004@news.povray.org...
> In article <40a593f3@news.povray.org>, "Xiaobin Wu" <xwu### [at] ciseufledu>
> wrote:
>
>
> I don't think you quite understood. For example, think of a deformed
> box. It has edges that should not be smoothed out, but which are actual
> geometry, not faked by tweaking the normals.
OK. Here are the two cases:
1. Smooth geometry, non-smooth normals. (Bump mapping)
2. Non-smooth geometry, non-smooth normals. (sharp creases)
Now with another look at warp's post, I am not that sure which case he was
referring to.
It could well be either one.
If only the second case is concerned, one could automatically determine the
crease edge
from the normal directions (which is simple). But I am ambitious to support
both cases, as well as "semi-sharp" creases. They seem useful to me in
practice.
Xiaobin
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
