|
|
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
|
|