 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hello.
First of all, there's no torus in this picture !
I spent a lot of time trying to figure out why my isosurface wasn't
showing. So I added the "max_gradient" parameter. I started with 10.
Each time I tried, POV told me that the max_gradient found was too low.
I had to set *3e10* for it to be ok.
Ouch!!! What justifies such a gigantic max_gradient?
The function is :
function {
(sq(sqrt(x*x + y*y) - 3) + z*z - 0.4 ) *
(sq(sqrt((x - 4.5)*(x - 4.5) + z*z) - 3) + y*y - 0.4) *
(sq(sqrt((x + 4.5)*(x + 4.5) + z*z) - 3) + y*y - 0.4) *
(sq(sqrt((y + 4.5)*(y + 4.5) + z*z) - 3) + x*x - 0.4) *
(sq(sqrt((y - 4.5)*(y - 4.5) + z*z) - 3) + x*x - 0.4) *
(sq(sqrt(x*x + y*y) - 5) + z*z - 0.4 )
}
--
Kurtz le pirate
Compagnie de la Banquise
Post a reply to this message
Attachments:
Download 'chain.png' (51 KB)
Preview of image 'chain.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
kurtz le pirate <kur### [at] gmail com> wrote:
> Ouch!!! What justifies such a gigantic max_gradient?
What is a gradient?
I would would speculate that since you have 6 terms that define 6 separate and
distinct surfaces, that you have a lot of discontinuity in that equation.
And this is why we can't use the object pattern as a function for an isosurface
very well, because it has an "infinite" gradient right where the object stops
and nothing begins.
I'll bet that if you made graphs of the x, y, and z directions you'd see what I
mean. Do central differences to calculate a slope.
I would also imagine that if you broke that equation up into 6 separate
isosurfaces, they would all behave a lot better.
- BE
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/4/24 13:13, kurtz le pirate wrote:
> What justifies such a gigantic max_gradient?
Multiplication in an isosurface function tends to be a bad choice(*).
Even with linear functions you have values larger than 1.0 some distance
away from the surface roots. You are multiplying six torus equations and
suppose at a distance a few units away from the cluster they all have a
value of 10. So the equation's values are as high as 10^6 - at distance.
Now think about what happens at each root. The values for one of the six
tori rapidly approaches zero and at zero the entire equation winks to
zero before climbing rapidly again out of the negative value region.
Though the values near the roots will be < 1.0, the change from very
large values to and from the root as the ray travels, will be rapid.
Change your equation to:
min(
(sq(sqrt(x*x + y*y) - 3) + z*z - 0.4 ),
(sq(sqrt((x - 4.5)*(x - 4.5) + z*z) - 3) + y*y - 0.4),
(sq(sqrt((x + 4.5)*(x + 4.5) + z*z) - 3) + y*y - 0.4),
(sq(sqrt((y + 4.5)*(y + 4.5) + z*z) - 3) + x*x - 0.4),
(sq(sqrt((y - 4.5)*(y - 4.5) + z*z) - 3) + x*x - 0.4),
(sq(sqrt(x*x + y*y) - 5) + z*z - 0.4 )
)
And the gradients will be much lower. Note, however, the value fields
now overlap each other so there will minor-ish discontinuities due this.
It's often the case you can cheat lower than the reported max gradient
when using min() or max(). These sorts of value "discontinuities" are
more like seams (inflections in values) away from the roots - and they
don't matter that much so long as you set the gradient (sampling rate)
high enough to not miss any roots(**) as the solver runs.
(*) - The yuqk fork implemented an f_cbrt() inbuilt function wrapping
C++'s std::cbrt(). This can wrap functions with high gradients in one or
more cube roots which lowers the effective gradient as seen by the
solver. (Sometimes, using multiplication is handy. Yes, I lie all the
time... :-) )
(**) - This why the yuqk fork added the 'report on|off' keyword to the
isosurface{}. The gradient warnings can be turned off for particular
isosurfaces, if the isosurface is otherwise rendering fine with a
gradient lower than the actual max gradient.
Bill P.
Aside: I've been thinking some about the isosurface{} feature of late.
Maybe adding options to return only the containing shape's clipped roots
- it would be the opposite of 'open'(***). Further, perhaps an option to
return only a range of all the roots found. This would let us break
apart the surfaces in a way would allow flexible texturing and offer a
way to gradually see isosurface{}s layer by layer, so to speak.
(***) - Having a complement keyword to 'open', I suppose, could apply to
all shapes supporting 'open' today? It would make texturing clipped
parts in ways completely different than the sides of those shapes much
easier.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 05/05/2024 00:48, William F Pokorny wrote:
> On 5/4/24 13:13, kurtz le pirate wrote:
>> What justifies such a gigantic max_gradient?
>
> Multiplication in an isosurface function tends to be a bad choice(*).
>
> Even with linear functions you have values larger than 1.0 some distance
> away from the surface roots. You are multiplying six torus equations and
> suppose at a distance a few units away from the cluster they all have a
> value of 10. So the equation's values are as high as 10^6 - at distance.
>
> Now think about what happens at each root. The values for one of the six
> tori rapidly approaches zero and at zero the entire equation winks to
> zero before climbing rapidly again out of the negative value region.
> Though the values near the roots will be < 1.0, the change from very
> large values to and from the root as the ray travels, will be rapid.
>
> Change your equation to:
>
> min(
> (sq(sqrt(x*x + y*y) - 3) + z*z - 0.4 ),
> (sq(sqrt((x - 4.5)*(x - 4.5) + z*z) - 3) + y*y - 0.4),
> (sq(sqrt((x + 4.5)*(x + 4.5) + z*z) - 3) + y*y - 0.4),
> (sq(sqrt((y + 4.5)*(y + 4.5) + z*z) - 3) + x*x - 0.4),
> (sq(sqrt((y - 4.5)*(y - 4.5) + z*z) - 3) + x*x - 0.4),
> (sq(sqrt(x*x + y*y) - 5) + z*z - 0.4 )
> )
>
> And the gradients will be much lower. Note, however, the value fields
> now overlap each other so there will minor-ish discontinuities due this.
> It's often the case you can cheat lower than the reported max gradient
> when using min() or max(). These sorts of value "discontinuities" are
> more like seams (inflections in values) away from the roots - and they
> don't matter that much so long as you set the gradient (sampling rate)
> high enough to not miss any roots(**) as the solver runs.
>
> (*) - The yuqk fork implemented an f_cbrt() inbuilt function wrapping
> C++'s std::cbrt(). This can wrap functions with high gradients in one or
> more cube roots which lowers the effective gradient as seen by the
> solver. (Sometimes, using multiplication is handy. Yes, I lie all the
> time... :-) )
>
> (**) - This why the yuqk fork added the 'report on|off' keyword to the
> isosurface{}. The gradient warnings can be turned off for particular
> isosurfaces, if the isosurface is otherwise rendering fine with a
> gradient lower than the actual max gradient.
>
> Bill P.
>
>
> Aside: I've been thinking some about the isosurface{} feature of late.
> Maybe adding options to return only the containing shape's clipped roots
> - it would be the opposite of 'open'(***). Further, perhaps an option to
> return only a range of all the roots found. This would let us break
> apart the surfaces in a way would allow flexible texturing and offer a
> way to gradually see isosurface{}s layer by layer, so to speak.
>
> (***) - Having a complement keyword to 'open', I suppose, could apply to
> all shapes supporting 'open' today? It would make texturing clipped
> parts in ways completely different than the sides of those shapes much
> easier.
>
Your explanation is clear. Well done.
Well, it's true that this kind of equation is rather special and
contains a lot of "empty space".
Multiplying isosurfaces is generally used to make blobs. No need here.
On the other hand, the min() function is the equivalent of union{} and
is much better adapted.
Without changing the value of max_gradient (3e10) and just by adding the
min() in my function, POV finds say : "The maximum gradient found was
4235539.500, but max_gradient of the isosurface was set to
30000001024.000...".
Thanks
--
Kurtz le pirate
Compagnie de la Banquise
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/5/24 06:07, kurtz le pirate wrote:
> Without changing the value of max_gradient (3e10) and just by adding the
> min() in my function, POV finds say : "The maximum gradient found was
> 4235539.500, but max_gradient of the isosurface was set to
> 30000001024.000...".
Alright. Though, that feels to me like too large a max gradient for the
min() approach! Let me try quickly here.
A truth with isosurface{}s, is that setting higher gradients tends to
find higher gradients. A reason is often rays glancing off, or just
catching, the far edges of shapes.
Another truth is that max gradients seen are not constant with respect
to incoming rays.
---
At 10 (Which for me looks OK. See attached image) I see:
The maximum gradient found was 13.001, but max_gradient of the
isosurface was set to 10.000. ...
---
At 1e5 (I don't have the patience for more on my little i3) I see:
The maximum gradient found was 18.814, but max_gradient of the
isosurface was set to 100000.000. ...
I'm unsure what's happening with your version of the scene to see the
much larger max gradient with min(). Maybe your bounding box is much
larger than it need be? I don't know.
I'm attaching my version of the scene. I used yuqk, but I don't think
I've changed anything in the solver which would account for difference
in max gradients seen.
Do you see differences between your scene and mine which might account
for the difference in max gradients? I'm willing to do the digging, if
you'll post your version of the scene. I'd like to understand what I'm
missing.
Bill P.
Post a reply to this message
Attachments:
Download 'tmp.png' (42 KB)
Download 'tmp.pov.txt' (2 KB)
Preview of image 'tmp.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 05/05/2024 20:48, William F Pokorny wrote:
> I'm attaching my version of the scene. I used yuqk, but I don't think
> I've changed anything in the solver which would account for difference
> in max gradients seen.
>
> Do you see differences between your scene and mine which might account
> for the difference in max gradients? I'm willing to do the digging, if
> you'll post your version of the scene. I'd like to understand what I'm
> missing.
Your scene works perfectly. Same image as in your post.
Render time about 6 seconds. I don't think you missed a thing.
My scene (attached) is always bad with with delirious values for
max_gradient. Differences are :
- My container is a sphere : contained_by { sphere { <0,0,0>, 9 } }
- Function is inside isosurface {}
- I have no "threshold" and no "accuracy".
- I remove sky_sphere
- I remove finish{}
Nothing really decisive :(
Lower (normal) value for max_gradient don't render object
Last thing, my version :
Persistence of Vision(tm) Ray Tracer Version
3.8.0-alpha.9945627.unofficial (
Compiler: 4.2.1 Compatible Apple LLVM 10.0.0 (clang-1000.11.45.5))
Might be buggy ?
--
Kurtz le pirate
Compagnie de la Banquise
Post a reply to this message
Attachments:
Download 'notorus.pov.txt' (3 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
kurtz le pirate <kur### [at] gmailcom> wrote:
> Hello.
>
> First of all, there's no torus in this picture !
Is there a reason you are avoiding f_torus()?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
kurtz le pirate <kur### [at] gmailcom> wrote:
> ...
> Lower (normal) value for max_gradient don't render object
yes, no object with value '100'. run with the scene as posted finds a max of
'29882873856'.
> Last thing, my version :
> Persistence of Vision(tm) Ray Tracer Version
> 3.8.0-alpha.9945627.unofficial (
> Compiler: 4.2.1 Compatible Apple LLVM 10.0.0 (clang-1000.11.45.5))
> Might be buggy ?
I used the 'beta.2' version.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
No mention of the evaluate keyword yet?
https://wiki.povray.org/content/Documentation:Tutorial_Section_4.1#Isosurface_not_rendering_properly.3F
https://wiki.povray.org/content/Reference:Isosurface
- BW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/6/24 10:27, kurtz le pirate wrote:
> Lower (normal) value for max_gradient don't render object
>
> Last thing, my version :
> Persistence of Vision(tm) Ray Tracer Version
> 3.8.0-alpha.9945627.unofficial (
> Compiler: 4.2.1 Compatible Apple LLVM 10.0.0 (clang-1000.11.45.5))
>
>
> Might be buggy ?
Thank you for the information and scene SDL. I'll let you know what I find.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/6/24 11:56, jr wrote:
> I used the 'beta.2' version.
Thank you for running & reporting what you saw. A mystery - of an
unfortunate kind.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/6/24 12:18, Bald Eagle wrote:
> No mention of the evaluate keyword yet?
The evaluate keywords has thread safety issues in v3.7+ versions of
POV-Ray(1).
In my experience it mostly ran much less well in recent POV-Ray official
versions over not using it at all - because it wasn't really working.
It's been stripped from the yuqk fork code.
Hmm. Suppose it's possible that code existing, might somehow be causing
other problems in official releases...
Bill P.
(1) - Maybe evaluate would run OK if using only one thread. Unsure.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/6/24 11:56, jr wrote:
> yes, no object with value '100'. run with the scene as posted finds a max of
> '29882873856'.
Hi jr, The scene, as posted, was the original without the suggested
min() wrapper - which we expect to have a very large max gradient.
Would you be kind enough to run the following version of the function on
your machine to verify you too see a much, much lower gradient?
min(
(sq(sqrt(x*x + y*y) - 3) + z*z - 0.4 ) ,
(sq(sqrt((x - 4.5)*(x - 4.5) + z*z) - 3) + y*y - 0.4) ,
(sq(sqrt((x + 4.5)*(x + 4.5) + z*z) - 3) + y*y - 0.4) ,
(sq(sqrt((y + 4.5)*(y + 4.5) + z*z) - 3) + x*x - 0.4) ,
(sq(sqrt((y - 4.5)*(y - 4.5) + z*z) - 3) + x*x - 0.4) ,
(sq(sqrt(x*x + y*y) - 5) + z*z - 0.4 )
)
// Rather than the posted:
// (sq(sqrt(x*x + y*y) - 3) + z*z - 0.4 ) *
// (sq(sqrt((x - 4.5)*(x - 4.5) + z*z) - 3) + y*y - 0.4) *
// (sq(sqrt((x + 4.5)*(x + 4.5) + z*z) - 3) + y*y - 0.4) *
// (sq(sqrt((y + 4.5)*(y + 4.5) + z*z) - 3) + x*x - 0.4) *
// (sq(sqrt((y - 4.5)*(y - 4.5) + z*z) - 3) + x*x - 0.4) *
// (sq(sqrt(x*x + y*y) - 5) + z*z - 0.4 )
With the bounding sphere of radius 9 I'm seeing less than 10 on all
recent versions of official POV-Ray and yuqk I have in hand. I'd like to
know you too see the really low gradient too and not just a lower, but
still quite large max gradient with the min() wrap.
I've not tried a clang compile yet. Off to do that - in part because
I've not done a clang compile of yuqk in long while...
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
William F Pokorny <ano### [at] anonymousorg> wrote:
> ...
> Would you be kind enough to run the following version of the function on
> your machine to verify you too see a much, much lower gradient?
>
> min(
> (sq(sqrt(x*x + y*y) - 3) + z*z - 0.4 ) ,
> (sq(sqrt((x - 4.5)*(x - 4.5) + z*z) - 3) + y*y - 0.4) ,
> (sq(sqrt((x + 4.5)*(x + 4.5) + z*z) - 3) + y*y - 0.4) ,
> (sq(sqrt((y + 4.5)*(y + 4.5) + z*z) - 3) + x*x - 0.4) ,
> (sq(sqrt((y - 4.5)*(y - 4.5) + z*z) - 3) + x*x - 0.4) ,
> (sq(sqrt(x*x + y*y) - 5) + z*z - 0.4 )
> )
much faster render, much lower gradient. gave (again) value '100', the beta.2
now reports "maximum gradient found was 12.207, ...". nice.
cheers.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jr" <cre### [at] gmailcom> wrote:
> ...
> much faster render, much lower gradient. gave (again) value '100', the beta.2
> now reports "maximum gradient found was 12.207, ...". nice.
fwiw, ran same with alpha.9945627 (over breakfast :-)), and got same gradient /
result.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/6/24 15:35, William F Pokorny wrote:
> I've not tried a clang compile yet. Off to do that - in part because
> I've not done a clang compile of yuqk in long while...
The clang results for max gradients with min() are also all <<20.
---
That said, I found the clang++ compile broken! :-( While coding up a few
of of the vm inbuilt functions I used code like:
constexpr double Cn = 4.0*std::exp(-0.5)/std::sqrt(2.0); // **
which works with gnu compilers c+11 and later, but does not in today's
mainstream c++ versions for clang++. I knew there were differences in
what basic functions could be used in constant expressions, but I
somehow fooled myself into thinking clang++ was OK with those two (they
are officially available in later c++ standards).
The fix is to hard code the resultant values from exp() and sqrt() and
the fixes will be in the next yuqk release (R15).
(**) - The why of this approach is, in part, related to the fact POV-Ray
today defines many macro constants with MORE than double precision
digits as well as others at double precision. What I suspect is that
this mixed precision constant habit is sometimes not numerically
optimal, but I've never found the time to prove / disprove the thought.
---
Once the clang compile issue was fixed, I happened to notice that so
long as the clang++ configuration was run with the flag
'-fgnuc-version=5' to set internally to clang++ __GNUC__, I got Intel's
hand coded noise optimization for my i3. I didn't expect this to happen,
though maybe it is the right result.
The (perhaps bogus) story I've been carrying around in my head is that
the gnu g++ compile used to do the same dynamic optimization, but for at
least a couple years now, it has not... It's one of the issues on my
infinite to-do list.
So, the dynamic optimization situation on my i3 is today confusing /
worrying? The clang++ compile has the dynamic optimization:
Dynamic optimizations:
CPU detected: Intel,SSE2,AVX,AVX2,FMA3
Noise generator: avx2fma3-intel (hand-optimized by Intel)
While the g++ compile has the dynamic optimization:
Dynamic optimizations:
CPU detected: Intel,FMA3,FMA4
Noise generator: generic (portable)
The latter is safe, but likely not optimal. The clang++ compile is
finding the correct features for my i3.
Add to this, that in my testing back when clipka first ported the AMD
and Intel hand optimizations to the Linux / Unix builds, the optimized
code was only sometimes (the benchmark scene being one) faster on my i3.
It sometimes tested slower than the generic (using -march=native) too.
Quickly on the biscuit.pov scene today, clang's dynamic optimization is
2.3% faster than a -march=native compile.
Aside: clang native is currently 4.2% faster the g++ native with
relatively basic optimization flags, but knowing learning why is always
a time consuming trick and which is faster tends to change over time.
Lastly, since I rendered different versions of output png files while
looking at performance, I did image comparisons. The clang++ native vs
avx2fma3-intel results matches exactly - as should be. The interesting
bit is the g++ native vs clang++ native mismatched by 1/255 on two
pixels. :-)
Anyhow...
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/7/24 02:03, jr wrote:
> much faster render, much lower gradient. gave (again) value '100', the beta.2
> now reports "maximum gradient found was 12.207, ...". nice.
Thank you!
I got a clang++ compile going too (with issues...), but it's also
reporting the much lower gradient with the min() wrapper.
So, my best guess at the moment - given, kurtz le pirate, reported a
lower max gradient, but one still quite large, is that perhaps what
ended up coded on trying min() in his case was something like:
min(
(SQ(sqrt(x*x + y*y) - 3) + z*z - 0.4 ),
(SQ(sqrt((x - 4.5)*(x - 4.5) + z*z) - 3) + y*y - 0.4),
(SQ(sqrt((x + 4.5)*(x + 4.5) + z*z) - 3) + y*y - 0.4),
(SQ(sqrt((y + 4.5)*(y + 4.5) + z*z) - 3) + x*x - 0.4),
(SQ(sqrt((y - 4.5)*(y - 4.5) + z*z) - 3) + x*x - 0.4) *
(SQ(sqrt(x*x + y*y) - 5) + z*z - 0.4 )
)
It's just a guess but, I'm otherwise out of ideas as to other causes.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/7/24 07:18, William F Pokorny wrote:
> So, the dynamic optimization situation on my i3 is today confusing /
> worrying? The clang++ compile has the dynamic optimization:
>
> Dynamic optimizations:
> CPU detected: Intel,SSE2,AVX,AVX2,FMA3
> Noise generator: avx2fma3-intel (hand-optimized by Intel)
>
> While the g++ compile has the dynamic optimization:
>
> Dynamic optimizations:
> CPU detected: Intel,FMA3,FMA4
> Noise generator: generic (portable)
>
> The latter is safe, but likely not optimal. The clang++ compile is
> finding the correct features for my i3.
For the record.
Yesterday, I found LLVM Project code with comments and code for handling
gcc not accounting for 'cpuid' clobbering of one of the registers.
Though they don't protect the register in the same way, it explains
'some 'of the assembly code in our code base protecting the same
register. Still unsure if this issue really why my g++ compiles don't
use the same optimization as clang++'s.
Looking at what we have, I see all this code is now a bit dated and the
set up is limited in comparison. I'm unsure I want to invest my time in
it - thinking now about removing it all from yuqk as another general
simplification.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 06/05/2024 20:27, William F Pokorny wrote:
> On 5/6/24 10:27, kurtz le pirate wrote:
>> Lower (normal) value for max_gradient don't render object
>>
>> Last thing, my version :
>> Persistence of Vision(tm) Ray Tracer Version
>> 3.8.0-alpha.9945627.unofficial (
>> Compiler: 4.2.1 Compatible Apple LLVM 10.0.0 (clang-1000.11.45.5))
>>
>>
>> Might be buggy ?
>
> Thank you for the information and scene SDL. I'll let you know what I find.
Hello Bill,
Looking at the various answers, I don't think it's a compiler problem
any more. Your code and mine are identical and give the same results for
several people.
I don't think there's any point in you wasting any more time on this
problem unless you really care... For me, it was just a test to adapt
isosurfaces found in "MathMod" to POVRay
<https://sourceforge.net/projects/mathmod/>.
Thank you all for your participation.
--
Kurtz le pirate
Compagnie de la Banquise
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
kurtz le pirate <kur### [at] gmailcom> wrote:
> . . . to adapt
> isosurfaces found in "MathMod" to POVRay
> <https://sourceforge.net/projects/mathmod/>.
Nice - I've played with that before.
I emailed the guy who runs that to find out how he managed:
https://www.deviantart.com/mathmod/art/Straw-Torus-579426225
But I never did get an answer.
Do you understand how all the syntax works?
- BW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 09/05/2024 12:39, Bald Eagle wrote:
> Nice - I've played with that before.
>
LOL
> I emailed the guy who runs that to find out how he managed:
> https://www.deviantart.com/mathmod/art/Straw-Torus-579426225
>
> But I never did get an answer.
>
Same...
It seems that a FaceBook group exists. I don't have an account, so I
don't know if it's still active : <https://www.facebook.com/parisolab/>
> Do you understand how all the syntax works?
Ho no, far from it.
Some syntaxes are really strange and without doc..
--
Kurtz le pirate
Compagnie de la Banquise
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 5/9/24 04:23, kurtz le pirate wrote:
> For me, it was just a test to adapt
> isosurfaces found in "MathMod" to POVRay
> <https://sourceforge.net/projects/mathmod/>
I've not run the application, but I too have spent time trying shapes
others have worked up for it. The f_toupie() inbuilt in my yuqk fork,
both in name and core code, comes from such play! :-)
---
As for chasing the original, "min() max gradient still too high" issue,
I've stopped.
In hindsight, the overall chase was worthwhile for yuqk fork issues of
my own doing. Plus, clang correctly implementing the dynamic CPU
optimization, gave me the means to dig into a longstanding, general
POV-Ray build issue too.
As "code bug hunts" go, this one yielded much. :-)
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
