 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] anonymous org> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/12/23 13:41, Bald Eagle wrote:
> 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.
My only experience using orthographic & angle was first setting up a
perspective view of solver test cases - where the camera needs be a
significant distance away with smaller angles. Then I'd flip perspective
to orthographic to get the, much harder for ray->surface equations and
solver, ortho rays as another test case. For me all I did was flip the
camera types... I've got no experience with more.
Where the documentation says:
"Note: The length of direction is irrelevant unless angle is used." is
true only in an abstract sense. While not the direction vector length,
the actual length of the ray in that direction absolutely matters with
respect to how well many shapes work.
If I take my earlier Camera01z set up and change the location to be:
location <0,0,-2*1e3>
I get the attached image of the same identical scene. The ray length
went from ~2 to ~2000.
Bill P.
(a) - To some extent it matters to other camera types(b) (or say light
positions for shooting photons), but in other cases the rays are almost
all coming in at some angle relative to the scene objects - and this
alone helps the ray->surface equations set up and the solvers.
(b) - I had too sovler tests for extremely small angle perspective
cameras 1-2 degrees and these too often turn up equation set up / solver
issues both because the camera rays are nearing orthogonal, but also due
the length.
Post a reply to this message
Attachments:
Download 'behmm.png' (88 KB)
Preview of image 'behmm.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 3/12/23 08:45, Bald Eagle wrote:
> 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.
I'm thinking some about this and unsure how to do it in any general way
that would not often raise false alarms.
> On to the trivial solution.
> Spindle torus, did you say?
I'll write more about accuracy stuff here so folks are not left too
'depressed' about higher order inbuilt shapes like the lemon. ;-)
Attached is another image with three shapes left to right where the
orthographic camera is again pulled back about -2000 from the origin
where the shapes sit. In fact even -2e6 is no problem.
The middle and right shapes are an isosurface, f_torus 'intersect'
spindle and on the right is the torus 'intersect' spindle. A good
question is why do these shapes seem to be immune to the camera set back
(to the long ray length)?
The answer is both shapes have low order container shapes which are in
fact the first intersection. The isosurface shape uses either a box or a
sphere(a) which users specify as the container. The torus internally
creates a bounding sphere which is the first intersection(a).
On the left is again the lemon, but now it works! It does because I did
this:
union {
box { -1,1 pigment {rgbt <0,0,0,1>} } // <--- low order bounding(a)
lemon {
<0, -Y, 0>, 0, <0, Y, 0>, 0, r
texture {pigment {rgb <0.2, 0.2,0>} finish {specular 0.4}}
//sturm
}
translate <-.7,0,-.1>
}
Bill P.
(a) - This kind of outer bounding certainly helps and is often a decent
work-around, but it is not a general solution. For example, when the
shapes themselves are large (big interior) - as the ray->surface
equation and solvers see the shape. Or where the type of csg forces the
from camera intersections.
The union, clear, first shape bounding can also introduce issues /
artefacts with other shapes in the scene because that invisible surface
exists in the scene.
Aside: An attractive argument for representing all shapes with low
order, mesh approximations is those low order (simpler) ray->surface
equations tolerate MUCH longer ray to surface distances on cpu float
hardware.
Post a reply to this message
Attachments:
Download 'behmmisotorusspindle.png' (77 KB)
Preview of image 'behmmisotorusspindle.png'
|
|
| |
| |
|
|
|
|
| |
|
|
