The three attached images were created using two new patterns called 
hard_object and soft_object. They can be found in the patch branch off 
master (3.7.2) at:

https://github.com/wfpokorny/povray/tree/feature/soft_objectAndhard_objectPatterns

Associated demo scenes can be found in the scenes/textures/patterns 
directory of the branch. Both new patterns are aimed first at making the 
object to isosurface-object path easier. However, both work as pure 
patterns too with gradual 0 to 1 value changes from the object surface 
inward.

The hard_object pattern is a more complete implementation of the 
ObjectAsIso idea I was playing with - mostly in SDL - back in 2008 or 
2009. Hard because the method replicates an input object's sharp features.

The soft_object pattern is based upon a subset of the density file 
pattern updates and ideas I was playing with last year. See: 
http://wiki.povray.org/content/User:Wfpokorny/DensityFile. Soft because 
the method uses exponential blobbing. In this implementation a virtual 
"df3 grid" is created on the fly.

The essential sdl for hard_object looks like:

  #declare FnHardObj = function {
     pattern { hard_object { ObjectText }
         radius 0.08
         recursion_limit 10
         samples 22
         warp { turbulence VarTurb octaves 3 lambda 3 }
     }
}

and for soft_object it looks like :

#declare FnSoftObj = function {
     pattern { soft_object { ObjectText }
               spacing 0.009
               strength 1.00
               warp { turbulence VarTurb lambda 5 }
     }
}

If you'd like to give these patterns a try, feel free to grab the branch 
off github. I'm still seeing what they can do - and not do - myself.
Bill P.

Further notes.
---------------

- Both patterns are sampling based.

- The hard_object demo uses one text object ("Water") for simplicity. 
The soft_object demo is made faster making each letter was its own 
isosurface due bounding and inside object test efficiency. Both methods 
are sensitive to how quickly the inside object tests can be done.

- Objects used must have a defined inside.

- Further documentation on the options can be found in the associated 
git commit messages.

- If using as a pattern the soft_object is often faster than hard_object 
for a smooth result. The reverse tends to be true if using the patterns 
in an isosurface.

- When using hard_object in a pattern low recursion_limit values and 
high samples are usually best. If using the hard_object pattern in an 
isosurface low samples and higher recursion tends to be better.

- The hard_object method works exceptionally well with convex, 
outwardly-pointy object features. The method struggles with concave, 
inward-crevasse portions of the object - though where samples high 
enough the distance from surface measure is decent. As the spherical 
sampling moves further inside the original object fewer and fewer of the 
spherical samples are usable in estimating the distance within - and 
results get noisy. Such noisiness is both shown and used for effect in 
this TinaCHeP image:

http://www.tc-rtc.co.uk/imagenewdisplay/stills/754/10.html

- Aggressive AA settings in combination with these patterns should be 
avoided until final renders. The relative slowness of the patterns 
compounds with AA.

Post a reply to this message

Attachments:
Download 'hard_object.jpg' (65 KB) Download 'hard_objecta.jpg' (129 KB) Download 'soft_object.jpg' (81 KB)

Preview of image 'hard_object.jpg'

Preview of image 'hard_objecta.jpg'

Preview of image 'soft_object.jpg'

Am 03.03.2017 um 11:43 schrieb William F Pokorny:
> The three attached images were created using two new patterns called
> hard_object and soft_object. They can be found in the patch branch off
> master (3.7.2) at:
> 
> https://github.com/wfpokorny/povray/tree/feature/soft_objectAndhard_objectPatterns

Sounds to me like an extension of the mechanism could be used for
proximity patterns.

I find the names `hard_object` and `soft_object` rather nondescriptive.

Also, I wonder whether it would be more user-friendly to syntactically
include these patterns into the `object` pattern, using one additional
parameter to enable "fuzzyness" of the pattern and choose a mode to
achieve that "fuzzyness", plus mode-specific parameters (though ideally
the modes should use the same set of parameters where possible).

How I would like to use such a pattern would be by specifying:

- Whether the pattern slope should be outside the surface, inside the
surface, or across the surface (given a flat surface of course). (Note
however that the latter might be sufficient to create the other two by
"postprocessing".)

- A falloff rule, e.g. linear, power-law or exponential-ish. (Note
however that the waveform pattern parameter might be sufficient for this.)

- A parameter to control the falloff distance.

- One or more parameters to control the quality of the computations.

Maybe it would also be useful to implement a caching mechanism for some
modes.

Also, ideally some parameterization of the whole smash should combine
neatly with blob potential patterns.

Post a reply to this message

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

> Associated demo scenes can be found in the scenes/textures/patterns
> directory of the branch. Both new patterns are aimed first at making the
> object to isosurface-object path easier.

Hmmm -
I'm watching this right now and you may also find this to be of interest:
https://www.youtube.com/watch?v=r18Gi8lSkfM

especially around the 12:00 mark

IIRC from another tutorial I saw a while back, there may be some utility here in
selecting round vs sharp corners - I'll have to track down the demonstration of
that.  Might be useful for other folks playing around with scanning, meshes,
isosurfaces, fillets, etc.

Looks like Thies Heidecke was working in the forward direction in 2002.
http://news.povray.org/povray.binaries.images/message/%3C3c7bb095%40news.povray.org%3E/#%3C3c7bb095%40news.povray.org%3
E

So much to learn, so many approaches to every problem!

Post a reply to this message

On 03/03/2017 09:00 AM, clipka wrote:
> Am 03.03.2017 um 11:43 schrieb William F Pokorny:
>> The three attached images were created using two new patterns called
>> hard_object and soft_object. They can be found in the patch branch off
>> master (3.7.2) at:
>>
>> https://github.com/wfpokorny/povray/tree/feature/soft_objectAndhard_objectPatterns
>
> Sounds to me like an extension of the mechanism could be used for
> proximity patterns.

Yes, a variation of the hard_object method would essentially be what 
many here have called proximity patterns - that are really local 
density-of-object(s) patterns. Jérôme has this: 
http://wiki.povray.org/content/User:Le_Forgeron#proximity_pattern and 
several have done things in SDL(1).

I think any real proximity pattern would shoot sample rays outward from 
any sample point in space. Meaning it would be valid at a distance from 
objects, perhaps even in a way not associated with particular objects at 
all.

(1) - Including me. Somewhere I have a local density of object(s) 
pattern written with functions for which performance was pretty good in 
my use. I'll see if I can find it.

>
> I find the names `hard_object` and `soft_object` rather nondescriptive.
>

Not a big fan of these myself, but in the moment it's what I came up with.

> Also, I wonder whether it would be more user-friendly to syntactically
> include these patterns into the `object` pattern, using one additional
> parameter to enable "fuzzyness" of the pattern and choose a mode to
> achieve that "fuzzyness", plus mode-specific parameters (though ideally
> the modes should use the same set of parameters where possible).
>

A good idea - but one which is hampered by my near-amateur c++ skills... 
:-)

> How I would like to use such a pattern would be by specifying:
>
> - Whether the pattern slope should be outside the surface, inside the
> surface, or across the surface (given a flat surface of course). (Note
> however that the latter might be sufficient to create the other two by
> "postprocessing".)
>

Agree & thought of 'some' of these use desires myself. Tried one or two 
variations working from outside the object, but failed to come up with 
anything that worked.

By 'worked' here remember we are, performance wise, playing out at the 
edge of practicality. Especially, given the primary intended use is in 
another performance challenged area in functions and isosurfaces.

> - A falloff rule, e.g. linear, power-law or exponential-ish. (Note
> however that the waveform pattern parameter might be sufficient for this.)
>

Yes, poly_wave is the intended method.

> - A parameter to control the falloff distance.
>

This is somewhat there given the hard_object->radius and 
soft_object->spacing & soft_object->strength affect the falloff. Might 
be hard to get the right trade offs though without an explicit falloff 
value... If we can figure out a just outside value field capability an 
explicit falloff distance - as a maximum - becomes more useful I think. 
I'll think about it...

> - One or more parameters to control the quality of the computations.
>

Not completely sure what you mean here. hard_object->samples is one I 
guess. As you perhaps saw from the previous df3 blobbing modes, there 
are some known tricks for faster much less accurate exp emulation used 
in the soft_object which might be OK for pure pattern use - they were in 
experimentation not useful with isosurfaces.

The very latest intel processors have AVX512 8x double exp capability, 
which in the soft_object method might lead to a significant performance 
boost. The code would have to be restructured I think to make it 
practical by hand coding or compiler optimization. (I also do not own 
such a processor & most other users won't have them near term...)

> Maybe it would also be useful to implement a caching mechanism for some
> modes.
>

Yes, possible. For the soft_object form I have little immediate 
interest in code work given the new df3 3,4 & 5 interpolation modes are 
just such a cache with the added benefit I can tune the strengths used 
in the df3-grid to get much better looking soft/blobbed results.

I've played a little with caching ideas for the hard_object method 
without success. My limited C++ skills are likely in the way.

What I found myself wishing for was a simple to use fixed thread 
associated, array storage. Something I could index by thread number 
(ThreadData->ThreadNumber).

There is a thread id in the boost pthread implementations, but no by 
render-thread 'integer' I could find which might be the basis for such 
caching. Did I miss something or might we create such an render-thread 
index integer ourselves as we spin the render-threads off? For caching 
to benefit performance-wise it is my belief we cannot be doing much - 
perhaps any - memory management. Thinking of caching created on pattern 
creation and then fixed thereafter during pattern evaluation could 
likely help.

I looked at the crackle and isosurface caching, but in addition to not 
really understanding completely how it all works - just adding more 
overhead to the by thread threaddata looked undesirable. Especially 
given our recent thread stack size issues.

> Also, ideally some parameterization of the whole smash should combine
> neatly with blob potential patterns.
>

Yes, this thought popped into my head too, but I'm well off having any 
clear view on how it might all work.

Thanks for the feedback!

Bill P.

Post a reply to this message

On 03/03/2017 10:15 AM, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>
>> Associated demo scenes can be found in the scenes/textures/patterns
>> directory of the branch. Both new patterns are aimed first at making the
>> object to isosurface-object path easier.
>
> Hmmm -
> I'm watching this right now and you may also find this to be of interest:
> https://www.youtube.com/watch?v=r18Gi8lSkfM
>
> especially around the 12:00 mark
>
> IIRC from another tutorial I saw a while back, there may be some utility here in
> selecting round vs sharp corners - I'll have to track down the demonstration of
> that.  Might be useful for other folks playing around with scanning, meshes,
> isosurfaces, fillets, etc.
>
> Looks like Thies Heidecke was working in the forward direction in 2002.
>
http://news.povray.org/povray.binaries.images/message/%3C3c7bb095%40news.povray.org%3E/#%3C3c7bb095%40news.povray.org%3
> E
>
> So much to learn, so many approaches to every problem!
>
>
>
Thanks for the pointers and yes, agree. Lots of ways to come at things.

I've noted your recent FFT posts. Who knows maybe they can play some 
part here, but I've never worked directly with FFT code or libraries.

Bill P.

Post a reply to this message

On 03/04/2017 10:32 AM, William F Pokorny wrote:
>>
>> Sounds to me like an extension of the mechanism could be used for
>> proximity patterns.
>
> Yes, a variation of the hard_object method would essentially be what
> many here have called proximity patterns - that are really local
> density-of-object(s) patterns. Jérôme has this:
> http://wiki.povray.org/content/User:Le_Forgeron#proximity_pattern and
> several have done things in SDL(1).
>
> I think any real proximity pattern would shoot sample rays outward from
> any sample point in space. Meaning it would be valid at a distance from
> objects, perhaps even in a way not associated with particular objects at
> all.
>
> (1) - Including me. Somewhere I have a local density of object(s)
> pattern written with functions for which performance was pretty good in
> my use. I'll see if I can find it.
>

I've posted the full code for an example to p.b.scene-files. The 
resultant image is attached. It shows too some of the shortcomings of 
density-based vs what a real proximity pattern might do.

FYI - In finding the code again, the functions could I think be 
encapsulated in a macro for a general local-density capability. I 
defined a radius variable and a falloff variable.

In this implementation the starting radius with a relatively few samples 
is shrunk by a falloff - (currentRadius/falloff) for each step - from 
the starting radius smaller for 22 steps. The sampling vectors  were 
randomly rotated at each step. The number of samples inside of all the 
samples is then normalized to a 0-1 value as the final functional result.

Bill P.

Post a reply to this message

Attachments:
Download 'denfnctexample.jpg' (34 KB)

Preview of image 'denfnctexample.jpg'

> I've posted the full code for an example to p.b.scene-files. The
> resultant image is attached. It shows too some of the shortcomings of
> density-based vs what a real proximity pattern might do.
>
I'll admit, I have no idea what "short comings" I am looking at, since, 
this looks really neat. Like, someone painted the thing blue, then 
yellow, then bright pink, then it spent enough time in some sort of 
abrasive conditions so as to strip the paint, except where well 
protected, back to yellow, then finally the original blue, along the 
much more exposed edges.

-- 
Commander Vimes: "You take a bunch of people who don't seem any 
different from you and me, but when you add them all together you get 
this sort of huge raving maniac with national borders and an anthem."

Post a reply to this message

On 5-3-2017 19:27, Patrick Elliott wrote:
>> I've posted the full code for an example to p.b.scene-files. The
>> resultant image is attached. It shows too some of the shortcomings of
>> density-based vs what a real proximity pattern might do.
>>
> I'll admit, I have no idea what "short comings" I am looking at, since,
> this looks really neat. Like, someone painted the thing blue, then
> yellow, then bright pink, then it spent enough time in some sort of
> abrasive conditions so as to strip the paint, except where well
> protected, back to yellow, then finally the original blue, along the
> much more exposed edges.
>

I was thinking the same and that this image even seems to show some 
improvements over current proximity pattern use.

-- 
Thomas

Post a reply to this message

On 03/05/2017 01:27 PM, Patrick Elliott wrote:
>> I've posted the full code for an example to p.b.scene-files. The
>> resultant image is attached. It shows too some of the shortcomings of
>> density-based vs what a real proximity pattern might do.
>>
> I'll admit, I have no idea what "short comings" I am looking at, since,
> this looks really neat. Like, someone painted the thing blue, then
> yellow, then bright pink, then it spent enough time in some sort of
> abrasive conditions so as to strip the paint, except where well
> protected, back to yellow, then finally the original blue, along the
> much more exposed edges.
>
Patrick & Thomas, Thanks & thanks for making me think more about this.

I've had it in my head a real proximity pattern would stop at the first 
surface of the surrounding object(s) - which would create a smoother 
result than seen - in addition to working with objects having no 
interior(1).

Suppose though, rays shot outward from a proximity pattern don't have to 
stop at the first surface... ;-)

Perhaps relatively obvious, but the posted density function example 
doesn't need to be object based. In other words it's input function can 
be another pattern or any other function. I'm attaching another image 
using the cells pattern as the input. I've played very little with other 
than object based function inputs with this local density method.

Bill P.


(1) - A really rough idea for use I've had rattling around in my head 
for a first-surface (best aligned to surface normal, min found, other?) 
proximity pattern is using such a pattern as an aid in placing objects. 
Or, moving objects around in a scene in an environmentally aware way. 
Especially meshes and objects in relation to meshes. Mesh camera looking 
outward from each face toward objects(s) whose pigment is an emitted 
color which corresponds to proximity not to itself but back to the 
mesh... Similar things can be done with trace, but at the speed of SDL...

Post a reply to this message

Attachments:
Download 'denfnctexample2.jpg' (51 KB)

Preview of image 'denfnctexample2.jpg'

Am 06.03.2017 um 15:49 schrieb William F Pokorny:

> I've had it in my head a real proximity pattern would stop at the first
> surface of the surrounding object(s) - which would create a smoother
> result than seen - in addition to working with objects having no
> interior(1).

I would consider that an implementation detail of a proximity pattern --
just a different mode, if you will.

Post a reply to this message