 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Cousin Ricky <ric### [at] yahoo com> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
