









 
 




 
 


Suppose you take a pigment pattern and use a color map with one color, the other
being clear. Texture a box with that. Only the sides of the box are
textured, so it appears hollow. This makes some sense due to POVRay only
raytracing surfaces, however since the rays obviously travel through the box to
the other faces and beyond, I wonder what it would take to have the rays
"detect" and pigment the first non rgbf 1 region.
Testing this with pigment {spherical}, one might naively assume to see the
sphere  but only if you make the edge of the textured box intersect somewhere
less than 1.
Post a reply to this message


 
 


From: Alain Martel
Subject: Re: Non  rgbf 1 pigment only applied to surface.
Date: 8 May 2020 02:17:35
Message: <5eb4c13f$1@news.povray.org>



 
 


Le 20200507 Ã 21:10, Bald Eagle a Ã©critÂ :
>
> Suppose you take a pigment pattern and use a color map with one color, the other
> being clear. Texture a box with that. Only the sides of the box are
> textured, so it appears hollow. This makes some sense due to POVRay only
> raytracing surfaces, however since the rays obviously travel through the box to
> the other faces and beyond, I wonder what it would take to have the rays
> "detect" and pigment the first non rgbf 1 region.
>
> Testing this with pigment {spherical}, one might naively assume to see the
> sphere  but only if you make the edge of the textured box intersect somewhere
> less than 1.
>
>
Add an interior.
You can then give it an IOR that will cause rays entering to be refracted.
Fill it with some media that use the same pigment as the container. In
thos case, don't forget to use hollow.
Post a reply to this message


 
 


From: William F Pokorny
Subject: Re: Non  rgbf 1 pigment only applied to surface.
Date: 8 May 2020 10:27:08
Message: <5eb533fc$1@news.povray.org>



 
 


On 5/7/20 9:10 PM, Bald Eagle wrote:
>
> Suppose you take a pigment pattern and use a color map with one color, the other
> being clear. Texture a box with that. Only the sides of the box are
> textured, so it appears hollow. This makes some sense due to POVRay only
> raytracing surfaces, however since the rays obviously travel through the box to
> the other faces and beyond, I wonder what it would take to have the rays
> "detect" and pigment the first non rgbf 1 region.
>
> Testing this with pigment {spherical}, one might naively assume to see the
> sphere  but only if you make the edge of the textured box intersect somewhere
> less than 1.
>
>
Not sure I'm following.
Are you looking for ray tracing efficiency?
If after a result, in addition to Alain's suggestion I'd add the
clipped_by mechanism where only surfaces inside the clipped_by shape
show up.
Underneath today everything is textured  carries that overhead  no
matter.
I've been playing with the idea of independent
containers/shapes/surfaces and bounding structures for textures,
interiors and so on rather than hanging everything off the shape
surfaces. Only a few experiments in that direction thus far (the maze
isosurfaces posted months back was one in part).
Bill P.
Post a reply to this message


 
 




 
 


William F Pokorny <ano### [at] anonymousorg> wrote:
> Not sure I'm following.
And here I thought you would have seen exactly where I was going with this.
> Are you looking for ray tracing efficiency?
.... in a way...
> Underneath today everything is textured  carries that overhead  no
> matter.
My brain couldn't parse that.
Imagine you have the checkered pattern. One color is blue, the other clear.
Apply that to a plane. You can see through the clear parts  but not the blue
parts.
Put an object of some sort under/behind the plane. You can see IT through the
clear parts of the checkered pattern.
So far so good.
Now make a box{} with the same pattern, and have the edge you're looking at
transect a row of squares. What do you see? Alternating clear and blue, sure
..... but you don't see the blue of the second row (if your box is deep enough) 
what you see is the very farthest edge of the last row. You don't even see the
orthogonal edges of the first row, except on the top and bottom surfaces of the
box.
And here's where I was going with this.
If you COULD have the raytracer evaluate the interior of the pattern (sans
media), then you would essentially have  _an isosurface. But given how
patterns and isosurfaces are evaluated under the hood, I'm betting it would be
rendered a LOT faster.

And this is just the unthoughtthrough circus in my brain, before coffee....
I haven't even begun to think through the implications of having
#declare Pattern = pattern {function{myFunction}}
#declare F= function {Pattern}
#declare PartialVectorFunction = function {something * F(x,y,z).x +sumthin_else
* F(x,y,z).y + another_sumthin * F(x,y,z).z}
Shortening the variable names and implementing a default (x,y,z) argument if
unspecified, you'd get a nice tight expression like
#declare PVF = function {s * F.x + se * F.y + as * F.z}
I'll also have to think about encoding a vector into a function so that the
pattern {function{}} thing evaluates to the same VECTOR result everywhere  thus
you could define a function intead of a vector and then use the dot notation in
a function, whereas you currently can't use Vector.x in a function expression.
One needs to resort to the clunky
#declare VX = Vector.x and THEN use VX in the function.....
Post a reply to this message


 
 


From: William F Pokorny
Subject: Re: Non  rgbf 1 pigment only applied to surface.
Date: 8 May 2020 12:24:16
Message: <5eb54f70$1@news.povray.org>



 
 


On 5/8/20 7:09 AM, Bald Eagle wrote:
>
> William F Pokorny <ano### [at] anonymousorg> wrote:
>
>> Not sure I'm following.
>
> And here I thought you would have seen exactly where I was going with this.
>
>> Are you looking for ray tracing efficiency?
>
> .... in a way...
>
>> Underneath today everything is textured  carries that overhead  no
>> matter.
>
> My brain couldn't parse that.
Ignore it for where I 'think' I now understand you're headed. :)
>
...
>
> And here's where I was going with this.
> If you COULD have the raytracer evaluate the interior of the pattern (sans
> media), then you would essentially have  _an isosurface. But given how
> patterns and isosurfaces are evaluated under the hood, I'm betting it would be
> rendered a LOT faster.
>
Starting to follow and I've had thoughts along similar lines. Randomish
stuff from my head:
1) Today with isosurfaces we have the contained_by shape. I had the
thought long ago it would be really helpful to be able to specify any
standard shape as that container. See github issue:
https://github.com/POVRay/povray/issues/228
2) Christoph introduced the potential pattern which has the potential to
be applied to more the blobs and isosurfaces(where not that useful). We
have some issues with normals and warps... A wild thought I've been
carrying around is to implement always an implicit form of the shape in
a way where we'd get today's fast ray  surface intersection with then
underneath a standard way to both deform shapes, get normals deformed or
not and provide a potential pattern(a). I think of this as my always has
isosurface shapes inside the raysurface shape. CSG would perhaps always
be some isosurface where the raysurface intersections are only giving
us the collection of shapefunctions on which to work. But, yeah the
implementation here not easy...
(a)  The traditional normal and normal perturbation code 'could' go
away in total for any 'got ISOsinside' shapes. Maybe performance wise
still useful to fake normals too.
3) With some of my new functions coupled with the f_dual() idea I am
aiming to nest complex shapes/patterns within simpler ones. Until I can
work out a mechanism to delay function evaluation this likely to help
only with better gradients. Think f_dual(), as I can implement it
quickly, likely to buy a lot only when we are forming multiple shapes
within one isosurface.
Your idea and/or a mix of those above there is a key component for
usefulness  some way to fade the isosurface function(s) at the hard
surface boundaries. Otherwise, we have gradient issues there  unless OK
with the container shape cutting or clipping the resultant shape.
Aside: An aim of the, new to povr, f_mult1to8pairs() and f_eblob
functions was to help with this shape/shape, shape/pattern blending.
Though the gradients are still sometimes high depending on how the
component functions come together  especially with the former and
negative*negative multiplication. If you are intersecting half way
through a shape with the multiplication method the gradient is high at
the resultant 'surface' despite achieving some fade.
Bill P.
> 
> And this is just the unthoughtthrough circus in my brain, before coffee....
>
...
>
> I'll also have to think about encoding a vector into a function so that the
> pattern {function{}} thing evaluates to the same VECTOR result everywhere  thus
> you could define a function intead of a vector and then use the dot notation in
> a function, whereas you currently can't use Vector.x in a function expression.
Interesting idea... I'll let it bang around in my head.
> One needs to resort to the clunky
> #declare VX = Vector.x and THEN use VX in the function.....
>
>
>
>
>
>
>
Post a reply to this message


 
 




 
 


William F Pokorny <ano### [at] anonymousorg> wrote:
> 1) Today with isosurfaces we have the contained_by shape. I had the
> thought long ago it would be really helpful to be able to specify any
> standard shape as that container. See github issue:
>
> https://github.com/POVRay/povray/issues/228
Well, this leads me to ask several questions which I've brought up before:
How exactly is an isosurface evaluated?
In my SDLcoded emulation, I iterated over a nested x,y,z loop, evaluated the
function for those elements, and if the result was less than a certain
threshold, I plotted a sphere.
I largely get the gist of the "raytracing equation" but I wonder if there isn't
some advantage of using raymarching to "get close to" the result, with the
raytracing being the finetuning part. Perhaps there are things that we do now
that are simply legacy code, which might be better implemented with different
approaches or at least different equations or algorithms.
When I'm coding isosurface equations or pigment pattern functions, first I just
try to get it "right"/working, and then I look a bit at optimizing the sludge
that I've defiled the editor with. ;)
Predefining squareroots so that I only evaluate that one time rather than
eight...
and something that Inigo Quilez and Martijn Steinrucken teach  finding
symmetries in the objects so that you might only have to "evaluate" 1/4 or 1/8
of the shape. (I admit that I don't quite fully understand how that works in
terms of number of calculations). Even orientation can help simply the
functions so that the number of terms is drastically reduced.
But I don't have a firm enough grasp on how POVRay currently handles all of
that vs ray marching and Signed Distance Functions (SDF's).
I never see anyone talking about gradients  they just go ahead and start piling
equations up and running at an unbelievable 60 FPS.
At which point I can't help but think  we must be doing something wrong.
> 2) .... A wild thought I've been
> carrying around is to implement always an implicit form of the shape
> ..... I think of this as my always has
> isosurface shapes inside the raysurface shape. CSG would perhaps always
> be some isosurface where the raysurface intersections are only giving
> us the collection of shapefunctions on which to work. But, yeah the
> implementation here not easy...
Having tried to code a full set of isosurface equivalents of a lot of basic
shapes, and manage their orientations and CSG permutations.... no, it quickly
becomes pretty crazy. But then again, maybe I was just going about it the
wrong way.
> Your idea and/or a mix of those above there is a key component for
> usefulness  some way to fade the isosurface function(s) at the hard
> surface boundaries. Otherwise, we have gradient issues there  unless OK
> with the container shape cutting or clipping the resultant shape.
OK, but I still don't understand the gradient issue. We have CSG and flat
planes and abrupt discontinuities in shapes all the time that the raytracer
handles just fine. Why are the raymarching algorithms not struggling with this
gradient thing, whereas we find it to be positively crippling in certain
instances?
Post a reply to this message


 
 




 
 


> > I'll also have to think about encoding a vector into a function so that the
> > pattern {function{}} thing evaluates to the same VECTOR result everywhere  thus
> > you could define a function intead of a vector and then use the dot notation in
> > a function, whereas you currently can't use Vector.x in a function expression.
>
> Interesting idea... I'll let it bang around in my head.
Kinda sorta works.
I only played around with it enough to get basic functionality.
Still some weird / awkward things about it all.
#version 3.8;
global_settings {assumed_gamma 1.0}
camera {
location <0, 3, 10>
//location <0, 4, 50>
right x*image_width/image_height
up y
look_at <0, 3, 0>
}
light_source {<20, 50, 30> rgb 1}
sky_sphere {pigment {rgb 0.2}}
// user_defined {FnRed, FnGreen, FnBlue, FnFilter, FnTransmit}
#declare FnR = function (x,y,z) {1}
#declare FnG = function (x,y,z) { 0}
#declare FnB = function (x,y,z) { 1}
#declare FnF = function (x,y,z) {pi}
#declare FnT = function (x,y,z) {tau}
#declare Vector5 = pigment {
user_defined {
function { FnR(x,y,z)},
function { FnG(x,y,z)},
function { FnB(x,y,z)},
function { FnF(x,y,z)},
function { FnT(x,y,z)}
}
}
#declare V5 = function {pigment{Vector5}}
#declare R = function {V5(x,y,z).x}
#declare G = function {V5(x,y,z).y}
#declare B = function {V5(x,y,z).z}
#declare F = function {V5(x,y,z).filter}
#declare T = function {V5(x,y,z).transmit}
#declare Fs = array [5] {
function {R(x,y,z)},
function {G(x,y,z)},
function {B(x,y,z)},
function {F(x,y,z)},
function {T(x,y,z)}
}
#declare C = array [5] {
pigment {rgb <1, 0, 0>},
pigment {rgb <0, 1, 0>},
pigment {rgb <0, 0, 1>},
pigment {rgb 1},
pigment {rgb 0}
}
#for (Func, 0, 4)
#for (N, 0, 10)
#local Y = Fs[Func](1,2,3);
//#local Y = Fs[F](x,y,z); This does NOT work. ???
sphere {<1*N/5, Y, 0> 0.1 pigment {C[Func]}}
#end
#end
Post a reply to this message


 
 


From: William F Pokorny
Subject: Re: Non  rgbf 1 pigment only applied to surface.
Date: 9 May 2020 14:58:04
Message: <5eb6c4fc$1@news.povray.org>



 
 


On 5/8/20 8:09 PM, Bald Eagle wrote:
>
...
Forgive me, I'm going to forgo answering all the questions in detail.
You're asking the right questions. Answers there are a many. Shy away
from extremes that any given approach is all right or all wrong  that
thinking I've found almost always wrong.
On the fast, distance based stuff. I believe a reason they can be so
fast  in addition to a lot of optimization  is they set everything up
distance based (nice gradients). This lets them toss gazillions of
equations at GPU hardware (or SIMD), run it all in parallel and 'just'
add up the answers to get an 'effective equation.' By that I mean a
continuous value field over which one can iterate and find roots. How
accurate those roots are is a LOT less clear to me... Like our
isosurface set up, this method has no way to universally find all roots.
In fact beyond a certain number of equations tossed into the mix, not
sure the creator of the input really knows...
(In a bisection like solver  see below  they can also test thousands
of points along the ray 'at once'. Not sure if this done.)
All said, it IS an approach I think could have a place with isosurfaces,
but then there is the matter of multiple GPU vendors and packages on
packages of ever changing software to get at it. Needing too to stay
somewhat an expert in the field to keep it all running over time...
Aside: When I looked at the distance based work I was reminded of all
the Design Rule Checking (DRC) work I did while working in the
semiconductor industry for 30 plus years. A very big pile of very old
methods exists there  on which I the distance stuff is somewhat leaning
whether they know it or not. A pile of ideas / methods where we might do
well to beg, borrow and steal too (text object(1)).
(1)  Which if I ever get to back to Christoph's freetype work will be I
think a new character only object leaving 'text' as it exists with some
patches in my povr.
>
>> Your idea and/or a mix of those above there is a key component for
>> usefulness  some way to fade the isosurface function(s) at the hard
>> surface boundaries. Otherwise, we have gradient issues there  unless OK
>> with the container shape cutting or clipping the resultant shape.
>
> OK, but I still don't understand the gradient issue. We have CSG and flat
> planes and abrupt discontinuities in shapes all the time that the raytracer
> handles just fine. Why are the raymarching algorithms not struggling with this
> gradient thing, whereas we find it to be positively crippling in certain
> instances?
>
There IS equation/value continuity in ALL the underlying raysurface
equations with roots (surfaces) showing up at zero  anywhere we get a
clean result. All polynomial solvers returning 'all roots' require
continuity  otherwise the root isolation methods do not work reliably.
The only solver approach handling discontinuities in a general and safe
way  is a bisection(forwardmarching) solver  of which our isosurface
solver is a form (No I don't know if it lines up with any of the
published by name ones...).
With bisection you can have discontinuities so long as you sample enough
to not miss root ranges as the ray approaches actual roots. Once you
know you have a range with '' on one end and '+' on the other you can
always find at least one root (or discontinuity too actually) in that
range.
Aside: Range in hand with a root is where our isosurface solver  I
think  could probably close on the root faster so long as there is
local continuity. Thinking users would declare this is so by option 
and come what may. Even with continuity these faster methods are
something risky, depending. I believe I have in hand a foolproof  coded
from scratch NewRaphson/bisection univariate polynomial solver which
could be adapted for use inside the isosurface solver.
The disadvantage of bisection / marching solver approaches is you never
'really' know the number of roots  or whether you've found them all...
Our parametric and isosurface objects carry this shortcoming. It can be
a big one in csg and shadow testing, as examples.
I don't have all the answers. I never will. In my solver work I've
collected a set of books if stacked on the floor would be well over my
head. Papers, if printed, a stack many, many times that height. The
whole of it is way, way beyond me to digest.
There is the problem too, in the last 30 years say, of enormous amounts
of published noise in the field(2)... People need to publish for degrees
so there is loads of minorish, real, but practically, meaningless stuff
published. Figuring that out some touted by title thing isn't 'really'
useful takes so blasted much time! There are also niches and notches
where researchers are off doing things which seem related, but that
don't really apply to ray tracing. Folks off working on polynomials of
insane (for us) orders for various reasons...
Anyway, I'm starting to vent. I get frustrated too. :) You're asking
the right questions. If the answers were easy  wonderful, fast
solutions would be everywhere to be had doing everything we want. Be
thankful! That this not true, gives us a good hobby. ;)
My philosophy is to push on things. See if something opens up where
'relatively' easy progress can be made. If so, I work there until it
gets hard  or I get bored. Then I push on other stuff. I'm also,
slowly, pruning and changing povr to get it to a place where it's easier
to try some things on my idea pile.
Apologies for the mistakes  a fair bit of thinking aloud so to speak.
Bill P.
(2)  Book publishers own rights to older stuff  or stuff not selling
that well  that I can better afford. I believe now, those often spun up
by an author's students or hiredinfluencefolks. A fair number of the
books I've picked up aren't bad I guess. Often though, they're not
helpful in any practical, get something real done, way. A particular
popular one which is, has a license for the code therein which forces
open source efforts to "keep it on the shelf" for real code work.
Post a reply to this message


 
 


From: William F Pokorny
Subject: Re: Non  rgbf 1 pigment only applied to surface.
Date: 10 May 2020 10:51:10
Message: <5eb7dc9e$1@news.povray.org>



 
 


On 5/8/20 9:56 PM, Bald Eagle wrote:
>
>>> I'll also have to think about encoding a vector into a function so that the
>>> pattern {function{}} thing evaluates to the same VECTOR result everywhere  thus
>>> you could define a function intead of a vector and then use the dot notation in
>>> a function, whereas you currently can't use Vector.x in a function expression.
>>
>> Interesting idea... I'll let it bang around in my head.
>
> Kinda sorta works.
> I only played around with it enough to get basic functionality.
> Still some weird / awkward things about it all.
>
Thanks. Grabbed a copy of your code last night for future reference/play.
Bill P.
Post a reply to this message


 
 




 
 


William F Pokorny <ano### [at] anonymousorg> wrote:
> Thanks. Grabbed a copy of your code last night for future reference/play.
Sure thing. It's  rough. ;)
While coding up some other stuff, I was thinking about how to make isosurfaces
easier and faster to develop.
There must be a way to give feedback on a threshold that the user missed  such
as mistakenly using vlength() as the formula for a sphere rather than vlength()
 r.
I was thinking maybe sampling along a few vectors from the center of the AABB or
from the center of any points found.
That led to the idea of feedback on better bounded_by constraints. No one ever
renders an isosurface ONCE. If there's a lot of empty space, then maybe the
algorithm can keep a running tab on min/max extents of the actual object.
And maybe there's a way to take fewer samples when smoothing the gradient, but
interpolate more, in order to have fewer calculations and greater speed when
running prototypes.
BB optimization also would then be a further refinement. ;)
OK, off to work.
Post a reply to this message


 
 




 

