 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I've been trying to make a rather blatent rip-off of an image on
http://www.sover.net/~tlongtin/, but as you can see in the attached image,
I'm having a small problem. (OK, it's not an exact rip-off, the holes on
mine are more evenly spaced, and I have a class in differential geometry 20
years ago to thank for that. OTOH, the textures on the original are not so
good, and mine are much, much worse. Perhaps with a huge pile of greebles
added on... 8^)
I have (or at least should have) a properly enclosed mesh object, along with
an inside vector for it. It's the green object in the image, if you haven't
guessed. 8^) It's a mesh with some cylinders differenced out to make the
holes for the torus to go through. I think it would be a huge pain to try
to compute the holes as part of the mesh, but it could be just because I
haven't thought about it enough.
The POVray help files say that this should be OK for CSG, but I get a parse
warning saying "Patch objects not allowed in intersection" at the closing
brace for my difference object. And if you look carefully at the holes,
they don't have any depth like the edge of the band does. (Or the holes in
the torus, which is the same thickness as the band.)
Also, the documentation talks about the vector as the location of a point
inside the mesh, but then talks about it as if it is some nebulous
direction for POV-Ray to shoot from random points to determine
"insidedness". This is not the most clear exposition of the situation, and
could use some polish IMHO. If someone will explain the exact algorithms
involved, I'll make a stab at cleaning it up a bit.
BTW, I am using POV-Ray version 3.6.1b.icl8.win32
Jon
Post a reply to this message
Attachments:
Download 'mobius.png' (58 KB)
Preview of image 'mobius.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jon Buller nous apporta ses lumieres en ce 15/05/2006 19:03:
> I've been trying to make a rather blatent rip-off of an image on
> http://www.sover.net/~tlongtin/, but as you can see in the attached image,
> I'm having a small problem. (OK, it's not an exact rip-off, the holes on
> mine are more evenly spaced, and I have a class in differential geometry 20
> years ago to thank for that. OTOH, the textures on the original are not so
> good, and mine are much, much worse. Perhaps with a huge pile of greebles
> added on... 8^)
>
> I have (or at least should have) a properly enclosed mesh object, along with
> an inside vector for it. It's the green object in the image, if you haven't
> guessed. 8^) It's a mesh with some cylinders differenced out to make the
> holes for the torus to go through. I think it would be a huge pain to try
> to compute the holes as part of the mesh, but it could be just because I
> haven't thought about it enough.
>
> The POVray help files say that this should be OK for CSG, but I get a parse
> warning saying "Patch objects not allowed in intersection" at the closing
> brace for my difference object. And if you look carefully at the holes,
> they don't have any depth like the edge of the band does. (Or the holes in
> the torus, which is the same thickness as the band.)
>
> Also, the documentation talks about the vector as the location of a point
> inside the mesh, but then talks about it as if it is some nebulous
> direction for POV-Ray to shoot from random points to determine
> "insidedness". This is not the most clear exposition of the situation, and
> could use some polish IMHO. If someone will explain the exact algorithms
> involved, I'll make a stab at cleaning it up a bit.
>
> BTW, I am using POV-Ray version 3.6.1b.icl8.win32
>
> Jon
>
>
>
> ------------------------------------------------------------------------
>
You can substract or intersect from a patch object, but you can't substract/intersect
a patch object
from another object. The patch object is only a surface, even if it have a defined
interior.
--
Alain
-------------------------------------------------
Unitarianism: Come let us reason together about this shit.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain <ele### [at] netscape net> wrote:
> You can substract or intersect from a patch object, but you can't
substract/intersect a patch object
> from another object. The patch object is only a surface, even if it have a defined
interior.
Hmmm... I am doing this:
difference {
mesh { triangle { } }
cylinder { }
pigment { rgb { <1/2,1,1/2> } }
}
for the green band, and the same for the torus, substituting torus for mesh,
and red for green...
To me, this is "subtract cylinder from mesh", correct? Of course there is a
while loop around the cylinder to get all the holes, and a few loops inside
the mesh to make all the smooth_triangles...
I'll post the code if it helps, (or if anyone is interested) but there is a
bunch of ugly math in there to get the positions, distances, and normals
correct. The algebra (and trig identities) needed to get the metric tensor
are pretty messy. I needed to use Maxima to double check and find the
mistakes in my afternoon of algebraic manipulations.
......checks code... Oh, I think it was the inside_vector. When I first did
this, I think I just used x, but the torus is {8,3 ...}. That produced
some weird ghost reflections off the cylinders, so I changed it to 0, as
above and it worked better. Changing it just now to <8,0,0> looks like it
is working correctly. Perhaps my first attempt just happened to get the
inside_vector inside one of the cylinders, and I missed seeing the warning
until later.
Am I correct in believing that inside_vector is a point inside the mesh, and
the part in the docs saying "You can specify the direction of this vector.
For example, to use +z as the direction..." perhaps should have the word
"location" substituted for "direction"?
Many thanks,
Jon
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Jon Buller" <jon### [at] bullersnet> wrote:
> ......checks code... Oh, I think it was the inside_vector. When I first did
> this, I think I just used x, but the torus is {8,3 ...}. That produced
> some weird ghost reflections off the cylinders, so I changed it to 0, as
> above and it worked better. Changing it just now to <8,0,0> looks like it
> is working correctly. Perhaps my first attempt just happened to get the
> inside_vector inside one of the cylinders, and I missed seeing the warning
> until later.
Never mind, that wasn't it. Or at least not all of it. This is the same
file (with the <8,0,0> inside_vector) but the torus is off, and the camera
has been moved from <5,19,11>*3/2 to <5,11,19>/2. Notice the odd ghosts on
the hole on the right, and sides on the upper holes with the lights
shining across them (through holes on the other side of the band).
Jon
Post a reply to this message
Attachments:
Download 'mobius.png' (56 KB)
Preview of image 'mobius.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jon Buller nous apporta ses lumieres en ce 15/05/2006 23:53:
> "Jon Buller" <jon### [at] bullersnet> wrote:
>
>
>>......checks code... Oh, I think it was the inside_vector. When I first did
>>this, I think I just used x, but the torus is {8,3 ...}. That produced
>>some weird ghost reflections off the cylinders, so I changed it to 0, as
>>above and it worked better. Changing it just now to <8,0,0> looks like it
>>is working correctly. Perhaps my first attempt just happened to get the
>>inside_vector inside one of the cylinders, and I missed seeing the warning
>>until later.
>
>
>
> Never mind, that wasn't it. Or at least not all of it. This is the same
> file (with the <8,0,0> inside_vector) but the torus is off, and the camera
> has been moved from <5,19,11>*3/2 to <5,11,19>/2. Notice the odd ghosts on
> the hole on the right, and sides on the upper holes with the lights
> shining across them (through holes on the other side of the band).
>
> Jon
>
>
>
> ------------------------------------------------------------------------
>
When you intersect from a mesh, you effectively clip off a hole in it. The fact that
you see the
iner face is the expected behaviour. The dark "edge" of the middle hole looks like
it's a shadow on
the back surface, try using an area_light, it should become blured.
--
Alain
-------------------------------------------------
God doesn't play dice. -- Albert Einstein
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain <ele### [at] netscapenet> wrote:
> When you intersect from a mesh, you effectively clip off a hole in it. The fact that
you see the
> iner face is the expected behaviour. The dark "edge" of the middle hole looks like
it's a shadow on
> the back surface, try using an area_light, it should become blured.
Oh, so a mesh box used in CSG is more like a cardboard box, not a solid
block of concrete? That doesn't seem all that useful. Is there any way to
switch it?
And as for the artifact, it's not the dark edge, but the gray area in the
middle of the black hole. For an even better example, look to the lower
left corner, there is a bigger one there. It seems to be completely off the
surface going into the center area. The only thing that should be in that
area is the end of the cylinder used to cut the hole.
Once again, many thanks for your time and explainations.
Jon
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jon Buller wrote:
> And as for the artifact, it's not the dark edge, but the gray area in the
> middle of the black hole. For an even better example, look to the lower
> left corner, there is a bigger one there. It seems to be completely off the
> surface going into the center area. The only thing that should be in that
> area is the end of the cylinder used to cut the hole.
It could very well be the end of the cylinder. Try increasing the
length by moving the ends out more from the mesh they're cutting from.
I would recommend that you either compute the holes as part of your
mesh, or write a function for this shape and use an isosurface - but
that's because I've a nuerotic aversion to polygon meshes :)
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
