POV-Ray : Newsgroups : povray.object-collection : RoundEdge 2.0: unequal edge radii Server Time
31 Oct 2024 19:24:15 EDT (-0400)
  RoundEdge 2.0: unequal edge radii (Message 1 to 10 of 12)  
Goto Latest 10 Messages Next 2 Messages >>>
From: Cousin Ricky
Subject: RoundEdge 2.0: unequal edge radii
Date: 29 Apr 2020 17:23:17
Message: <5ea9f045@news.povray.org>
RoundEdge 2.0 now has macros for rounded boxes with unequal edge radii. 
As a bonus, a wrapper is added for POV-Ray's cryptic isosurface evaluate 
feature.

In January of 2016, I posted an update to RoundEdge to correct a torus 
artifact.  More recently, while working on RoundEdge 2.0, I noticed that 
I had made the torus change in February 2015, and didn't post it until 
after clipka mentioned the artifact in December that year.  Why did I 
wait 350 days to post it?

I think it must have been that I was already working on the unequal edge 
radii when I made the torus correction, and planned to roll out the fix 
along with the new feature.  But the unequal edge radii turned out to 
have far more variations than I anticipated, so I put the whole update 
on the back burner--until clipka's comment induced me to rethink holding 
up the torus correction.  A massive toothache in early 2015 may have 
also been a factor in pausing development.

Well, it's 5 years later, and the new unequal edge macros are now 
completed and uploaded.

http://lib.povray.org/searchcollection/index2.php?objectName=RoundEdge&contributorTag=Cousin%20Ricky

An isosurface elliptical toroid is still on my wish list.  Although I've 
already implemented mesh toroids, they cannot be deformed or blobbed. 
Back in 2008, Nicolas George proposed a function which, upon 
implementation, I found unsatisfactory.  (He projected lines from the 
origin through the central ellipse, which I had previously determined to 
be a bad approach.)  In 2006, Sebastian H. posted a function that 
appears to create the exact shape I desire, but I have been unable to 
verify that the gradients are stable.  Stable gradients would be 
essential for isosurface blobbing.


Post a reply to this message

From: William F Pokorny
Subject: Re: RoundEdge 2.0: unequal edge radii
Date: 30 Apr 2020 07:23:22
Message: <5eaab52a$1@news.povray.org>
On 4/29/20 5:23 PM, Cousin Ricky wrote:
> RoundEdge 2.0 now has macros for rounded boxes with unequal edge radii. 
> As a bonus, a wrapper is added for POV-Ray's cryptic isosurface evaluate 
> feature.
> 

Thanks for the update.

I've never gotten to where evaluate is part of my isosurface flow... How 
much does the evaluate feature typically buy you?

In my experiments 10-15% at most - and it's sometimes slower, but I've 
also not stuck with using it. Am I'm missing bigger possible gains?

Suppose my issue with feature is I don't know what it really does beyond 
adjust the gradient on the fly within some bounding(1). The code is 
there, I could figure it out, but given I've never seen big gains...

Aside: v38's optional parameters are tempting additions to your evaluate 
wrapper. :-)

Bill P.

(1) - What happens inside that black box when I play games with ever 
changing (dis-continuous) - or even significantly flat gradients? Tricks 
workable if the roots are kept 'away' from the discontinuities (within 
continuous value regions/envelopes) - and the sampling periodicity is 
high enough over the whole isosurface with respect to rays such that the 
continuous value envelopes are not missed.


Post a reply to this message

From: Cousin Ricky
Subject: Re: RoundEdge 2.0: unequal edge radii
Date: 30 Apr 2020 12:21:42
Message: <5eaafb16$1@news.povray.org>
On 2020-04-30 7:23 AM (-4), William F Pokorny wrote:
> 
> Thanks for the update.

You're welcome.

> I've never gotten to where evaluate is part of my isosurface flow... How 
> much does the evaluate feature typically buy you?
> 
> In my experiments 10-15% at most - and it's sometimes slower, but I've 
> also not stuck with using it. Am I'm missing bigger possible gains?

In my experience it helps with POV-Ray 3.6, but slows things down with 
POV-Ray 3.7--for the same isosurface function!  I once had a mind to ask 
the group about this anomaly, but I never got a round tuit (POVers 
charge a premium for those!), and I cannot find my records of the timing 
statistics.  I don't normally use it, but I believe Thomas de Groot uses 
it a great deal.


Post a reply to this message

From: Bald Eagle
Subject: Re: RoundEdge 2.0: unequal edge radii
Date: 30 Apr 2020 13:30:00
Message: <web.5eab0b0e9fcd114afb0b41570@news.povray.org>
Cousin Ricky <ric### [at] yahoocom> wrote:

> In my experience it helps with POV-Ray 3.6, but slows things down with
> POV-Ray 3.7--for the same isosurface function!  I once had a mind to ask
> the group about this anomaly, but I never got a round tuit (POVers
> charge a premium for those!), and I cannot find my records of the timing
> statistics.  I don't normally use it, but I believe Thomas de Groot uses
> it a great deal.

Hmmm.   I didn't know about the 3.6 to 3.7 issue.

I use it ... maybe 50% of the time?
Because I'm fantastically lazy with experimental / developmental code, and just
copy existing code from whatever file or open tab is closest at hand.

I have been meaning to get 'round to writing a nice concise isosurface code
block for my Insert Menu stuff, but I haven't gotten there yet.   Maybe by
2021...

If I can remember to do it, I can record times for with/without evaluate in the
future.

Maybe I'll just collect a bunch of functions into an array and see if I can
figure out how to record the render times automagically when I run them all as
an animation.

Is there a way to access and record the max_gradient that was found and write
that to a file?


Post a reply to this message

From: Cousin Ricky
Subject: Re: RoundEdge 2.0: unequal edge radii
Date: 30 Apr 2020 23:44:05
Message: <5eab9b05$1@news.povray.org>
On 2020-04-30 1:29 PM (-4), Bald Eagle wrote:
> 
> Is there a way to access and record the max_gradient that was found and write
> that to a file?

The Warning_Console option (+GW) should do it.  But beware that 3.7 
neglects to report the max_gradient under certain conditions.  See:

https://news.povray.org/povray.beta-test/thread/%3Cweb.51c722c522807ec9540235480%40news.povray.org%3E/


Post a reply to this message

From: Thomas de Groot
Subject: Re: RoundEdge 2.0: unequal edge radii
Date: 1 May 2020 02:51:14
Message: <5eabc6e2$1@news.povray.org>
Op 30/04/2020 om 18:21 schreef Cousin Ricky:
> On 2020-04-30 7:23 AM (-4), William F Pokorny wrote:
>>
>> I've never gotten to where evaluate is part of my isosurface flow... 
>> How much does the evaluate feature typically buy you?
>>
>> In my experiments 10-15% at most - and it's sometimes slower, but I've 
>> also not stuck with using it. Am I'm missing bigger possible gains?
> 
> In my experience it helps with POV-Ray 3.6, but slows things down with 
> POV-Ray 3.7--for the same isosurface function!  I once had a mind to ask 
> the group about this anomaly, but I never got a round tuit (POVers 
> charge a premium for those!), and I cannot find my records of the timing 
> statistics.  I don't normally use it, but I believe Thomas de Groot uses 
> it a great deal.

I have not really used 'evaluate' in my isosurfaces. I have played with 
it of course but as far as I can remember, I did not find any 
significant use for it in my scenes. I browsed a couple of them and 
'evalate' is never used.

-- 
Thomas


Post a reply to this message

From: Cousin Ricky
Subject: Re: RoundEdge 2.0: unequal edge radii
Date: 1 May 2020 12:44:35
Message: <5eac51f3$1@news.povray.org>
On 2020-05-01 2:51 AM (-4), Thomas de Groot wrote:
> Op 30/04/2020 om 18:21 schreef Cousin Ricky:
>>
>> In my experience it helps with POV-Ray 3.6, but slows things down with 
>> POV-Ray 3.7--for the same isosurface function!  I once had a mind to 
>> ask the group about this anomaly, but I never got a round tuit (POVers 
>> charge a premium for those!), and I cannot find my records of the 
>> timing statistics.  I don't normally use it, but I believe Thomas de 
>> Groot uses it a great deal.
> 
> I have not really used 'evaluate' in my isosurfaces. I have played with 
> it of course but as far as I can remember, I did not find any 
> significant use for it in my scenes. I browsed a couple of them and 
> 'evalate' is never used.

Hmmmm.  Perhaps I'm mixing you up with one of the many POVers doing 
Landscapes Of The Week many years ago.  The search continues for a 
satisfied evaluate user...


Post a reply to this message

From: Thomas de Groot
Subject: Re: RoundEdge 2.0: unequal edge radii
Date: 2 May 2020 02:31:12
Message: <5ead13b0$1@news.povray.org>
Op 01/05/2020 om 18:44 schreef Cousin Ricky:
> On 2020-05-01 2:51 AM (-4), Thomas de Groot wrote:
>> Op 30/04/2020 om 18:21 schreef Cousin Ricky:
>>>
>>> In my experience it helps with POV-Ray 3.6, but slows things down 
>>> with POV-Ray 3.7--for the same isosurface function!  I once had a 
>>> mind to ask the group about this anomaly, but I never got a round 
>>> tuit (POVers charge a premium for those!), and I cannot find my 
>>> records of the timing statistics.  I don't normally use it, but I 
>>> believe Thomas de Groot uses it a great deal.
>>
>> I have not really used 'evaluate' in my isosurfaces. I have played 
>> with it of course but as far as I can remember, I did not find any 
>> significant use for it in my scenes. I browsed a couple of them and 
>> 'evalate' is never used.
> 
> Hmmmm.  Perhaps I'm mixing you up with one of the many POVers doing 
> Landscapes Of The Week many years ago.  The search continues for a 
> satisfied evaluate user...

Christoph Hormann perhaps?

-- 
Thomas


Post a reply to this message

From: William F Pokorny
Subject: Re: RoundEdge 2.0: unequal edge radii
Date: 2 May 2020 08:17:27
Message: <5ead64d7$1@news.povray.org>
On 4/30/20 12:21 PM, Cousin Ricky wrote:
...
> 
>> I've never gotten to where evaluate is part of my isosurface flow... 
>> How much does the evaluate feature typically buy you?
>>
>> In my experiments 10-15% at most - and it's sometimes slower, but I've 
>> also not stuck with using it. Am I'm missing bigger possible gains?
> 
> In my experience it helps with POV-Ray 3.6, but slows things down with 
> POV-Ray 3.7--for the same isosurface function!  I once had a mind to ask 
> the group about this anomaly, but I never got a round tuit (POVers 
> charge a premium for those!), and I cannot find my records of the timing 
> statistics.  I don't normally use it, but I believe Thomas de Groot uses 
> it a great deal.

Hmm, That stinks of a thread safety issue. Let me take a quick look at 
the code.

On a quick read I agree with comments left long ago from the core 
developers - evaluate is not thread safe... ;-)

Also sort of looks like the on the fly evaluate adjustments are sticky 
for the isosurface. Meaning they are not done on a ray by ray basis 
which itself is questionable except with really well behaved functions 
(no sharp edges / local high gradients).

All doesn't mean things won't kinda sorta work if you set the right 
limiting parameters. Isosurfaces are like that...

Will take a deeper look before 'boom,' but think this feature just made 
my povr nuke it list. There is considerable overhead for it even when 
not using it.

If someone wants to test how much performance we get in v37, v38 by 
using it, running with one thread best for accuracy. Unsure what to 
trust results wise. A box with sharpish edges - it might adjust the 
internal gradient downward to where the image at the sharp edges changes 
(sharper bits get missed). Who knows, maybe this would make for a 
smoother image on average, certainly would render faster.

If folks do turn up performance numbers, I am still interested.

Bill P.


Post a reply to this message

From: Bald Eagle
Subject: Re: RoundEdge 2.0: unequal edge radii
Date: 2 May 2020 09:55:01
Message: <web.5ead7ad89fcd114afb0b41570@news.povray.org>
Given all of the isosurface stuff I [try to] do, and the functions that are
needed to do them, I really do have to say that it seems like something is
amiss.

I mean, I watch people code shaders, and then I follow along the best I can with
analogous POV-Ray code, and things quickly get SLOW - for a single render -
while they are still happily running at 30+ fps.

(and damn - RT vortices...   :O
https://www.shadertoy.com/view/MlS3Rh
https://www.win.tue.nl/~vanwijk/ibfv/ibfv.pdf
)

Is it a function evaluation issue?
Do vector functions make thing THAT much faster?
(they even use swizzling)
Is it a core isosurface code issue?
Can the pigment pattern - to - isosurface trick help to speed that up?
Is it that the shaders use GPU rather than cpu (ShaderToy runs in a browser...)
Does the shader stuff somehow get compiled beforehand?

I also have to bring up the parametric object speed again - I haven't yet dug
into the source for that, but it doesn't really make any sense why that should
be any slower than any of the rest of the object primitives, or at least THAT
much slower.
Maybe the reason for its drag can point to clues for speeding up ALL of the
function evaluations?

I would of course like to help - you could always point to filenames in 3.7/3.8
and approximate line numbers so I can familiarize myself with the moving parts
and begin to more fully wrap my head around what's going on and let my
subconscious crunch on it.


Post a reply to this message

Goto Latest 10 Messages Next 2 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.