POV-Ray : Newsgroups : povray.object-collection : RoundEdge 2.0: unequal edge radii Server Time
28 Mar 2024 08:15:08 EDT (-0400)
  RoundEdge 2.0: unequal edge radii (Message 3 to 12 of 12)  
<<< Previous 2 Messages Goto Initial 10 Messages
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

From: William F Pokorny
Subject: Re: RoundEdge 2.0: unequal edge radii
Date: 2 May 2020 11:49:55
Message: <5ead96a3$1@news.povray.org>
On 5/2/20 9:51 AM, Bald Eagle wrote:
> 
> 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.
> 

It's complicated and you've guessed a lot of it.

I think the biggest speed differences come from gpu/simd optimization. 
If you can break down a problem in a way which lets you feed those very 
wide compute units with huge chunks of the problem at a go, you speed 
things up by many multiples - even with simd which isn't that wide(1).

Exploiting gpus / simd units in a general way - which doesn't perch you 
at the top of a massive software stack - doesn't look easy to me(2).

Bill P.

(1) - I think even the massively parallel gpu cards are not too far off 
from running out of gas. You can only make parallel so much of the job. 
With the cpu core counts going ever higher - should we bother with a lot 
of gpu optimization?

(2) - I have looked at using GPUs with isosurfaces. A 5000 way min, no 
problem... Each time I take a peak at gpu code, it's just too much, ever 
changing, software infrastructure. I cannot find a way in that's easy 
enough and of general enough use.


Post a reply to this message

From: William F Pokorny
Subject: Re: RoundEdge 2.0: unequal edge radii
Date: 2 May 2020 12:43:48
Message: <5eada344$1@news.povray.org>
On 5/2/20 9:51 AM, Bald Eagle wrote:
> 
...
> 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 don't use it, but forgot about your mention of parametric...

I'm not sure why so slow either though suppose we should expect it to be 
3x slower as a sort of baseline. Never looked at it with any of the 
performance tools. Next time I have a compile set up for profiling I'll 
try to remember to run a parametric or two. Maybe something will pop out.

I've dug a little into parametric shadow issues. I think Jerome has a 
github issue open on the parametric for something similar. Didn't dig 
deep, but looked to me like the code only returns one root which can be 
an problem for shadows.

Bill P.


Post a reply to this message

<<< Previous 2 Messages Goto Initial 10 Messages

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