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