 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've had this strange question going around in my head for awhile now, so I
thought I would finally ask:
My understanding of meshes is not complete, but in theory, it seems like it
would possible to take a mesh object, and convert each of the mesh triangles
(including normals) into dissected CSG spheres which are then scaled,
rotated, and translated into place.
Has anyone ever experimented with this? Obviously, render time would be
much slower, especially if many difference operations are involved, and it
just might be impossible with today's hardware and todays' large meshes.
Additionally, I would guess that uv_mapping would be out of the question
without a specific patch that supports this. Nevertheless, it could be a
useful tool in some, if not many, situations.
--
Jeremy
www.beantoad.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wasn't it Jeremy M. Praay who wrote:
>I've had this strange question going around in my head for awhile now, so I
>thought I would finally ask:
>
>My understanding of meshes is not complete, but in theory, it seems like it
>would possible to take a mesh object, and convert each of the mesh triangles
>(including normals) into dissected CSG spheres which are then scaled,
>rotated, and translated into place.
A sphere only has 4 degrees of freedom, so you could place a sphere so
that it intersected the three vertices of the triangle, and matched ONE
of the vertex normals. That would then uniquely define the sphere. The
other two vertex normals would not match except in a few specific
situations.
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Mike Williams" <nos### [at] econym demoncouk> wrote in message
news:+7jz### [at] econymdemoncouk...
>
> A sphere only has 4 degrees of freedom, so you could place a sphere so
> that it intersected the three vertices of the triangle, and matched ONE
> of the vertex normals. That would then uniquely define the sphere. The
> other two vertex normals would not match except in a few specific
> situations.
>
Ahhh... I didn't realize that each vertex had a normal. I guess I need to
learn more about smooth meshes/triangles. Now I guess I'll have to start
thinking about using iso-surfaces, in which case, I think I'm going to stop
thinking.
Thanks for the answer.
--
Jeremy
www.beantoad.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jeremy M. Praay <sla### [at] hotmailcom> wrote:
> My understanding of meshes is not complete, but in theory, it seems like it
> would possible to take a mesh object, and convert each of the mesh triangles
> (including normals) into dissected CSG spheres which are then scaled,
> rotated, and translated into place.
You mean something like this?
http://www.geocities.com/ccolefax/images/createmesh.jpg
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jeremy M. Praay wrote:
> I've had this strange question going around in my head for awhile now, so I
> thought I would finally ask:
>
> My understanding of meshes is not complete, but in theory, it seems like it
> would possible to take a mesh object, and convert each of the mesh triangles
> (including normals) into dissected CSG spheres which are then scaled,
> rotated, and translated into place.
>
> Has anyone ever experimented with this? Obviously, render time would be
> much slower, especially if many difference operations are involved, and it
> just might be impossible with today's hardware and todays' large meshes.
> Additionally, I would guess that uv_mapping would be out of the question
> without a specific patch that supports this. Nevertheless, it could be a
> useful tool in some, if not many, situations.
>
Not sure where you are heading with it. It would seem that you could
take any three points and generate a triangular shape from planes and
use it to difference a sphere surface but the edges would still be
curved and not follow a straight line between the points. ( iso_csg has
a function for generating a triangle from three points btw which could
be used to clip the sphere surface ) Also I have been playing with
using complex clippings of sphere surfaces to use as hair. Actually it
is kind of on the back burning right now but it seemed quite fast
rendering. Don't know if any of that relates to your problem.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Jim Charter" <jrc### [at] msncom> wrote in message
news:414d9723@news.povray.org...
> Jeremy M. Praay wrote:
>> I've had this strange question going around in my head for awhile now, so
>> I thought I would finally ask:
>>
>> My understanding of meshes is not complete, but in theory, it seems like
>> it would possible to take a mesh object, and convert each of the mesh
>> triangles (including normals) into dissected CSG spheres which are then
>> scaled, rotated, and translated into place.
>>
>> Has anyone ever experimented with this? Obviously, render time would be
>> much slower, especially if many difference operations are involved, and
>> it just might be impossible with today's hardware and todays' large
>> meshes. Additionally, I would guess that uv_mapping would be out of the
>> question without a specific patch that supports this. Nevertheless, it
>> could be a useful tool in some, if not many, situations.
>>
> Not sure where you are heading with it. It would seem that you could take
> any three points and generate a triangular shape from planes and use it to
> difference a sphere surface but the edges would still be curved and not
> follow a straight line between the points. ( iso_csg has a function for
> generating a triangle from three points btw which could be used to clip
> the sphere surface ) Also I have been playing with using complex
> clippings of sphere surfaces to use as hair. Actually it is kind of on
> the back burning right now but it seemed quite fast rendering. Don't know
> if any of that relates to your problem.
Mike actually answered my question, but thanks to you and Warp for the extra
information.
The IC_Triangle function (in ISOCSG.inc) is very close to what I would like.
What I'm thinking of, is a fairly simple way of replacing a mesh (smooth
triangles) with "real" surfaces. If the IC_Triangle had the ability to pass
the vertex normals as well, and actually have the normals changed into a
real function-based surface, it would be, well, really cool. In theory,
such a feature could allow someone to completely replace a smooth triangle
mesh with isosurfaces.
It sounds compelling to me, but I'm not sure I could pull-off something of
this magnitude. In my ideal world, it could be a patch which uses a new
format (mesh3?), or alternately, it could read through a mesh2 object and
convert it into something else (isosurfaces, perhaps).
To back up a little bit, I'm often annoyed by the artifacts that come as a
result of the "smooth triangle" problem. The problem becomes very visible
at times (e.g. http://www.oyonale.com/ldc/images/fermeture_detail2.jpg
[sorry Gilles]). However, I see that the new PoseRay does surface
subdivision now, which may aid in alleviating this problem. So anyway,
that's where I was going with this.
--
Jeremy
www.beantoad.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jeremy M. Praay wrote:
>
> To back up a little bit, I'm often annoyed by the artifacts that
> come as a result of the "smooth triangle" problem.
http://www.slimeland.com/slimepov/
-Shay
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Shay" <sah### [at] simcopartscom> wrote in message
news:41506249$1@news.povray.org...
> Jeremy M. Praay wrote:
>>
>> To back up a little bit, I'm often annoyed by the artifacts that
>> come as a result of the "smooth triangle" problem.
>
> http://www.slimeland.com/slimepov/
>
Thanks for that. When I brought up the problem awhile ago (in the
p.tools.poser ng), I had heard that Christophe Bouffartigue had a fix once,
but I couldn't find any mention of it in any of the recent compilations.
I wonder why Slime's patch for the smooth triangle (and shadow-line
artifact) problem never made it into MegaPov. But I'm guessing it's the
fact that "there is no solution that works in every case".
I tried the new version of PoseRay, and did surface subdivision on the
Victoria 3 model, and it seemed to work for me. I'm sure there are still
some artifacts, but I guess it becomes a question of degree at that point,
and if you have enough RAM (and patience), you could always subdivide it
more. IMHO, that is an awesome feature to have. It's makes a world of
difference for POV-Ray. (Though I have to say that it took me a few minutes
to figure out how to get it to work.)
I still think it would be waaay cool to be able to turn a mesh into
isosurfaces, though. I guess I'll have to get smarter.
--
Jeremy
www.beantoad.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I wonder why Slime's patch for the smooth triangle (and shadow-line
> artifact) problem never made it into MegaPov. But I'm guessing it's the
> fact that "there is no solution that works in every case".
Well...
The smooth triangle bug *is* a bug and there are solutions which work in
every case. However, this bug is very difficult to fix given the way that
it's ingrained in the POV-Ray code. My bug fix was a hack and did not really
address the underlying issue. I hope (and basically expect) that the code
changes for POV-Ray 4.0 will address this issue and treat the smoothing of
triangles more like normal perturbation so that the bug does not occur.
I believe there are two reasons that my "fix" for this bug was not brought
into MegaPov: first, the best feature of SlimePOV (IMO and probably the
opinions of others as well) was the height field normal bugfix, and that and
other height field bug fixes were put into MegaPov and POV-Ray 3.6; these
were probably a distraction from the triangle normal bugfix. Second, the fix
was very messy and ugly, so there probably wasn't much of a desire for other
coders to put it in their patches.
The shadow line artifact is not a bug, however, and there is no real perfect
solution to it. My solution in SlimePOV is also kind of a hack, and it
doesn't really behave completely intuitively.
I was thinking recently, however, about a different possible solution to the
shadow line artifact: what if there were a keyword that prevented the
*inner* surface of an object from casting shadows? That is, an object with
this flag set would only intersect with shadow rays when the shadow rays hit
it on the outside. The shadow line artifact is caused by self-shadowing, but
that self shadowing is from the *inside* of a nearby part of the object. I
think that this would solve the problem for all objects which are completely
contained (no holes in the surface, either missing triangles in a mesh or
clipped_by). But that tends to be a property of 99% of objects in POV-Ray
anyway.
- Slime
[ http://www.slimeland.com/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jeremy M. Praay wrote:
> real function-based surface, it would be, well, really cool. In theory,
> such a feature could allow someone to completely replace a smooth triangle
> mesh with isosurfaces.
>
Yes I played with it a bit leaving the surfaces flat, the attraction being
that you could then apply a real displaced texture to
the surface. It was very slow to render and first results were not
too exciting.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
