 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2020-05-04 3:56 AM (-4), William F Pokorny wrote:
>
> FYI. I've not recently looked at it, but back in 2006 Bruno Cabasson
> worked up some code for elliptical tori implemented with sphere_sweeps
> and blobs. Perhaps useful to review that work as we look for an
> f_elliptical_torus() or complete parametric solution.
>
> Given we can use blobs as potential patterns in functions/isosurfaces in
> v38, perhaps this a path to something practical for Cousin Ricky?
>
> The sphere_sweep as a general solution is not very attractive in v37 and
> prior due bugs. Situations is better in v38 - and still better in povr
> but the sphere_sweep probably not the fastest.
>
> With both approaches expect tolerances to any math ideal, but perhaps we
> are stuck with a fuzzy result in any case?
Sphere sweeps are unsatisfactory. The attachment shows that the inner
and outer curves are not ellipses. The discrepancy does decrease with
the ratio of the minor radius to the major radii and the eccentricity of
the shape, but I would prefer a mathematical match at all scales.
Post a reply to this message
Attachments:
Download 'why_not_sswp.jpg' (61 KB)
Preview of image 'why_not_sswp.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2020-05-02 9:27 AM (-4), Bald Eagle wrote:
> Hopefully this is to spec.
>
> The green circles are torus{} objects to show that the cross section is indeed
> exactly circular.
>
> Not my best work, and it's only a parametric, not an implicit equation, but
> perhaps I can "implicitize" it.
Converting it to an isosurface with a table gradient will be the hard
part. I don't know what to do with parametrics; I might have put in the
work if they didn't take longer to render than refraction and dispersion
with media and radiosity.
These are some diagrams that I worked out in 2008. They led me to a
quartic equation, which I predicted (but haven't verified) would become
8th order when converted to 3-D. I never did solve the equation. My
last attempt that I remember was in 2010, and those worksheets are
currently in storage (along with most of my possessions) while home
repairs progress(?).
Note that the minor radius does not project to the origin except at the
elliptical vertices and co-vertices.
Even without direct conversion to 3-D, the solution could be adapted for
isosurface ellipses with roughly isodirectional gradients, which could
easily be converted to toroids with RE_fn_Blob2()--although blobbing a
shape that has already been treated with RE_fn_Blob2() would be rather slow.
Also attached is a test of an equation posted by Nicolas George at the
time. It looks remarkably similar to Bill's May 8th fail. Nicolas
appears to have taken exactly the approach that I had rejected, namely
to project the minor radius back to the origin. In fairness to him, I
had not posted my diagrams. His post is at
https://news.povray.org/48fe0ebe%241%40news.povray.org
in response to my thread.
Post a reply to this message
Attachments:
Download 'elliptor-eq.png' (52 KB)
Download 'elliptor-fig.png' (18 KB)
Download 'elliptical_torus-iso.jpg' (72 KB)
Preview of image 'elliptor-eq.png'
Preview of image 'elliptor-fig.png'
Preview of image 'elliptical_torus-iso.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2020-05-02 9:27 AM (-4), Bald Eagle wrote:
> Hopefully this is to spec.
>
> The green circles are torus{} objects to show that the cross section is indeed
> exactly circular.
>
> Not my best work, and it's only a parametric, not an implicit equation, but
> perhaps I can "implicitize" it.
This is a test of an equation posted by Sebastian H in 2006. The shape
appears to be exact, but the max_gradient is a nightmare, and I don't
know how it stable the gradients are. The post is at:
https://news.povray.org/4409cd2a%40news.povray.org
Post a reply to this message
Attachments:
Download 'sebastian-elliptor-test4.jpg' (59 KB)
Download 'sebastian-elliptor-test70-4.jpg' (48 KB)
Preview of image 'sebastian-elliptor-test4.jpg'
Preview of image 'sebastian-elliptor-test70-4.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/8/20 9:29 PM, Cousin Ricky wrote:
> On 2020-05-02 9:27 AM (-4), Bald Eagle wrote:
....
>
> appears to be exact, but the max_gradient is a nightmare, and I don't
> > https://news.povray.org/4409cd2a%40news.povray.org
Ah... Thanks. I would probably not have jumped in knowing all that
ahead. I was only aware of Bruno's work and his only because I was
looking for sphere_sweep and blob test cases for my solver work.
I've captured all the information in my f_torus working directory.
My gut when I first read your list of requirements was that there was
probably no exact solution. That the requirements force some
discontinuity / fuzz. Is this thinking proven wrong somewhere?
I was on a path that solutions like Bruno's were OK / useful enough...
If I run at this again I'll probably try and implement the blob like
solution on the fly as a solution for something I can use.
Sebastian's images mention compares to a mesh. Of what mesh was he
speaking? Something created from an exact solution? Something in your
package somewhere?
Did you see my recent post to povray.general on the parametric
performance being better than we've thought all these years? Default
gradient of 1.0 should be more like 0.001.
Supposing there is an exact solution for the elliptical tori you want.
Any 8th order equation will be somewhat sloppy with respect to solutions
(165 terms were mentioned in the one post. If not sparse...).
My personal interests lean toward something with good gradients in a
range which will play well with all the other stuff I'm doing. Solutions
a little sloppy, but fast, and good enough are OK with me. :-)
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2020-05-09 8:48 AM (-4), William F Pokorny wrote:
> On 5/8/20 9:29 PM, Cousin Ricky wrote:
>> shape appears to be exact, but the max_gradient is a nightmare, and I
>> > https://news.povray.org/4409cd2a%40news.povray.org
>
> Ah... Thanks. I would probably not have jumped in knowing all that
> ahead. I was only aware of Bruno's work and his only because I was
> looking for sphere_sweep and blob test cases for my solver work.
>
> I've captured all the information in my f_torus working directory.
>
> My gut when I first read your list of requirements was that there was
> probably no exact solution. That the requirements force some
> discontinuity / fuzz. Is this thinking proven wrong somewhere?
Based on my work in 2008, I'm pretty sure there is an exact solution.
The key seemed to be in solving a quartic equation, although the
equation itself would not be the whole solution.
> Sebastian's images mention compares to a mesh. Of what mesh was he
> speaking? Something created from an exact solution? Something in your
> package somewhere?
I created the mesh using RoundEdge::RE_Elliptorus_mesh(), then
co-located it with Sebastian's isosurface. The mesh2 is built up in a
parametric fashion using sines and cosines.
> Did you see my recent post to povray.general on the parametric
> performance being better than we've thought all these years? Default
> gradient of 1.0 should be more like 0.001.
No, I haven't see it yet.
> Supposing there is an exact solution for the elliptical tori you want.
> Any 8th order equation will be somewhat sloppy with respect to solutions
> (165 terms were mentioned in the one post. If not sparse...).
I'm aware of that. I even wrote a JavaScript that shows me the POV-Ray
order of coefficients for the poly object, although it has since been
rendered redundant by 3.7's new polynomial syntax.
Every poly I've had occasion to use has been sparse. While I don't have
an intuitive feel for these things, I don't see why an elliptical toroid
would break this pattern.
> My personal interests lean toward something with good gradients in a
> range which will play well with all the other stuff I'm doing. Solutions
> a little sloppy, but fast, and good enough are OK with me. :-)
I guess I could take "good enough" if it can sneak by our eyes'
simultaneous contrast. But simultaneous contrast is surprisingly
sensitive. The attached renders of the lever cap cam of a hand plane
use deformations of an isosurface oblong toroid that was "good enough,"
but it is easy to see the mismatch between the toroid and the scaled
cylinder. This was a few months before my initial upload of RoundEdge;
I was hopeful of finding a solution, but decided to post the module
without the toroid rather than include a poor solution.
Post a reply to this message
Attachments:
Download 'cam-blob.jpg' (13 KB)
Download 'cam-oblique.jpg' (17 KB)
Preview of image 'cam-blob.jpg'
Preview of image 'cam-oblique.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/9/20 12:07 PM, Cousin Ricky wrote:
> On 2020-05-09 8:48 AM (-4), William F Pokorny wrote:
...
Ah, blast. Thank you for posting those 'lever cap cam' images.
Wondering in this moment if the 'failed' attempts were me having the
wrong visual expectation for what you need. Pretty sure what you need
has to pinch between the orthogonal axes for that lever thing. I've been
working against that result.
Let me see if I can get a test set up going with a parametric as the
reference.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
OK folks,
This is certainly challenging, but bit by bit, I think we're drawing closer to
figuring out where the difficulty is, and what is needed to overcome it.
I would be very interested in seeing the quartic equation, or at least the best
recollection of how it was derived.
As [creepily] often happens, I've had this tab open in my browser for quite some
time, but with the shader autoplay blocked by Brave, I didn't fully grasp what
it was about.
https://www.iquilezles.org/www/articles/distance/distance.htm
This was very exciting to me, as it solves some problems I've had with sine
waves and offset curves.
But as you can see, it also fixes the scaling of the thickness of an ellipse.
You can imagine this being used to fix a torus scaled into an elliptical torus.
https://www.shadertoy.com/view/MdfGWn
https://www.shadertoy.com/view/4tSfRz
I worked on it for a while, and got the simple 2D ellipse to work nicely, but
the 3D extrapolation to the torus didn't quite work out.
But then I thought - if one method is "off" one way, and this method is "off"
the other, .... then what happens if I blend them - will they cancel each other
out?
Almost.
What I've noticed while playing with parameters is that as Ricky observed, the
errors are accentuated by eccentricity and minor radius size. Those errors seem
to be a shrinking effect in my original isosurface, and an expansion in the new
equation. That error seems to be due to too much "z" at the ends, which then
tapers off as the curve approaches the z axis.
I haven't gotten the numerical gradient correction to work properly (yet), but
the approach makes sense, it feels like the right way to go due to its
simplicity, and most of my experiments had a max_gradient around 26.
The attached render has a gradient of 1770, but I rendered it with a holdover
value of only 355.
Post a reply to this message
Attachments:
Download 'implicitellipticaltorus_modgrad.png' (186 KB)
Preview of image 'implicitellipticaltorus_modgrad.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscape net> wrote:
> This was very exciting to me, as it solves some problems I've had with sine
> waves and offset curves.
> But as you can see, it also fixes the scaling of the thickness of an ellipse.
> You can imagine this being used to fix a torus scaled into an elliptical torus.
AND .... this same approach was implemented by ... user And in 2013 to make
constant-thickness isosurface shells.
http://news.povray.org/povray.binaries.images/thread/%3Cweb.5264d1b954cff585cc1fd1150%40news.povray.org%3E/?ttop=423056
&toff=750&mtop=423452&moff=10
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Whereupon Tor Olav Kristensen made a whopping follow-up post:
http://news.povray.org/povray.binaries.images/message/%3Cweb.5b5e768edce0719a79917fa00%40news.povray.org%3E/#%3Cweb.5b5
e768edce0719a79917fa00%40news.povray.org%3E
Especially interesting, with regard to the f_r function and fn_Gradient macro.
That ties in to the calculation of normals and using the object pattern in an
isosurface.
I suppose I'll also do a little light reading about the Laplacian operator and
the elliptic operator, since they are directly related. ;)
With regard to the elliptical torus, I'm not exactly sure what throws off the 3D
shape. With the standard circular torus, we just use R minus the length of the
x,z vector to get one side of the right triangle to evaluate the minor radius'
circle, and y becomes the other.
Generalizing this to an ellipse really seems like it should work without issue,
but obviously it doesn't.
It seems that any circle "drawn" ought to be in the plane bisecting the angle
formed by the two foci and the point on the ellipse.
It also seems like there's trend where the torus extends outward too much in the
direction of the longest semi-axis, and not enough in the shortest semi-axis.
Which leads me to intuitively believe that there ought to be a way to use a and
b to compensate for how the torus gets thrown off.
And that's all I have for now.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/15/20 2:09 PM, Bald Eagle wrote:
> Whereupon Tor Olav Kristensen made a whopping follow-up post:
>
...
>
> And that's all I have for now.
>
Unsure how helpful, but I'd read in the past supertoroids a good way to
create various csg modeling shapes.
Along with other work brought up a parametric supertoroid alongside a
parametric of Cousin Ricky's include macro. The latter is a subset of
the former's function! See the attached image(2).
Good news, right... We can find, half a dozen, slightly different,
supposed, implicit equations in books, papers and the web for
supertoroids. Another day plus of struggle and I've not a single attempt
that does the a, b scaling correctly - most equations have other issues
too(3). I'm struggling with gradients in all of the implicit forms,
which makes trying ideas slow(4).
Aside:
----
I made an attempt too using my updated f_ellipsoid function creating
first an x,y shell with the proper scaling. Used my new f_multiply1to8
to get something torus like as well as some other forms.
The issue - perhaps like that you were up against in one of your posts -
is, while the surface (the roots) with respect to x,y are in the
correct(1) places, the gradients 'inside' are not of uniform value
around the ring. To a first order the multiplication affects z around
the ring, but I suspect the gradients are also not symmetrical about the
central supertorus axis. Not been able to come up with the right
corrections for even the first order z issue - yet again. :-)
If you or I get this going, Ricky's invoice is going to huge! :-)
Bill P.
(1) - Getting a supertoroid implicit which matches in every respect the
parametric one a worthy goal no matter, but I worry some whether the
resulting super torus will always be the right shape. I think it likely
depends on the approach taken with the rest of the 'csg' - and perhaps
some of the forms you've come up with might be what's needed.
(2) - Differences shown at a 2x multiple. These are due using compute
depths of 8 and 18 with other accuracy items the same. Not too
surprising, but interesting to see.
(3) - The function's terms and how they play with C++/SDL ones given
different e1/e2 parameters is tricky (abs() is your friend). Yep,
possible one or more forms is correctly as presented and it's me not
getting something right.
(4) - Isosurfaces, when not just slow, suddenly blinking out of
existence all or in part. It's as much the problem as slow renders and
forces high gradient settings 500, 1000 or to avoid.
Post a reply to this message
Attachments:
Download 'supertor_chapter7.jpg' (51 KB)
Preview of image 'supertor_chapter7.jpg'
|
|
| |
| |
|
|
|
|
| |
|
|
