On 4/14/20 3:19 PM, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
...
> 
>> The v.zyx syntax has a name - like twizzling or something - and it's
>> offered in some C++ vector template classes at significant complexity to
>> those
> 
> Swizzling - yes that rang a bell, and a search confirmed.
> 
> Given the above .gray / .grey capability, I must admit it's a bit surprising
> that .yzx would be more complex than either of those or .hf.
> 
> 

Suppose up front I'll admit I'm in large part repeating what I've heard 
other say or what I've read as to the impacts - I've not played a lot 
myself with really complex vector template libraries. But, I believe the 
impact statements probably true to a large degree.

Aside: There was a cppcon presentation by some effects guru in the last 
few years where he was describing his company's code and C++ experience. 
As an aside he mentions/complains at one point the C++ vector template 
class they use requires a 64GB machine for their compiles(1).

In isolation, v.yzx is not complicated. It, however, adds to the 
combinatorial complexity of any vector template class which support 
arbitrary floating point types and on those many methods such as 
v.yzx.length(), v.yzx.normalize(), v.zyx * v2.yxz, etc. The behavior of 
all the methods and overloads you want to generically work have to be 
enumerated by the template class in some way such that it turns into 
compilable code.

Bill P.

(1) - And people make fun of M4... ;-) Want to side track yourself some 
day, look into all the C++ template assist/creation tools...

Post a reply to this message

On 4/14/20 9:10 PM, Bald Eagle wrote:
> Any idea if I can [successfully] use the object{} pigment pattern in an
> isosurface function, and what the proper syntax is?
> 
> 
Yep, you can by sampling enough to create continuous values, but it's 
not all that usable implemented in SDL. Look for some zip file called 
ObjectAsISO maybe I put out on the news server in 2008 or maybe 2009.

The hard_object pattern in povr is an inbuilt version of the approach. 
The soft_object pattern another alternative.

The limiter in an object pattern (AKA inside test) based function is the 
normal bounding structure searches are bypassed. If you have one or just 
a few simple shapes - all with effecient inside test code (1) - 
something like hard_object is workable. The soft_object approach less so.

If your shape / structure is complex csg, things become unbearably slow 
-  because POV-Ray today tests each shape one by one.

Bill P.

(1) - Some shapes like the superellipsoid have extremely slow inside 
tests. Others like mesh and mesh2 are really quick as they have an 
internal bounding structure that gets used to do the inside test.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:

> Yep, you can by sampling enough to create continuous values, but it's
> not all that usable implemented in SDL. Look for some zip file called
> ObjectAsISO maybe I put out on the news server in 2008 or maybe 2009.

Excellent - that's exactly the approach I began exploring upon understanding
what the problem was after reading
http://www.econym.demon.co.uk/isotut/dont.htm

It's kinda like calculating normals, combined with dithering / convolving.

http://news.povray.org/povray.binaries.scene-files/thread/%3Cweb.4aae23151285f23f15ee2c550%40news.povray.org%3E/

Downloaded.

I will compare my notes with your working code.   :)

> The hard_object pattern in povr is an inbuilt version of the approach.
> The soft_object pattern another alternative.

I'm sure you've thought about /succeeded in writing the shape out to a df3 -
maybe that would speed things up after the initial conversion...

> If your shape / structure is complex csg, things become unbearably slow
> -  because POV-Ray today tests each shape one by one.

Hmmm.  Can I manually bound the individual elements to mitigate that?

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>
> > Yep, you can by sampling enough to create continuous values, but it's
> > not all that usable implemented in SDL.

I was able to puzzle things out and experiment a bit with parameters.
It works, but is still a bit rough.   Only takes 28 seconds though.   :)

> I will compare my notes with your working code.   :)

Somewhat similar approaches - I'm using an average of the function evaluated at
a variable number of delta-h's (function constructed with a #for loop) along
each of the 3 axes.   You sample around a sphere, and do some complex binary
searching stuff...

I tried using f_r, but I got a lot of weird results.

When my function values cross 0, I get rounding of the corners in the +x and +z
directions, and the same thing happens to a lesser extent when I use too many
samples and flatten the gradient too much.

Shown is a test object, good function results, graph of good function, and the
bad results just mentioned.

Post a reply to this message

Attachments:
Download 'curvedprism.png' (57 KB)

Preview of image 'curvedprism.png'

"Bald Eagle" <cre### [at] netscapenet> wrote:

> When my function values cross 0, I get rounding of the corners in the +x and +z
> directions, and the same thing happens to a lesser extent when I use too many
> samples and flatten the gradient too much.

Fixed that 5 min after posting, and understood exactly why at 4:30 this morning.
  :|

Low accuracy setting for the isosurface gives it the speed and terrible look.
;)
Higher accuracy obviously makes it much smoother and slows it way down.

Will see if RL gives me time to hammer out some more experiments and discover
anything of value.

Post a reply to this message

On 4/15/20 4:56 PM, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>> Yep, you can by sampling enough to create continuous values, but it's
>> not all that usable implemented in SDL. Look for some zip file called
>> ObjectAsISO maybe I put out on the news server in 2008 or maybe 2009.
> 
> Excellent - that's exactly the approach I began exploring upon understanding
> what the problem was after reading
> http://www.econym.demon.co.uk/isotut/dont.htm
> 
> It's kinda like calculating normals, combined with dithering / convolving.
> 
>
http://news.povray.org/povray.binaries.scene-files/thread/%3Cweb.4aae23151285f23f15ee2c550%40news.povray.org%3E/
> 
> Downloaded.
> 
> I will compare my notes with your working code.   :)
> 
>> The hard_object pattern in povr is an inbuilt version of the approach.
>> The soft_object pattern another alternative.
> 
> I'm sure you've thought about /succeeded in writing the shape out to a df3 -
> maybe that would speed things up after the initial conversion...
> 
>> If your shape / structure is complex csg, things become unbearably slow
>> -  because POV-Ray today tests each shape one by one.
> 
> Hmmm.  Can I manually bound the individual elements to mitigate that?
> 

I know of no way today to do that well from a user view.

I have on my possible list of new in built functions one to replace low 
count object patterns where we use functions for the insides tests and 
possible some simple bounding to make it faster for maybe 8-16 'shapes'. 
Really need to finish some of my 'repeatN times' as inbuilts. Many of 
those I already have as SDL.

Another function (or function set) I have less well thought out would 
use multiple functions instead of one into the isosurface by providing a 
wrapper. The name 'f_dual" is what I have in my head as a first try. It 
would use a simple shape(2) until the value fell below an amount enough 
to contain any noise, turbulence or other deformations at which point it 
would switch to the much more complicated - and less gradient friendly - 
function to complete the isosurface.

I didn't post details, but I've played with alternate methods to code, 
f_sphere, for example. Something to avoid the sqrt() because it's 
expensive CPU wise. The other forms have higher gradients and we always 
lose big in isosurface time. In other words the gradient is king with 
our current solver.

This result is why my new f_mult1to8pairs() function includes sqrt as 
options and standard method on the defaut mode. Ah dang I need to post 
details no those don't I.. I got side tracked by the f_superellipsoid 
business, which I had scheduled as a small side job while running test 
scenes.

This response somewhat rushed - sorry about typos and gibberish. Doing 
other stuff much of the day.

Bill P.

Post a reply to this message

On 4/16/20 7:01 AM, Bald Eagle wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> 
>> When my function values cross 0, I get rounding of the corners in the +x and +z
>> directions, and the same thing happens to a lesser extent when I use too many
>> samples and flatten the gradient too much.
> 
> Fixed that 5 min after posting, and understood exactly why at 4:30 this morning.
>    :|
> 
> Low accuracy setting for the isosurface gives it the speed and terrible look.
> ;)
> Higher accuracy obviously makes it much smoother and slows it way down.
> 
> Will see if RL gives me time to hammer out some more experiments and discover
> anything of value.
> 
> 

Yes, in general when working with isosurfaces, you get into the habit of 
working with awful looking results as you work up the structure of a 
scene before cranking down and doing the real render - and even there 
it's often better to render larger and scale down.

It's the case with many shapes there are always ray approaches which 
just catch or miss an edge. These always end up a little more jaggy than 
they should with AA (and drive AA time some). (1)

Rushed...

Bill P.

(1) - Yes, this same effect is there with non-isosurface shapes too, but 
to a lessor extent. Basically for those glancing edges to be clean the 
ray aim must be perfect and due numerical noise, it's not.

Post a reply to this message

On 20200416 8:38 AM (-4), William F Pokorny wrote:
> 
> I didn't post details, but I've played with alternate methods to code, 
> f_sphere, for example. Something to avoid the sqrt() because it's 
> expensive CPU wise. The other forms have higher gradients and we always 
> lose big in isosurface time. In other words the gradient is king with 
> our current solver.

I have found non-linear gradients to be more expensive than sqrt() 
calls.  If I have a quadratic isosurface function (which is the case 
with RE_fn_Blob2() in the Object Collection), I will use a sqrt() 
without hesitation in my SDL to flatten out the gradient.  I imagine 
that the contrast would be even greater with native sqrt() calls, since 
they would not have to go through an interpreter.

Post a reply to this message

On 4/17/20 11:09 AM, Cousin Ricky wrote:
> On 20200416 8:38 AM (-4), William F Pokorny wrote:
>>
>> I didn't post details, but I've played with alternate methods to code, 
>> f_sphere, for example. Something to avoid the sqrt() because it's 
>> expensive CPU wise. The other forms have higher gradients and we 
>> always lose big in isosurface time. In other words the gradient is 
>> king with our current solver.
> 
> I have found non-linear gradients to be more expensive than sqrt() 

> with RE_fn_Blob2() in the Object Collection), I will use a sqrt() 

> that the contrast would be even greater with native sqrt() calls, since 
> they would not have to go through an interpreter.

Yes, think so. Your post a reminder I should review the object 
collection isosurface work. Been years since I played with those files much.

Bill P.

Post a reply to this message