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

Le 2020-05-07 à 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 POV-Ray 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

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 POV-Ray 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 un-thought-through 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

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. Random-ish 
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/POV-Ray/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 ray-surface shape. CSG would perhaps always 
be some isosurface where the ray-surface intersections are only giving 
us the collection of shape-functions 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 ISOs-inside' 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 un-thought-through 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/POV-Ray/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 SDL-coded 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 ray-marching to "get close to" the result, with the
ray-tracing being the fine-tuning 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.  ;)
Pre-defining square-roots 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 POV-Ray 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 ray-surface shape. CSG would perhaps always
> be some isosurface where the ray-surface intersections are only giving
> us the collection of shape-functions 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

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 ray-surface 
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(forward-marching) 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 New-Raphson/bisection uni-variate 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 minor-ish, 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 hired-influence-folks. 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 there-in which forces 
open source efforts to "keep it on the shelf" for real code work.

Post a reply to this message

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