 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] gmail com> 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
|
|
| |
| |
|
|
|
|
| |
