Attached an image from one of the dens_object pattern tests. Suppose 
X-ray vision - or something.

Bill P.

Post a reply to this message

Attachments:
Download 'dens_object_01.png' (116 KB)

Preview of image 'dens_object_01.png'

William F Pokorny <ano### [at] anonymousorg> wrote:
> Attached an image from one of the dens_object pattern tests. Suppose
> X-ray vision - or something.
>
> Bill P.

That's a very nice and smooth result. I haven't been following, but how does it
work? And have you tried using as a surface normal, to fake rounded edges?

Sam

Post a reply to this message

On 9/3/23 15:54, Samuel B. wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> Attached an image from one of the dens_object pattern tests. Suppose
>> X-ray vision - or something.
>>
>> Bill P.
> 
> That's a very nice and smooth result. I haven't been following, but how does it
> work? And have you tried using as a surface normal, to fake rounded edges?
> 
> Sam
> 
Hi Sam,
Thanks. The core bit of POV-Ray (povr) code for the image is:

...
#declare ColorMap = color_map {
     [  -1 Orange ]
     [   0 ClearBlack100 ]
     [ 0.6 Yellow ]
     [   1 Yellow ]
}
#declare TextR = text {
     ttf "timrom.ttf" "R"
     0.1, 0
     translate <0,0,-0.05>
}
#declare PigListObj = pigment {
     dens_object {
         TextR
         exponent 1.2
         radius 0.044
         recursion_limit 12
         samples 44
     }
     function_interval
     color_map { ColorMap }
}
...

The dens_object pattern does a series of spherical inside tests starting 
at the radius and shrinking on each 'recursion' (actually a loop as 
implemented, but the keyword matches another pattern called 
hard_object{} where recursion is used.) The center of the spherical 
tests is at each ray-surface intersection. Sum up all the tests inside, 
divide by the number of tests and return a value in the -1 to 1 range; 
flat parts come out around 0.0. The aim of this pattern is as a 
'proximity' pattern stand in.

I had the thought to do another render where I use an inside cyan 
pigment to make it clearer which 'edges' are inside, but suppose 
something for another day.

As for using the pattern to perturb raw normals to make things look more 
rounded(a). I'd not thought about it, but I will. I've played quite a 
bit with perturbed normal methods in the povr fork. My guess is 
something based on the surface density measure could work OK for the 
'far side' edges, but might be problematic where the edge faces the 
incoming rays. There would likely be a visible discontinuity in that 
case. That said, I'll think about it. It's an interesting idea(b).

(a) - There is in the povr fork 'soft_object' which can be used to 
create an actual rounded isosurface, but with results that are often a 
little lumpy - often looking like one of your recent ray marching images.

(b) - In part because the density measured can be other than the shape / 
  surface where the normals are being perturbed. In other words, it 
might be possible to use unseen shapes as normal perturbation magnets - 
thinking aloud.

Bill P.

Post a reply to this message

On 9/3/23 21:49, William F Pokorny wrote:
> As for using the pattern to perturb raw normals to make things look more 
> rounded(a). I'd not thought about it, but I will. I've played quite a 
> bit with perturbed normal methods in the povr fork. My guess is 
> something based on the surface density measure could work OK for the 
> 'far side' edges, but might be problematic where the edge faces the 
> incoming rays. There would likely be a visible discontinuity in that 
> case. That said, I'll think about it. It's an interesting idea(b).

And on hitting send, I thought, why not just try Sam's idea...

Attached is an image where I turned the pigment plain white - this the 
image on the left. I then used the existing dens_object set up as a 
normal{} block value pattern. This the image in the middle - the 
polarity of the -1..1 function interval is wrong. Well povr has an 
'inverse' scalar value pattern wave modifier. Added it and we get the 
image on the right - and, dang Sam, that looks pretty good as a quick go 
at it! :-) Thanks for the idea!

Bill P.

Post a reply to this message

Attachments:
Download 'samsnormalidea.jpg' (27 KB)

Preview of image 'samsnormalidea.jpg'

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 9/3/23 15:54, Samuel B. wrote:
> > William F Pokorny <ano### [at] anonymousorg> wrote:
> >> Attached an image from one of the dens_object pattern tests. Suppose
> >> X-ray vision - or something.
> >
> > That's a very nice and smooth result. I haven't been following, but how does it
> > work? And have you tried using as a surface normal, to fake rounded edges?
>
> [...]
> The dens_object pattern does a series of spherical inside tests [...+a more
elaborate explanation...]

I think I get the gist of it, but not the specifics. Are the parsing & rendering
times ok? (It always seems like solutions for this are weighty one way or
another.)

> [...]
> As for using the pattern to perturb raw normals to make things look more
> rounded(a). I'd not thought about it, but I will. I've played quite a
> bit with perturbed normal methods in the povr fork.

This povr fork sounds interesting. Does it allow an object's normal to be
completely overridden?

I've been thinking about making a fork of my own. It's probably a lot of work
and frustration just to get it to compile, but I might have to try anyway.

> [...]
>
> And on hitting send, I thought, why not just try Sam's idea...
>
> Attached is an image where I turned the pigment plain white - this the
> image on the left. I then used the existing dens_object set up as a
> normal{} block value pattern. This the image in the middle - the
> polarity of the -1..1 function interval is wrong. Well povr has an
> 'inverse' scalar value pattern wave modifier. Added it and we get the
> image on the right - and, dang Sam, that looks pretty good as a quick go
> at it! :-) Thanks for the idea!
>
> Bill P.

That result is... really good! Have you tried it with specular highlights or
reflection? It's hard to see the absolute quality here, but I'd say the
experiment was a success for sure!

Sam

Post a reply to this message

On 9/5/23 18:59, Samuel B. wrote:

> Parsing and render times.

Of course quite a bit longer with dens_object. No getting around there 
being a lot more work getting done. Let's see. A render of just the R - 
no normal{} at all on my old 2 core i3:

   1.50user 0.03system 0:01.26elapsed

and with a dens_object normal 'similar' to that posted prior.

   69.96user 0.11system 0:18.82elapsed

using both times the command line:

   povr dens_object_02.pov +w800 +h600 +a0.05 +am2 +r3 +j3.33


 > This povr fork sounds interesting. Does it allow an object's normal 
to > be completely overridden?

Only a little more so than the usual POV-Ray at this point. As we 
increase the normal{} block bump_size beyond 0.5 we already start to, 
for example, invert normals. The larger that bump_size the more the 
perturbation influence becomes the total perturbed normal. This 'take 
over' usually at the cost of some distortion to the intended result.

In povr, I've played some with chained normal perturbations which 
replace the raw normal with more perturbations due the chaining.

I have not, though, thought about selectively replacing raw normals 
completely with some other entirely. This would be hard to do in general 
(with a switch say) but say maybe if using other shapes to paint in 
replacements always from the outside / inside we could make the 
replacement orderly... I'll think about it.

 > I've been thinking about making a fork of my own.

It's work - and sometimes frustrating for sure - but you can also try 
what you want. To some degree you get to use what you want from other 
forks too.

> Have you tried it with specular highlights or reflection?

I've not played with finishes yet.

I did spec a little time with the accuracy(a) setting which has some 
effect. The 0.02 accuracy default shown in the earlier posting is as 
much blunting corners (except for the opposing seams - which stick 
around) as rounding them when looked at on closer renders. A smaller 
accuracy setting looks more rounded,  but pretty quickly also better 
shows additional discontinuities in the normals.

(a) - I have some long standing concerns with this keyword's 
implementation with respect to bias and an internal 'magic factor' there 
in the code, but not described. I dislike 'magic' code because it almost 
always disconnects users from any intuitive feel for what setting would 
be best. Anyhow, I might use dens_object based normals to play with that 
accuracy code some... We'll see.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 9/5/23 18:59, Samuel B. wrote:
>
> > Parsing and render times.
>
> Of course quite a bit longer with dens_object. No getting around there
> being a lot more work getting done. Let's see. A render of just the R -
> no normal{} at all on my old 2 core i3:
>
>    1.50user 0.03system 0:01.26elapsed
>
> and with a dens_object normal 'similar' to that posted prior.
>
>    69.96user 0.11system 0:18.82elapsed

I don't know what any of that means :( Are you using Linux or something? I'm
guessing those values are in seconds? And that the object with a normal took a
bit over 1 minute? (POV-Ray has always showed me things in terms of seconds,
minutes, hours, PPS etc.)

> > This povr fork sounds interesting. Does it allow an object's normal
> > to be completely overridden?
>
> Only a little more so than the usual POV-Ray at this point. As we
> increase the normal{} block bump_size beyond 0.5 we already start to,
> for example, invert normals. The larger that bump_size the more the
> perturbation influence becomes the total perturbed normal. This 'take
> over' usually at the cost of some distortion to the intended result.

Ah. I think that the only thing the official versions can do to override a
normal atm is to use one of the facets patterns.

It would be nice to completely change normals. We could do things like make
actual normal maps, or in this case, make shaders for rounded edges. At this
point, I can make a function of averaged object patterns and then derive a
normal from it, but I can't take that normal value and use it as an actual
normal :/ I can only adjust the original surface normal with a single density
value. I don't know what future versions of the SDL would look like, but I hope
it supports more direct access to shading without decreasing the easy usability
of today's syntax.

>  > I've been thinking about making a fork of my own.
>
> It's work - and sometimes frustrating for sure - but you can also try
> what you want. To some degree you get to use what you want from other
> forks too.

Yeah, I've been wanting to play with clipka's reflection blurring to force it to
allow, for instance, only one sample. That way samples could be multipled via
focal blur and/or aa without reaching ridiculous render times. It would help get
the renderer more in line with something like Blender's Cycles.

> > Have you tried it with specular highlights or reflection?
>
> I've not played with finishes yet.
>
> I did spec a little time with the accuracy(a) [...]
>
> (a) - I have some long standing concerns with this keyword's
> implementation with respect to bias and an internal 'magic factor' there
> in the code, but not described. I dislike 'magic' code because it almost
> always disconnects users from any intuitive feel for what setting would
> be best. Anyhow, I might use dens_object based normals to play with that
> accuracy code some... We'll see.
>
> Bill P.

I always interpreted 'accuracy' as a sort of radius. I don't know if the values
match of with actual units, but I keep it low for sharp things, and higher for
when I need a smoother look.

Sam

Post a reply to this message

On 9/6/23 19:30, Samuel B. wrote:
>> Of course quite a bit longer with dens_object. No getting around there
>> being a lot more work getting done. Let's see. A render of just the R -
>> no normal{} at all on my old 2 core i3:
>>
>>     1.50user 0.03system 0:01.26elapsed
>>
>> and with a dens_object normal 'similar' to that posted prior.
>>
>>     69.96user 0.11system 0:18.82elapsed
> I don't know what any of that means 🙁 Are you using Linux or something? I'm
> guessing those values are in seconds? And that the object with a normal took a
> bit over 1 minute? (POV-Ray has always showed me things in terms of seconds,
> minutes, hours, PPS etc.)
> 

Yes, Ubuntu and I trust the unix/linux timers over POV-Ray's internal 
measures because they wrap POV-Ray's processes / sub-processes.

The elapsed time is likely the practical user measure. It's how long 
someone waits for the render to finish. So, 1.5 seconds became 19 
seconds on my i3.

Multi-cores, multi-threads, variable clock rates - now high power and 
low power cores. There are too configure and compile options, differing 
compilers etc too. Other load on the machine...

What the reported times mean these days is a good deal harder to really 
understand than it used to be.

---

... and facets ... I've never spent time with that normal{} block 
modifier or the code. In a quick look at the code it does look like 
there is a mode for complete replacement in addition to one which
perturbs. Thanks.

---

Aside: The povr fork has a normal{micro} perturbation method which 
really only works as a final results with AA. This sounds a little like 
what the clipka code experiment you'd like to do.

---

Shading... This something about which I don't know very much. I know 
there are shaders available in GPU hardware which can fake effects and 
do certain limited programming like stuff, but that's about it.

As for mapping to arbitrary shapes - a tough problem. Probably easier to 
create a mesh and work with that. Aside: I've played a little with df3 
environments into which arbitrary shapes can be placed for pigment / 
normal mapping of a sort. However, that approach has the non-trivial, 
practical issue of very large df3 sizes accompanying those now mapped / 
painted shapes.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 9/6/23 19:30, Samuel B. wrote:
> > William F Pokorny <ano### [at] anonymousorg> wrote:
> >> Of course quite a bit longer with dens_object. No getting around there
> >> being a lot more work getting done. Let's see. A render of just the R -
> >> no normal{} at all on my old 2 core i3:
> >>
> >>     1.50user 0.03system 0:01.26elapsed
> >>
> >> and with a dens_object normal 'similar' to that posted prior.
> >>
> >>     69.96user 0.11system 0:18.82elapsed
> >
> > I don't know what any of that means 🙁 Are you using Linux or something?
[...]
>
> Yes, Ubuntu and I trust the unix/linux timers over POV-Ray's internal
> measures because they wrap POV-Ray's processes / sub-processes.

Ah, ok. I was starting to wonder if there was a setting I missed.

I'll have to switch over to some flavor of Linux one of these days, since
Microsoft is progressively making Windows worse in every way. (Bloat is probably
the biggest issue. I suspect Windows uses too many resources... Currently, 44%
of my 8GB of memory is being used, and I only have Firefox open! For some
reason, several Edge instances are running, plus a bunch of other things. It's
crazy.)

> Aside: The povr fork has a normal{micro} perturbation method which
> really only works as a final results with AA. This sounds a little like
> what the clipka code experiment you'd like to do.

Ah, so is it like crand, but for normals? That would probably be perfect,
especially if samples multiply with focal blur.

> Shading... This something about which I don't know very much. I know
> there are shaders available in GPU hardware which can fake effects and
> do certain limited programming like stuff, but that's about it.

I was referring to shading in the general sense, as in what POV-Ray does under
the hood. Being an end user, I only get to change options exposed/implemented by
the SDL.

Ideally, I think a future version could benefit from being more like Blender's
Cycles, where you get near absolute control over diffuse, glossy reflections,
emission, subsurface scatting, etc. (Blender uses nodes for this, so it would be
different in POV-Ray.) Each such feature could receive value and pattern inputs,
while still being simple to use when you don't want to go overboard. In POV, we
can already do a lot with texture_maps but they tend to be slower to render,
even for simple things like having the specular roughness change using a
pattern.

> As for mapping to arbitrary shapes - a tough problem. Probably easier to
> create a mesh and work with that.

Yeah, real shapes are always better overall.

> Aside: I've played a little with df3 environments into which arbitrary
> shapes can be placed for pigment / normal mapping of a sort. However,
> that approach has the non-trivial, practical issue of very large df3
> sizes accompanying those now mapped / painted shapes.
>
> Bill P.

There is a way to 'grow' signed distance functions (SDFs), and then render them
at resolutions higher than the initial array size. In cases where you're making
arbitrary shapes (like if you had a 3D voxel painter or such), the result might
look bumpy (like packed spheres) near the resolution size. But in cases where
you know the shapes you want, it can be very precise.

I can't really explain it better at this time, but if your system supports
hardware shaders, check out these 2D examples:
https://www.shadertoy.com/view/4sK3WK
https://www.shadertoy.com/view/MdGGWt

It's probably not ideal for most things.

Sam

Post a reply to this message

On 2023-09-07 18:33 (-4), Samuel B. wrote:
> 
> I'll have to switch over to some flavor of Linux one of these days, since
> Microsoft is progressively making Windows worse in every way. (Bloat is probably
> the biggest issue. I suspect Windows uses too many resources... Currently, 44%
> of my 8GB of memory is being used, and I only have Firefox open! For some
> reason, several Edge instances are running, plus a bunch of other things. It's
> crazy.)

I don't know that switching would help.  While Microsoft does eat disk
space like candy, and I'm never one to discourage people from ditching
Windows, my GNU/Linux system shows 393 processes open.  Only a few dozen
at most are windows that I have open.  And Firefox is easily the
greediest app on my system.

Starting a fresh session shows 365 processes and 1.3 GiB memory used,
before I even open any apps.  Bloat just seems to be an inherent
property of most 21st century software.

But yeah, Edge does have a habit of popping up out of nowhere on Windows
systems.

Post a reply to this message