Hi all.

Well, this is an idea that I had, is about the meshes, I was thinking, the
smooth triangle have a simulated normal that seems to be smooth, but it
isn't. This simulation even cause an artifact, then ¿why not make a
smooth_triangle really smoothed?, if the syntax of the smooth_triangle is
conserved we can use the new shape with old mesh objects without problem,
but with better quality.

This object have another characteristics, for example, the amount of
triangles needed to create a model are very few, compared with the normal
mesh, this is because the mesh is an aproximation of the real model, you
need a lot of triangles to seem to be a curve, in this case, it is a curve,
and you save a lot of triangles, this allow you make your models even
manually, with a good quality, and it also save allocation memory and disk
space, this is good if you want to share your models in internet, for
example.

There are another object similar, the bicubic patch, but it is too difficult
to use manually, and is difficult to transform a mesh model into bicubic
patchs, that's the reason of the idea of a mesh-like object.

¿What do you think about this?


Fernando Correa.

excuse my english.

Post a reply to this message

Majukatur <maj### [at] hotmailcom> wrote:
> Well, this is an idea that I had, is about the meshes, I was thinking, the
> smooth triangle have a simulated normal that seems to be smooth, but it
> isn't. This simulation even cause an artifact, then ¿why not make a
> smooth_triangle really smoothed?

  How? By subdividing it into more triangles?

> There are another object similar, the bicubic patch, but it is too difficult
> to use manually

  You are implicating that writing meshes manually is not difficult. I would
like to see you writing a bigger mesh by hand. ;)

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

Warp wrote:
>   You are implicating that writing meshes manually is
> not difficult. I would like to see you writing a bigger
> mesh by hand. ;)

Well, bicubic patches are just plain difficult to use in general.
Because of their four corners, it's very difficult to make advanced
shapes where the patches are joined up smoothly. Some 3d programs which
also use patch-like shapes come about this problem by offering special
patches with 3 or 5 corners to supplement the regular ones with 4
corners. Not POV-Ray though.

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

Post a reply to this message

...

Majukatur <maj### [at] hotmailcom> wrote:
> Well, this is an idea that I had, is about the meshes, I was thinking, the
> smooth triangle have a simulated normal that seems to be smooth, but it
> isn't. This simulation even cause an artifact, then ¿why not make a
> smooth_triangle really smoothed?

  How? By subdividing it into more triangles?

> There are another object similar, the bicubic patch, but it is too
difficult
> to use manually

  You are implicating that writing meshes manually is not difficult. I would
like to see you writing a bigger mesh by hand. ;)


Well, this object not is a mesh of triangles, is a curve defined by 3 points
and its normal vectors, it is not an aproximation. There is an equation that
have all this characteristics, not is a mesh of triangles, is a mesh of
patchs, and it is easy to write this kind of meshes MANUALLY, for example,
you need only 4 "triangles" to describe an sphere, with normal meshes you
need hundreds of triangles. For describe ANY ellipse you need only 12
"triangles".

Imagine this, cut a sphere in 3 equal areas, each of this areas is the shape
of one of these "triangles", is defined by 3 points and 3 normal vectors, of
course, this is not a triangle, but you can use it like one.

If you want to use a modeler, like Rhinoceros for example, you can use very
few triangles in your model (when you export it to POV syntax) without any
lost of quality, it allow you to share your model because the file is too
small.

Well, I'm looking for the equation (formula) that describes this shape, I
know that is difficult to imagine, I need to prepare a better description of
this in order to explain my idea. May be a image can show you what I am
talking about, I'm going to prepare one.

Thanks for your attention



Fernando Correa

excuse my english

Post a reply to this message

In article <3d2bca3e$1@news.povray.org> , "Majukatur" 
<maj### [at] hotmailcom> wrote:

> Well, this object not is a mesh of triangles, is a curve defined by 3 points
> and its normal vectors, it is not an aproximation. There is an equation that
> have all this characteristics, not is a mesh of triangles, is a mesh of
> patchs, and it is easy to write this kind of meshes MANUALLY, for example,
> you need only 4 "triangles" to describe an sphere, with normal meshes you
> need hundreds of triangles. For describe ANY ellipse you need only 12
> "triangles".

Why build a sphere out of triangles if you can just use the sphere object in
POV-Ray?  Sounds like reinventing the wheel to me...

    Thorsten

Post a reply to this message

By the way, I strongly suggest that you either use the actual reply
functionality of your newsreader or configure it to quote articles properly.
In that format it's extremely difficult to see what is a quote and what is
a reply.

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

In article <3d2b4e76@news.povray.org>,
 "Majukatur" <maj### [at] hotmailcom> wrote:

> Well, this is an idea that I had, is about the meshes, I was thinking, the
> smooth triangle have a simulated normal that seems to be smooth, but it
> isn't. This simulation even cause an artifact, then ¿why not make a
> smooth_triangle really smoothed?, if the syntax of the smooth_triangle is
> conserved we can use the new shape with old mesh objects without problem,
> but with better quality.

There have been a couple people working on macros to produce "curved" 
smooth triangles. The only good way to do that seems to be to divide 
each triangle into more triangles on a curved surface...trying to solve 
directly for the surface would probably be too slow for a mesh with a 
fair number of triangles. Their macros are probably in the scene file 
groups on this server. You might also want to look for information on 
subdivision surfaces.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

Thorsten Froehlich wrote:
> 
> In article <3d2bca3e$1@news.povray.org> , "Majukatur"
> <maj### [at] hotmailcom> wrote:
> 
> > Well, this object not is a mesh of triangles, is a curve defined by 3 points
> > and its normal vectors, it is not an aproximation. There is an equation that
> > have all this characteristics, not is a mesh of triangles, is a mesh of
> > patchs, and it is easy to write this kind of meshes MANUALLY, for example,
> > you need only 4 "triangles" to describe an sphere, with normal meshes you
> > need hundreds of triangles. For describe ANY ellipse you need only 12
> > "triangles".
> 
> Why build a sphere out of triangles if you can just use the sphere object in
> POV-Ray?  Sounds like reinventing the wheel to me...
> 
>     Thorsten

By 3 points and 3 normals (only direction, with the same constraints that
is now on smooth_triangle (normals go to the same side)), how many spheres go through
?
If you are lucky, one; else none.
Problem is that most of the time, you will be unlucky (at least due to computational
errors but not only). 
This is because the center of the sphere should be at the intersection
of the three lines made by the normals and points. and there is no reason for theses
lines to intersect, even two by two. There is in fact no reason that two of them be
in any common plane.

Another approach with a sphere might be to use a mapping from the first point&normal
to always be a well know point on the sphere (such as the intersection of x axis with
the unit sphere) and then, using only the normals informations, placing the second and
third points of a geodesic triangle (additional contrainte for the second point should
be added also, so that it lies in the xOy plane for instance).
Then you will need to compute a transformation matrix (3 points give 3 points, so that
should be easy) and perform the intersection test against the geodesic triangle on
the unit sphere (as well as the normal computation).

Problems are:
Any two normals should not even be parallel (whereas currently it is possible with
smooth_triangle)
The three normals must ABSOLUTELY define a free base of 3D space 
And of course, the triangle must not be degenerated (or flat)

So it's not that easy to do by hand! At least the parser must be very strict.

Additional caveat: 
- the matrix found may be dependent on the order of the points,
which might end up that an ABC triangle is not identical to a ACB, 
or even a BCA triangle!!! [I need a mathematician here !!]
- Computation of the intersection with the geodesic triangle is not
straight ahead. The third point has far too much freedom, from a programmer
point of view! The hit on the sphere is easy (copy&paste from current sphere object)
but then the only hope I could see is to express the normal in the base of the 
three triangle normales, if any coefficient is negative, it's outside of the geodesic
triangle.

Rendering time (per triangle) is probably fine, but I'm afraid of optimisation,
because bounding the curved_triangle is probably not easy to do exactly
(bounding of unit sphere transformed by the inverse matrix is the best I can imagine,
and it leaves a lot of false positives).

I'm not sure, given the additional contraints and all the trouble,
 that this new object is forth its developpement. 
Could you come with some (basic) scenes/objects, which are not already covered
by the existings objects ? (the sphere was a bad example !)
-- 
Non Sine Numine
http://grimbert.cjb.net/
Etiquette is for those with no breeding;
fashion for those with no taste.

Post a reply to this message

> > Why build a sphere out of triangles if you can just use the sphere
object in
> > POV-Ray?  Sounds like reinventing the wheel to me...
> >
> >     Thorsten

> By 3 points and 3 normals (only direction, with the same constraints that
<snip>
> Non Sine Numine
> http://grimbert.cjb.net/
> Etiquette is for those with no breeding;
> fashion for those with no taste.

That's one heck of a reply, but I think you misunderstood what Thorsten was
implying. He was talking about building a sphere using meshes not building
meshes out of spheres (though that is very interesting and you gave quite a
thorough answer)

BTW to Thorsten: I think the original reference to building a sphere out of
meshes was just a simple analogy, not meant to be taken literally but meant
to be extended to more complex objects.

-tgq

Post a reply to this message

Thorsten

That is an example, ¿why build a sphere with mesh?, but they do. That was an
example to show you a comparative between this shape and the mesh of
triangles.

FC

Post a reply to this message

TinCanMan wrote:
> 
> > > Why build a sphere out of triangles if you can just use the sphere
> object in
> > > POV-Ray?  Sounds like reinventing the wheel to me...
> > >
> > >     Thorsten
> 
> > By 3 points and 3 normals (only direction, with the same constraints that
> <snip>
> > Non Sine Numine
> > http://grimbert.cjb.net/
> > Etiquette is for those with no breeding;
> > fashion for those with no taste.
> 
> That's one heck of a reply, but I think you misunderstood what Thorsten was
> implying. He was talking about building a sphere using meshes not building
> meshes out of spheres (though that is very interesting and you gave quite a
> thorough answer)
> 

I agree, I was replying after to Thorsten but my target was the original
poster in the previous post.

Internal mental note: Learn to reply correctly!->

I mainly agree with Thorsten that building a sphere with this idea is worthless
and conter-productive.
And more over, it will introduced another 2D object which cannot be used in CSG
either. Meshes are a pleague, once you start with them, you stop thinging about
volume.

> BTW to Thorsten: I think the original reference to building a sphere out of
> meshes was just a simple analogy, not meant to be taken literally but meant
> to be extended to more complex objects.

Me too, but is there such complex objects that could be done by hand ?
(it was the reason of the initial idea...) 

Now, where is the original poster ?
Because (s)he has some answers to provide if (s)he really wants some work to be
done...

-- 
Non Sine Numine
http://grimbert.cjb.net/
Etiquette is for those with no breeding;
fashion for those with no taste.

Post a reply to this message

"Majukatur" <maj### [at] hotmailcom> wrote in message
news:3d2b4e76@news.povray.org...
> Hi all.
>
> Well, this is an idea that I had, is about the meshes, I was thinking, the
> smooth triangle have a simulated normal that seems to be smooth, but it
> isn't. This simulation even cause an artifact, then ¿why not make a
> smooth_triangle really smoothed?, if the syntax of the smooth_triangle is
> conserved we can use the new shape with old mesh objects without problem,
> but with better quality.

Check out my curvetri.inc, posted in p.b.s-f (I think :)

...Chambers

Post a reply to this message

On Thu, 11 Jul 2002 18:58:32 -0700, "Ben Chambers" <bdc### [at] yahoocom> wrote:
> 
> "Majukatur" <maj### [at] hotmailcom> wrote in message
> news:3d2b4e76@news.povray.org...
> > Hi all.
> >
> > Well, this is an idea that I had, is about the meshes, I was thinking, the
> > smooth triangle have a simulated normal that seems to be smooth, but it
> > isn't. This simulation even cause an artifact, then ¿why not make a
> > smooth_triangle really smoothed?, if the syntax of the smooth_triangle is
> > conserved we can use the new shape with old mesh objects without problem,
> > but with better quality.
> 
> Check out my curvetri.inc, posted in p.b.s-f (I think :)
> 
> ....Chambers
> 

Been thinking about this... This idea may be very mathimatically intensive, but lets
say you did
the folowing... Use the three points on the triangle and there relationship to the
normal provided
(assuming you can) and find an area of a real sphere defined by those points and with
same
real curvature, then use the math for generating spheres to produce those points
within the
that triangle. This assumes you can calculate based on those point and a curve what
the radius
would need to be for the sphere, but would in theory produce a true curve, without the
need to
tessilate the object further. I haven't a clue how myself, but geometrically it should
work. Or so
I assume...

Post a reply to this message

> Been thinking about this... This idea may be very mathimatically
intensive, but lets say you did
> the folowing... Use the three points on the triangle and there
relationship to the normal provided
> (assuming you can) and find an area of a real sphere defined by those
points and with same
> real curvature, then use the math for generating spheres to produce those
points within the
> that triangle. This assumes you can calculate based on those point and a
curve what the radius
> would need to be for the sphere, but would in theory produce a true curve,
without the need to
> tessilate the object further. I haven't a clue how myself, but
geometrically it should work. Or so
> I assume...
>

At first thought on this, I don't think it will work.

First of all, the three points and three normals will, in most cases, not be
able to realize a sphere. Any sized sphere large enough to contain all three
points (i.e., can 'rest' on the three points without falling through) can be
defined by these three points, but unless the patch has a spherical
curvature, it can never match all 3 normals.

Secondly, you want each triangle to run smoothly into the next.  Simple
analysis of spheres will tell you that no two spheres of different radii can
be intersected in such a way that their surfaces intersect smoothly.

I don't mean to rain on your parade but I just wanted to point this out
before someone puts a lot of time into trying this only to find it won't
work.  In reality, I don't think there are any simple POV primitives (blobs
and isosurfaces notwithstanding, but I don't even want to think about the
complexity of that) that can define every possible curved triangle.

-tgq

Post a reply to this message

On Fri, 12 Jul 2002 19:08:54 -0400, "TinCanMan" <Tin### [at] hotmailcom> wrote:
> At first thought on this, I don't think it will work.
> 
> First of all, the three points and three normals will, in most cases, not be
> able to realize a sphere. Any sized sphere large enough to contain all three
> points (i.e., can 'rest' on the three points without falling through) can be
> defined by these three points, but unless the patch has a spherical
> curvature, it can never match all 3 normals.
> 
> Secondly, you want each triangle to run smoothly into the next.  Simple
> analysis of spheres will tell you that no two spheres of different radii can
> be intersected in such a way that their surfaces intersect smoothly.
> 
> I don't mean to rain on your parade but I just wanted to point this out
> before someone puts a lot of time into trying this only to find it won't
> work.  In reality, I don't think there are any simple POV primitives (blobs
> and isosurfaces notwithstanding, but I don't even want to think about the
> complexity of that) that can define every possible curved triangle.
> 
> -tgq


Hadn't thought of that.. I was thinking of a single normal definiing the center of the
triangle and
therefor the curve of the whole thing.. Forgot there where 3. lol However.. What about
an
ellipsoid? That I think would, but kind of creates and even bigger mess figuring it
out. lol May still
not work, but it may be worth the try anyway since if it wasn't possible it should
produce a very
interesting shape, which itself would be very difficult to produce correctly.

Though I agree that in most cases it probably isn't needed, but I kind of get tired of
supposedly
'high-end' models that when rendered require you go back and photoshop the edges
because
you can't smooth out obvious surfaces on the line parallel to the camera view. I don't
care how
good you are with photoshop you miss some and for people like me that are horrible at
it... lol
Additional tessalation is a very poor answer imho. There has got to be a better way
and this one
could produce interesting results in the attempt for anyone with the knowledge to make
the attempt.

First step I think would be to figure out how much to move the points to make them
match a true
sphere, then use that displacement to scale that part to an ellipsiod. Since the
normals would still
be pointing the right way for both that section of the ellipsiod and the intended
curve... Hard to say
without trying, at least for me. Hmm. Though... there may be problems there too, but
only in the sense
of rotation, the needed curve will occure someplace at the right angles on an
ellipsoid, but finding it is
the rub. :p

Post a reply to this message

TinCanMan wrote:
> 
> > Been thinking about this... This idea may be very mathimatically
> intensive, but lets say you did
> > the folowing... Use the three points on the triangle and there
> relationship to the normal provided
> > (assuming you can) and find an area of a real sphere defined by those
> points and with same
> > real curvature, then use the math for generating spheres to produce those
> points within the
> > that triangle. This assumes you can calculate based on those point and a
> curve what the radius
> > would need to be for the sphere, but would in theory produce a true curve,
> without the need to
> > tessilate the object further. I haven't a clue how myself, but
> geometrically it should work. Or so
> > I assume...
> >
> 
> At first thought on this, I don't think it will work.
> 
> First of all, the three points and three normals will, in most cases, not be
> able to realize a sphere. Any sized sphere large enough to contain all three
> points (i.e., can 'rest' on the three points without falling through) can be
> defined by these three points, but unless the patch has a spherical
> curvature, it can never match all 3 normals.

It's even worth than that, but you did not seem to have read my previous posts
on the subject.

> Secondly, you want each triangle to run smoothly into the next.  Simple
> analysis of spheres will tell you that no two spheres of different radii can
> be intersected in such a way that their surfaces intersect smoothly.

Where did you get this second point ?
It was never implied, at least from the explanation.
But it's interesting... and might be expected 

> 
> I don't mean to rain on your parade but I just wanted to point this out
> before someone puts a lot of time into trying this only to find it won't
> work.  In reality, I don't think there are any simple POV primitives (blobs
> and isosurfaces notwithstanding, but I don't even want to think about the
> complexity of that) that can define every possible curved triangle.

There is many cases to study, according to the 4 normals.
(the three explicit ones and the one of the triangle)

If they all meet at one point, you get a part of a sphere,
where the intersection is the center of the sphere.

But what is most interesting, is when one of the explicit normal is
heading outward of the triangle while the two others are inward 
(or vice-versa), the surface need to be subdivided in more curves.

Similarly, when the three normals do not meet (most of the time!),
it might be wise to subdivide.

I ended up trying to generate a spherical triangle from the initial data, 
only to find out that the mapping is far too difficult (for me, at least).
So I only implemented a cleaner object to which you only provide the 
simple data:

The hull is just a triangle on a sphere:
 the first vertex is fixed (<1,0,0>,
 the second one evolves on nearly a circle (*),
 and the third and last one evolves on the remaining sphere.

*: excepted that the second vertex cannot be identical or opposite to
the first vertex.

Syntax is currently like the superellipsoid & torus, 
except it take a 3D vector instead of 2D.

hull { <elevation of second, phi of third, elevation of third> ....

The used sphere is the unit sphere, but you can of course scale/translate/rotate/...
it.
See a quick movie with a hull in p.b.a

-- 
Non Sine Numine
http://grimbert.cjb.net/
Etiquette is for those with no breeding;
fashion for those with no taste.

Post a reply to this message

Patrick Elliott wrote:

> Hadn't thought of that.. I was thinking of a single normal definiing the center of
the triangle and
> therefor the curve of the whole thing.. Forgot there where 3. lol However.. What
about an
> ellipsoid? That I think would, but kind of creates and even bigger mess figuring it
out. lol May still
> not work, but it may be worth the try anyway since if it wasn't possible it should
produce a very
> interesting shape, which itself would be very difficult to produce correctly.

Ellipsoid is only a linear transformation of a sphere, so it won't help when the
normals
do not meet.

> 
> Though I agree that in most cases it probably isn't needed, but I kind of get tired
of supposedly
> 'high-end' models that when rendered require you go back and photoshop the edges
because
> you can't smooth out obvious surfaces on the line parallel to the camera view. I
don't care how
> good you are with photoshop you miss some and for people like me that are horrible
at it... lol
> Additional tessalation is a very poor answer imho. There has got to be a better way
and this one
> could produce interesting results in the attempt for anyone with the knowledge to
make the attempt.
> 
> First step I think would be to figure out how much to move the points to make them
match a true
> sphere,

If you keep insisting on getting both vertices and normales, you have too much
constraint
for the
general case to work.

> then use that displacement to scale that part to an ellipsiod. Since the normals
would still
> be pointing the right way for both that section of the ellipsiod and the intended
curve... 

A linear transformation would help you to make convergent the normale!

> Hard to say
> without trying, at least for me. Hmm. Though... there may be problems there too, but
only in the sense
> of rotation, the needed curve will occure someplace at the right angles on an
ellipsoid, but finding it is
> the rub. :p

Consider when a normal is turned toward the center of the triangle and an other is 
turning away of that center. You won't find that surface on a sphere, or even on
ellipsoid.


-- 
Non Sine Numine
http://grimbert.cjb.net/
Etiquette is for those with no breeding;
fashion for those with no taste.

Post a reply to this message

On Sun, 14 Jul 2002 17:55:54 +0200, Le Forgeron <jgr### [at] freefr> wrote:
> Patrick Elliott wrote:
> 
> Consider when a normal is turned toward the center of the triangle and an other is 
> turning away of that center. You won't find that surface on a sphere, or even on
> ellipsoid.
> 

Hmm.. Ok that is true. :p It does make for some limited utility. Oh, well just
throwing
out ideas. I never claimed to actually have a clue what I was doing. lol

Post a reply to this message

Le Forgeron wrote:
> Ellipsoid is only a linear transformation of a
> sphere, so it won't help when the normals do not meet.

Does that logic apply?

Three normals of a sphere will always meet in the same point. But three
normals of a ellipsoid will not always meet in the same point. I'm not
saying that an ellipsoid is a solution, but just questioning this
particular argument.

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com (updated July 12)
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

On Sun, 14 Jul 2002 22:13:32 +0200, "Rune" <run### [at] mobilixnetdk> wrote:
> Le Forgeron wrote:
> > Ellipsoid is only a linear transformation of a
> > sphere, so it won't help when the normals do not meet.
> 
> Does that logic apply?
> 
> Three normals of a sphere will always meet in the same point. But three
> normals of a ellipsoid will not always meet in the same point. I'm not
> saying that an ellipsoid is a solution, but just questioning this
> particular argument.
> 
> Rune

I believe he is refering to trangles that bend two directions. i.e. the triangle
itself looks
like:

____
        \
          \
            \______

According to the normals provided. And he is correct that under such circumstances
you can never find any primitive that has such a shape. It does occure to me that
in such instances one may be able to find two curves on an ellipsoid that may conform
to such a shape, but you end up tracing the interior of one and the exterior of
another,
not to mention it maybe not working at all, since all three corners could be distorted
in
ways that make it impossible to find any combination that would match. :p There has
got to be a better way of doing this, but... A method that used ellipsoid matching
could
probably 'fix' about 90% of the triangles in the average mesh, but that last 10% are a
problem. And in some objects the percentages could end up drastically shifting the
other way. Oh, well.. Hopefully someone will come up with a decent solution, probably
about the same time someone gets rid of coincident surfaces that are the true bane
of my existance. lol

Post a reply to this message

Patrick Elliott <sel### [at] rrazcom> wrote:
> ____
>         \
>           \
>             \______

  Please don't tell me you are using a variable-width font to write and read
news.
  (It just wouldn't make any sense. By doing so you are assuming that
everyone else in the whole world is using the exact same font and font size
that you are.)

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

Rune wrote:
> 
> Le Forgeron wrote:
> > Ellipsoid is only a linear transformation of a
> > sphere, so it won't help when the normals do not meet.
> 
> Does that logic apply?
> 
> Three normals of a sphere will always meet in the same point. But three
> normals of a ellipsoid will not always meet in the same point. I'm not
> saying that an ellipsoid is a solution, but just questioning this
> particular argument.
> 

Maybe you're right, and for some cases you can find an ellipsoid 
which could accomodate the three normals (even if I have no idea of
how to find the ellipsoid parameters; using a unit sphere is easier
for the math). 
But a linear transform cannot transform a positive curvature into
a negative one. So the ellipsoid won't solve all the cases.

Given also the troubling case where two normals are parallel (which
cannot be solve on someting like a sphere or even an ellipsoid),
I wonder if the curved triangle shouldn't be on a torus instead (*).

At least for the two parallel normals case, it seems that two vertices 
would be on the very top circle of the torus with the third vertex somewhere
so that its normals is ok. Currently, I can only figure the math to 
position the first vertex, the circle where the second vertex is and 
where the third vertex might be.
Maybe using also the true normal of the initial triangle might help to
limit the position of the second and third vertices. 

Once the triangle on the torus is defined, we still go back to the classical
transformation of three points from one space to another, nothing really difficult!
But maybe the torus is not even the right solution.

(*): The more I look at the problem, the more it make me think of an analogy with 
conic curves (the 6 classical conic curves in 2D can all be view as the intersection
of a plane and an infinite double cone: ellipse, parabol, hyperbol, point, single and
double generating lines), which would means that to solve the really curved triangle,
you have first to find out which 3D objects should be used according to the
parameters...
Looks like an intersection of hyperplane with an hypercone, where the position of the
hyperplane
is made according to the parameter, isn't it ?
Only problem is that I can imagine in 3D, but 4D is a bit too much (excepted when it's
3D+Time,
which is not the case here)

-- 
Non Sine Numine
http://grimbert.cjb.net/
Etiquette is for those with no breeding;
fashion for those with no taste.

Post a reply to this message

> Maybe you're right, and for some cases you can find an ellipsoid
> which could accomodate the three normals (even if I have no idea of
> how to find the ellipsoid parameters; using a unit sphere is easier
> for the math).
> But a linear transform cannot transform a positive curvature into
> a negative one. So the ellipsoid won't solve all the cases.
>
> Given also the troubling case where two normals are parallel (which
> cannot be solve on someting like a sphere or even an ellipsoid),
> I wonder if the curved triangle shouldn't be on a torus instead (*).
>
> At least for the two parallel normals case, it seems that two vertices
> would be on the very top circle of the torus with the third vertex
somewhere
> so that its normals is ok. Currently, I can only figure the math to
> position the first vertex, the circle where the second vertex is and
> where the third vertex might be.
> Maybe using also the true normal of the initial triangle might help to
> limit the position of the second and third vertices.
>
> Once the triangle on the torus is defined, we still go back to the
classical
> transformation of three points from one space to another, nothing really
difficult!
> But maybe the torus is not even the right solution.
>
>
I would assume that for a curved triangle that had two parallel normals,
that the entire edge between those two normals would have the same normal.
for a torus, it is true that we can make a triangle that has two parallel
normals (ie, on the top of the torus) but it is quite easy to see that
between these two points the edge will curve (or even disappear in some
cases).
I don't think that simple primitives have the solution.  There must be some
way of creating quadratic type surfaces without having a discrete mesh.
Perhaps isosurfaces could be accomodated, but I would think that would come
at great CPU expense.

-tgq

Post a reply to this message

> I don't think that simple primitives have the solution.  There must be
some
> way of creating quadratic type surfaces without having a discrete mesh.
> Perhaps isosurfaces could be accomodated, but I would think that would
come
> at great CPU expense.
>
Just a furrther thought here.
I don't know how the vertices and normals are interpolated for a triangle,
but if it is a simple surface that can be described using some type of
equation, then perhaps that equation can be put into an isosurface function.
Anyone up for that?

-tgq

Post a reply to this message

On 15 Jul 2002 14:43:40 -0400, Warp <war### [at] tagpovrayorg> wrote:
>   Please don't tell me you are using a variable-width font to write and read
> news.

Not to read no, but apparently to send. I use Opera and it has some quirks
I would like to beat out of it, but since I do my web comic reading, news groups
and the rest all in one shot from in it I have been reluctant to install another
program just to use it. Also my copy of MS LookOut has bugged and crashes
on POP3 accounts. Why it still works with the html hotmail I can't comprehend,
but...

In any case I didn't realize it was doing that. I'll see what if anything I can do
to fix it. :p

Post a reply to this message

In article <3d340ef3$1@news.povray.org>,
 "TinCanMan" <Tin### [at] hotmailcom> wrote:

> I don't think that simple primitives have the solution.  There must be some
> way of creating quadratic type surfaces without having a discrete mesh.
> Perhaps isosurfaces could be accomodated, but I would think that would come
> at great CPU expense.

Why try so hard to avoid using a triangle mesh? Any method you find will 
probably be much more CPU hungry and have artifacts that are harder to 
get rid of than faceting. The reason originally given for "curved smooth 
triangles" was the dark artifact seen when the normal points away from 
the camera, but there are other possible ways to fix that with flat 
smooth triangles.
It seems like the best solution for curved triangles would be a cubic 
surface tesselated into triangles, something like a triangular bezier 
patch. It could even be tesselated on the fly to reduce memory 
requirements.

Maybe subdivision surfaces would be a better solution.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

> Why try so hard to avoid using a triangle mesh? Any method you find will
> probably be much more CPU hungry and have artifacts that are harder to
> get rid of than faceting. The reason originally given for "curved smooth
> triangles" was the dark artifact seen when the normal points away from
> the camera, but there are other possible ways to fix that with flat
> smooth triangles.
> It seems like the best solution for curved triangles would be a cubic
> surface tesselated into triangles, something like a triangular bezier
> patch. It could even be tesselated on the fly to reduce memory
> requirements.
>
> Maybe subdivision surfaces would be a better solution.

I think another reason was that if not enough triangles are used, in
profile, the shape has a jagged edge rather than a smooth one.  Even though
the shading is smooth, the outline still follows the polygons.

-tgq

Post a reply to this message

In article <3d35a378$1@news.povray.org>,
 "TinCanMan" <Tin### [at] hotmailcom> wrote:

> I think another reason was that if not enough triangles are used, in
> profile, the shape has a jagged edge rather than a smooth one.  Even though
> the shading is smooth, the outline still follows the polygons.

Still not a reason to avoid triangles altogether...if you use a 
tesselated surface for the "curved triangles", you could still get the 
straight edges small enough you can't tell the edge isn't really curved.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

On Wed, 17 Jul 2002 12:13:21 -0500, Christopher James Huff <chr### [at] maccom> wrote:
> In article <3d35a378$1@news.povray.org>,
>  "TinCanMan" <Tin### [at] hotmailcom> wrote:
> 
> > I think another reason was that if not enough triangles are used, in
> > profile, the shape has a jagged edge rather than a smooth one.  Even though
> > the shading is smooth, the outline still follows the polygons.
> 
> Still not a reason to avoid triangles altogether...if you use a 
> tesselated surface for the "curved triangles", you could still get the 
> straight edges small enough you can't tell the edge isn't really curved.
> 

Only with an extraordinary number of triangles, and if you are using someone elses
model...

But yeah, if POV could be made aware of when such artifacts where visible and
automatically tessalated those surfaces sufficiently to erase the jagged surfaces,
that would
be nice. The problem is that no program I know of does and not everyone can photoshop
them
away without making things worse. The dark artifacts 'may' be fixed with the right
changes,
but squarish 'curves' will only be solved by either replacing them with something that
can
be CSGed, further tessalation or some alternate solution. In general, the equation is:
Realism = Primatives Used / (Meshes / Complexity) and in that equation even one mesh
no
matter how complex 'will' effect the overall realism, at least until you have the
resources and
time of companies like Dreamworks and can make the complexity so high that the result
of the bottom half becomes 0.xxxx. I doubt most of us have those kinds of resources.
Neadless to say a better solution is definitely needed. ;)

Post a reply to this message

In article <1103_1026930387@news.povray.org>,
 Patrick Elliott <sel### [at] rrazcom> wrote:

> Only with an extraordinary number of triangles, and if you are using someone 
> elses model...

The tesselation could be done at render time without too much drop in 
speed, and the number of triangles wouldn't be so "extraordinary". And 
it could work with any mesh, I don't know where you got the "someone 
elses model" limitation.


> But yeah, if POV could be made aware of when such artifacts where 
> visible and automatically tessalated those surfaces sufficiently to 
> erase the jagged surfaces, that would be nice. The problem is that no 
> program I know of does and not everyone can photoshop them away 
> without making things worse.

I don't think it is such a problem...just increase the amount of 
tessellation for triangles with a high curvature and "convex" triangles 
where the normal for a flat triangle with the same points would be at a 
high angle to the incoming ray. Maybe also adjust the tesselation 
fineness across the triangle. There might be trouble with "tearing" or 
"cracks", but there might be a way to prevent that, and it might not be 
a big problem.


> The dark artifacts 'may' be fixed with the right changes, but 
> squarish 'curves' will only be solved by either replacing them with 
> something that can be CSGed, further tessalation or some alternate 
> solution.

If you are using a mesh anyway, further tesselation seems like a perfect 
solution.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

BTW, your Followup-To header seems to be scrambled somehow...it says 
"chr### [at] netplexaussieorg" in that message for 
some reason. It seems messed up in other messages of yours as well. At 
least, MT-NewsWatcher chokes on it when I try to reply to one of your 
messages, I have to manually change the Newsgroups header to the correct 
group.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

Christopher James Huff wrote:
> Maybe subdivision surfaces would be a better solution.

No way this is gonna go unnoticed from my eyes :)

I'm all for subdivision surfaces. Just to think that I could just export a
lowpoly mesh from Wings3D and POV would subdivide it for me (The UVs as
well).
I hope some able programmer wants to see POV do this and not just me :)

--
-Jide

Post a reply to this message

On Wed, 17 Jul 2002 14:17:46 -0500, Christopher James Huff <chr### [at] maccom> wrote:
> BTW, your Followup-To header seems to be scrambled somehow...it says 
> "chr### [at] netplexaussieorg" in that message for 
> some reason. It seems messed up in other messages of yours as well. At 
> least, MT-NewsWatcher chokes on it when I try to reply to one of your 
> messages, I have to manually change the Newsgroups header to the correct 
> group.

Yeah. I know. The problem is that I am using Opera and have to manually edit the
stupid
follow-up field to get it to post in the right thread (or any thread but a new one). I
have asked
for advice from someone else as to which of the various bits and pieces of the message
header that I need to fix it, but no one has given me a good answer... :p Opera just
won't
do it correctly, my version of Outlook is bugged (crashes on POP3 accounts, but not
hotmail's
html... figure that one out... lol) and I am reluctant to install still another
program on my comp
that may not work any better. :p I figured out that using the message ID correctly
posted it to
the thread, but... Do I use the xref field instead or something else? I just have no
clue and
people I have asked don't seem to know either or want to enlighten me...

Frankly I like being able to click on a custom html menu I made to go straight to the
POV
forums as well as ones for another program, several comics, etc., but there are a lot
of things I
hate about Opera's email/news, including the fact that it insists on posting using a
proportional
font, and reading in a fixed one. A 'feature' that also can't apparently be fix this
either. :p
It would almost be easier to write one as an COM program and call it through a
Javascript link
on my menu. lol But then I would still have to know what is actually broken in Opera.
lol

Post a reply to this message

"Patrick Elliott" <sel### [at] rrazcom> wrote in message
news:1103_1026511141@news.povray.org...
> > Check out my curvetri.inc, posted in p.b.s-f (I think :)
> >
> > ....Chambers
> >
>
> Been thinking about this... This idea may be very mathimatically
intensive, but lets say you did
> the folowing... Use the three points on the triangle and there
relationship to the normal provided
> (assuming you can) and find an area of a real sphere defined by those
points and with same
> real curvature, then use the math for generating spheres to produce those
points within the
> that triangle. This assumes you can calculate based on those point and a
curve what the radius
> would need to be for the sphere, but would in theory produce a true curve,
without the need to
> tessilate the object further. I haven't a clue how myself, but
geometrically it should work. Or so
> I assume...

That was similar to the first way I tried.  Except, I tried blending between
three different spheres, defined by each point and it's normal :)  Didn't
work too well, though :(

...Chambers

Post a reply to this message

> Patrick Elliott <sel### [at] rrazcom> wrote:
> > ____
> >         \
> >           \
> >             \______

Warp wrote:
>   Please don't tell me you are using a variable-width font
> to write and read news.

Maybe it's just a poor tab setting.

-- 
Anton Sherwood, http://www.ogre.nu/

Post a reply to this message

Rune wrote:
> Well, bicubic patches are just plain difficult to use in general.
> Because of their four corners, it's very difficult to make advanced
> shapes where the patches are joined up smoothly. Some 3d programs
> which also use patch-like shapes come about this problem by offering
> special patches with 3 or 5 corners to supplement the regular ones
> with 4 corners. Not POV-Ray though.

One could subdivide a triangle into three quadrilaterals (add a point in
each edge and one in the middle); but it does seem like going the long
way around the barn, essentially to make up for a defect in the syntax.

-- 
Anton Sherwood, http://www.ogre.nu/

Post a reply to this message

TinCanMan wrote:
> I don't know how the vertices and normals are interpolated for a
> triangle, but if it is a simple surface that can be described using
> some type of equation, then perhaps that equation can be put into an
> isosurface function.

I assume the normals of a smooth_triangle are linearly interpolated.

Hm: you have three known zeros (i.e. f(x0,y0,z0) = f(x1,y1,z1) =
f(x2,y2,z2) = 0) and nine partial derivatives, to which you can fit a
polynomial function -- but then you'll have to clip this iso into a
prism or pyramid whose shape may not be so easy to determine.

-- 
Anton Sherwood, http://www.ogre.nu/

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3d3317dc@news.povray.org...
> Patrick Elliott <sel### [at] rrazcom> wrote:
> > ____
> >         \
> >           \
> >             \______
>
>   Please don't tell me you are using a variable-width font to write and
read
> news.


    I do - variable width fonts are easier on the eye.

    The only time it matters is when someone includes ascii-art in a post,
and, realistically, just how often does that happen ? On the rare occasion I
do want to see some ascii art in a fixed width font I just copy and paste
into Notepad...

--
Pandora/Scott Hill/[::O:M:C::]Scorpion
Software Engineer.
http://www.pandora-software.com

Post a reply to this message

Pandora <pan### [at] pandora-softwarecom> wrote:
>     The only time it matters is when someone includes ascii-art in a post,
> and, realistically, just how often does that happen ?

  People post code quite often, and indentation suffers quite a lot with
variable-width font, as well as general readability (delimiters are much
harder to distinguish when they are really small).
  Smileys are just plain horrible with variable-width fonts.
  Also people usually write text so that the length of the lines is
approximately the same, thus getting approximately justified paragraphs,
which are nicer to the eye. With variable-width font you probably get
much more variation in line lengths.

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

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3d6be32a@news.povray.org...
> Pandora <pan### [at] pandora-softwarecom> wrote:
> >     The only time it matters is when someone includes ascii-art in a
post,
> > and, realistically, just how often does that happen ?
>
>   People post code quite often, and indentation suffers quite a lot with
> variable-width font, as well as general readability (delimiters are much
> harder to distinguish when they are really small).

    Hmm... I can see your point, but I can't see the problem - I have no
problem with reading code in a variable-width font. Though I could never
write code in a variable-width font...

>   Smileys are just plain horrible with variable-width fonts.

    Again, I don't see the problem - they look just fine to me...

>   Also people usually write text so that the length of the lines is
> approximately the same, thus getting approximately justified paragraphs,
> which are nicer to the eye. With variable-width font you probably get
> much more variation in line lengths.
>

    URGH! I _hate_ that all straight lines down each side - I always want to
mess 'em up a bit...

    I guess it's all a matter of taste...
--
Pandora/Scott Hill/[::O:M:C::]Scorpion
Software Engineer.
http://www.pandora-software.com

Post a reply to this message

In article <3d6bea14@news.povray.org>,
 "Pandora" <pan### [at] pandora-softwarecom> wrote:

>     Hmm... I can see your point, but I can't see the problem - I have no
> problem with reading code in a variable-width font. Though I could never
> write code in a variable-width font...

I hate trying to read code in variable-width font...especially when 
things are nicely lined up in fixed width font.


>     URGH! I _hate_ that all straight lines down each side - I always want to
> mess 'em up a bit...

He said "approximately", he wasn't talking about having the words 
perfectly aligned to both edges, but something like this message. Having 
gaps at the edges for no reason would be terrible for readability. Using 
a fixed width font makes sure you see what everyone else sees.

-- 
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" <chr### [at] maccom> wrote in message
news:chr### [at] netplexaussieorg...
> Having gaps at the edges for no reason would be terrible for readability.
>


    That's just it - I don't think it is - I find it more, um, natural -
maybe it's just me...

--
Pandora/Scott Hill/[::O:M:C::]Scorpion
Software Engineer.
http://www.pandora-software.com

Post a reply to this message

In article <3d6d6503$1@news.povray.org>,
 "Pandora" <pan### [at] pandora-softwarecom> wrote:

> 
>     That's just it - I don't think it is - I find it more, um, natural -
> maybe it's just me...


      He said "approximately", he wasn't talking about
having the words perfectly aligned to both
         edges, but something like this message. Having gaps
   at the edges for no reason would be terrible for
      readability. Using a fixed width font makes sure
 you see what everyone else sees.


You can't be serious...I suspect you are trying to say something 
completely different, because I don't see how anyone could think 
something so random could be better than naturally flowing text.

Having a straight line down the left side is much easier to read, it 
gives the eye a definite location to switch to after the end of a line. 
Forcing the right side to be even hurts readability, because it causes 
unnatural spacing in the words. Having the text centered is even harder 
to read, since the eye has to search for the beginning of the next line. 
Having both sides uneven would be the worst possible way, and I don't 
see why anyone would bother to do it.

-- 
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" <chr### [at] maccom> wrote in message
news:chr### [at] netplexaussieorg...
> In article <3d6d6503$1@news.povray.org>,
>  "Pandora" <pan### [at] pandora-softwarecom> wrote:
> >     That's just it - I don't think it is - I find it more, um, natural -
> > maybe it's just me...
>
> <snipped horribly random text>
>
> I suspect you are trying to say something
> completely different, because I don't see how anyone could think
> something so random could be better than naturally flowing text.
>

    Yes, I am saying something different. I agree, the left side should be
straight, but Warp said "people usually write text so that the length of the
lines is approximately the same, thus getting approximately justified
paragraphs", i.e. the right hand side, though not completely straight, is
roughly straight - it's that that I dislike.
    I dislike completely justified (with both left and right sides
completely straight) even more.
    I just like text to be a bit more random than "approximately justified".
For example, as I write this, the ends of the lines of my first paragraph
are in a roughly straight line, and I want to put a couple carriage-returns
in to make them less uniform, but won't 'cos I know it'll screw things up
completely when OE comes to wrap them at 76 characters...
    Of course, it could be taken to extremes, with hugely varying line
lengths, and that's just as bad, if not worse.
    I'm not sure I could define the points at which it's either too random
or too justified, so don't ask...

    Anyway, this is all getting way off-topic for p.u.p...

--
Pandora/Scott Hill/[::O:M:C::]Scorpion
Software Engineer.
http://www.pandora-software.com

Post a reply to this message