 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I was interested in using a lemon, or the inner surface of a spindle torus, or
the surface of revolution of a vesica piscis - whichever terminology you prefer
- to compare to a surface.
There is precious little information that I can find describing the lemon, and I
wanted a parameterized object.
The documentation doesn't have a diagram of how the lemon {} available in
version 3.8 is constructed (like it does for the ovus {} ), and the explanation
took me longer than it should have to clearly understand.
https://wiki.povray.org/content/Reference:Lemon
https://wiki.povray.org/content/Reference:Ovus
Presently, I have two problems. And one other issue.
First, when I try to render the lemon {} object with the current parameters, I
only get a very faint speckling rather than a well-formed surface. (I have
rendered several successful test lemons in 3.8)
You can just see it in the render. This makes me sad, as I know Jerome Grimbert
did a lot of work on this shape.
Second, after I finally worked out how to isolate the inner surface of a
standard torus using an isosurface, I found that I needed to add a Fudgefactor
to the minor radius in order to remove a lot of artefactual noise. I found the
0.2 magnitude of the FudgeFactor to be disturbingly large.
(Maybe I would have better luck with a polynomial object.)
The other issue is that the isosurface seems to have the interior_texture on the
outside, and the texture on the inside.
Anyone have any ideas?
// -------------------------------------------------------------------------
#version 3.8;
global_settings {assumed_gamma 1}
#declare E = 0.00001;
#declare Zoom = 160;
camera {
orthographic
//angle
location <0, 0, -image_width*2>
right x*image_width/Zoom
up y*image_height/Zoom
//sky y
look_at <0, 0, 0>
rotate y*0
}
light_source {<image_width/2, image_height/2, -image_width*4> rgb 1 shadowless}
sky_sphere {pigment {rgb 1}}
#declare R = 3;
#declare r = 0.25;
#declare Line = 0.01;
#macro LemonLayout (Radius, Distance, Points)
#local Circle =
union {
sphere {0, Line*2}
torus {Radius, Line rotate x*90}
pigment {rgb x}
}
object {Circle translate x*Distance}
object {Circle translate -x*Distance}
#if (Points)
union {
#for (Phi, 0, tau, 0.1)
#for (Theta, 0, tau, 0.1)
#local X = Radius * cos (Theta) * sin (Phi) - Distance;
#if (X >= 0)
#local Y = Radius * sin (Theta);
#local Z = X * sin (Phi);
sphere {<X, Y, Z>, Line*2}
#end
#end
#end
pigment {rgb z}
}
#end
#end
#declare MF = 0.6;
#declare Min_factor= min (MF, 1);
#declare Max_gradient = 250;
#declare P0 = Max_gradient * Min_factor;
#declare P1 = sqrt (Max_gradient/(Max_gradient * Min_factor));
#declare _P2 = 0.7;
#declare P2 = min (_P2, 1);
#declare r = 1;
#declare R = 0.6;
// intersection points of 2 circles
// (x+R)(x+R) + y*y = r*r
// (x-R)(x-R) + y*y = r*r
// x*x + 2*R*x + R*R + y*y = r*r
// x*x - 2*R*x + R*R + y*y = r*r
// 4*R*x = 0
// x = 0
// y = sqrt ( r*r - R*R )
#declare Y = sqrt ( r*r - R*R );
#declare FudgeFactor = 0.2;
#declare Torus = function {pow (x*x + y*y + z*z + R*R - r*r, 2) -
4*R*R*(x*x+z*z)}
#declare Spindle = function {select ((r-R)*(r-R) - (x*x+z*z) + FudgeFactor, 0,
pow (x*x + y*y + z*z + R*R - r*r, 2) - 4*R*R*(x*x+z*z))}
#declare Iso =
isosurface {
function {Spindle (x, y, z)}
contained_by { box {<-(R-r), -Y, -(R-r)>, <R-r, Y, R-r>} } // container shape
accuracy 0.001
max_gradient 250
//evaluate P0, P1, P2
open
texture {
pigment {rgb z}
finish {specular 0.4}
} // end texture
interior_texture
{
pigment {rgb x+y}
finish {specular 0.4}
} // end texture
} // end isosurface
union {
LemonLayout (1, 0.6, no)
object {Iso }
translate -x*r
}
union {
LemonLayout (1, 0.6, no)
object {Iso}
rotate y*90 translate x*r
}
lemon {
<0, -Y, 0>, 0, <0, Y, 0>, 0, r
texture {pigment {rgb <0.2, 0.2,0>} finish {specular 0.4}}
sturm
}
Post a reply to this message
Attachments:
Download 'lemon.png' (57 KB)
Preview of image 'lemon.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscape net> wrote:
> First, when I try to render the lemon {} object with the current parameters, I
> only get a very faint speckling rather than a well-formed surface. (I have
> rendered several successful test lemons in 3.8)
>
> You can just see it in the render. This makes me sad, as I know Jerome Grimbert
> did a lot of work on this shape.
And wouldn't you know it, subtracting that exact same FudgeFactor from the
radius in the lemon {} makes it show up, but as a sphere, not the shape that I'm
shooting for.
Puzzling.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/11/23 16:01, Bald Eagle wrote:
> Anyone have any ideas?
I'm in the middle of another code tangle, but...
After the lemon was added and we started to bang on it, a few numerical
issues turned up. I think most of this was discussed for a time on the
developer mailing list. No idea what is fixed. What might github have...
Looks like https://github.com/POV-Ray/povray/pull/358 has a little on
the lemon if you scroll down through the comments. Well, I suppose not
would help you near term of that work in any case.
A reminder the f_torus inbuilt function implements a couple of the
spindle modes though it is not directly documented anywhere that I know
about. See post to povray.binaries.images
Subject: Some v38 torus vs f_torus() information.
Date: 30 Apr 2020 08:32:29
https://news.povray.org/povray.binaries.images/thread/%3C5eaac55d%241%40news.povray.org%3E/
Message: <5eaac55d$1@news.povray.org>
Running your scene with my current development povr code, and without
sturm(a), I get the attached a result.
Bill P.
(a) - With sturm on I get a tiny nub on the ends bringing the height to
to about where the left and right shapes are. Without it it 'looks' like
the shape is a little more rounded at the ends than your equivalents.
Might be there is still some other numerical stuff going on... It's not
the easiest shape for the solvers.
Post a reply to this message
Attachments:
Download 'be.png' (53 KB)
Preview of image 'be.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/11/23 23:47, William F Pokorny wrote:
> It's not the easiest shape for the solvers.
Ah, and you are using an orthographic camera. This often the worst case
ray set up for the solvers. Other shapes like the sphere_sweep have
similar issues with the orthographic camera. Your' also positioning well
away it looks too.
If I step an ortho camera back just -2 in z and code as the lemon:
#declare r = 1;
#declare R = 0.6;
#declare Y = sqrt ( r*r - R*R );
lemon {
<0, -Y, 0>, 0, <0, Y, 0>, 0, r
texture {pigment {rgb <0.2, 0.2,0>} finish {specular 0.4}}
sturm
translate <-.1,0,-.1>
}
I get the attached image.
The ray length matters in that the longer it travels the more the
accuracy of the ray->surface equation degrades in accuracy. The equation
has to represent all those useless potential landing steps on the way to
the shapes surface and this burns up the floating point accuracy.
That bit was my painful discovery discussed in the previously referenced
github issue. I have a solution for best possible floating point
hardware accuracy, but the implementation is not trivial...
Bill P.
Post a reply to this message
Attachments:
Download 'behmm.png' (29 KB)
Preview of image 'behmm.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William F Pokorny <ano### [at] anonymousorg> wrote:
Haha! Your previous post jogged something in my memory that provides a truly
trivial solution.
> Ah, and you are using an orthographic camera.
Yes. Any time you see me doing graphs and drafting layout lines, there's a 99%
chance it's an orthographic camera.
> This often the worst case
> ray set up for the solvers. Other shapes like the sphere_sweep have
> similar issues with the orthographic camera.
> Right. I hammer through so many exploratory idea and experiments that my default is
a copy-paste from one of the 20
last-working-scene tabs that I have open in the editor.
> Your' also positioning well away it looks too.
IIRC, it was the single-image photogrammetry where I had an issue with all my
stuff disappearing because it hadn't damned on me how LARGE the objects were,
and therefore how far back they extended (past the camera plane). So yeah,
it's WAAAAAY back. I'll try to keep those under-the-hood issues about the
solver and the camera distance in mind.
> The ray length matters in that the longer it travels the more the
> accuracy of the ray->surface equation degrades in accuracy. The equation
> has to represent all those useless potential landing steps on the way to
> the shapes surface and this burns up the floating point accuracy.
Perhaps an interesting thing to have available in povr would be a "global
bounding box" for the scene in the render statistics. It could help clue scene
authors in to overlooked distance issues and maybe help track down spuriously
placed objects, as well as resolve other weird issues.
Still not sure what the crud on my isosurface is that gets removed with the
FudgeFactor. I'll make a quick switch to the perspective camera and see if it
goes away.
On to the trivial solution.
Spindle torus, did you say?
"The merge and intersection spindle modes have long existed with the f_torus,
but via value arguments."
Well, they've long existed for the regular torus primitive too.
Which I had discovered, and therefore "knew", but forgot.
http://news.povray.org/povray.binaries.misc/message/%3C604613ed%241%40news.povray.org%3E/#%3C604613ed%241%40news.povray
.org%3E
https://wiki.povray.org/content/Reference:Torus
and so, adding
torus {R, r intersection texture {pigment {rgb z} finish {specular 0.4}}
translate x*2*r}
gives me just what I was looking for.
"Oh, POV-Ray developers, you understand everything!" :)
Post a reply to this message
Attachments:
Download 'lemon.png' (65 KB)
Preview of image 'lemon.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> First, when I try to render the lemon {} object with the current parameters, I
> only get a very faint speckling rather than a well-formed surface.
The speckling was even worse for me.
By changing the camera to 'perspective' and with location <0,0,-.7>, I see the
nice lemon shape. Also, I don't see any difference re: sturm vs. no sturm.
>
> The other issue is that the isosurface seems to have the interior_texture
> on the outside, and the texture on the inside.
>
As an experiment, I negated your spindle function...
#declare Iso =
isosurface {
function {-Spindle (x, y, z)}...
and the interior/exterior textures look correct now. A clue to something?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
> By changing the camera to 'perspective' and with location <0,0,-.7>, I see the
> nice lemon shape. Also, I don't see any difference re: sturm vs. no sturm.
I did the same but needed to remove the fudge factor to transition from the
sphere to the lemon.
My isosurface still need the fudge factor, else I still have the cylinder of
crud.
> and the interior/exterior textures look correct now. A clue to something?
It's just the sign. I was just wondering if the native implementation of the
torus was "wrong", since I recall the uv-mapping being off compared to most
other shapes.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/12/23 08:45, Bald Eagle wrote:
> IIRC, it was the single-image photogrammetry where I had an issue with all my
> stuff disappearing because it hadn't damned on me how LARGE the objects were,
> and therefore how far back they extended (past the camera plane). So yeah,
> it's WAAAAAY back. I'll try to keep those under-the-hood issues about the
> solver and the camera distance in mind.
With the orthographic camera, the distance doesn't matter with respect
to the size of scene things. The size of the orthographic camera plane /
rectangle does matter - and that the plane be back a small distance from
all the objects and bounding in the scene.
The location of the camera's ray shooting plane can be very close to
objects. The orthographic camera rays are more difficult for the
solvers, as a rule we should position the orthographic cameras close to
the objects in the scene.
My (-z / looking toward +z) orthographic camera code is:
//---
#declare VarOrthoMult =
5.0/max(image_width/image_height,image_height/image_width);
#declare Camera01z = camera {
orthographic
location <0,0,-2>
direction z
right VarOrthoMult*x*max(1,image_width/image_height)
up VarOrthoMult*y*max(1,image_height/image_width)
}
//---
To see a larger part of the x/y plane in the scene, I change that 5.0
multiplier to something larger.
---
The spindle modes of the regular torus were added to v3.8 and have now
existed some years (4-5 give or take?), the f_torus modes came with the
addition of functions, the isosurface object and the function vm - which
I think goes back to v3.5. Those working in v3.7 would have only the
f_torus spindle options available. The lemon too isn't there in v3.7
being new in v3.8.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/12/23 10:30, Bald Eagle wrote:
> It's just the sign. I was just wondering if the native implementation of the
> torus was "wrong", since I recall the uv-mapping being off compared to most
> other shapes.
You remember correctly. :-)
IIRC think we found the torus 'uv_mapping' reversed (handedness)
compared to all other uv mapping in POV-Ray. It was for a short time
corrected, but then restored to what it had been since v3.7 to maintain
compatibility with old scenes. IIRC povr stuck with the corrected uv
mapping - but that memory of mine might be wrong...
Aside: It's also true the new 'uv_mapping' added to additional shapes
for v3.8/v4.0 was turned back off for other general 'uv_mapping'
concerns. This is one place where our current v3.8 documentation does
not align with the real state of v3.8 - the last I checked. In pulling
back the newer 'uv_mapping' I 'think' povr did too in the moment,
thinking a fix would soon be adopted - but that never happened and I
believe povr aligns with v3.8/v4.0.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William F Pokorny <ano### [at] anonymousorg> wrote:
> My (-z / looking toward +z) orthographic camera code is:
I also have a usage question with regard to orthographic:
I did not seem to be able to get this particular inclusion of the "angle"
keyword to work as described, but maybe I didn't try hard enough, or my camera
{} block was malformed. It would make my life easier instead of having to
switch between 2 different cameras and define (guess at) a Zoom value, like I do
now.
https://wiki.povray.org/content/Reference:Camera#Orthographic_projection
If, in a perspective camera, you replace the perspective keyword by orthographic
and leave all other parameters the same, you will get an orthographic view with
the same image area, i.e. the size of the image is the same. The same can be
achieved by adding the angle keyword to an orthographic camera. A value for the
angle is optional. So this second mode is active if no up and right are within
the camera statement, or when the angle keyword is within the camera statement.
....
Note: The length of direction is irrelevant unless angle is used. The lengths of
up and right define the dimensions of the view. The angle keyword can be used,
as long as less than 180. It will override the length of the right and up
vectors (the aspect ratio between up and right will be kept nevertheless) with a
scope of a perspective camera having the same direction and angle.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
