Inside out MandalayBox

[3dickulus]

Modified MandalayBox.frag, looking for colors found another dimension of complexity

Code:

// coordinate to invert to infinity
uniform vec3 InvertC; slider[(-5,-5,-5),(0,0,0),(5,5,5)]

// Roqen's domain mashup performs the active c = T(s)
vec3 domainMap(vec3 c)
{
  float s = dot(c,c);
  return c/s * InvertC;
}

float DE(vec3 p) {
     // first line
     p = InvertC ? domainMap(-p) : p;

     // the rest of the DE() function
}

<a href="http://vimeo.com/moogaloop.swf?clip_id=129356171" target="_blank">http://vimeo.com/moogaloop.swf?clip_id=129356171</a>
and this is zoomed into the round part of the surface at the first pause in morphing, that's where it's inside out I think

http://www.fractalforums.com/index.php?action=gallery;sa=view;id=17854 for the full 3840x2160 version

[visual.bermarte]

Nice, shouldn't be

Code:

uniform bool Invert; checkbox[false]

and then

Code:

p=(Invert ? domainMap(-p) : p);

[3dickulus]

yes, that works, as does...

Code:

p=(InvertC != vec3(0,0,0)) ? domainMap(-p) : p);

but they seem to look/act a little differently, as it is, it gets cast to bvec3
not being a mathmatician myself, I couldn't tell you if it should or shouldn't be something else, there are probably better ways, but it gets a look that I like and plan to explore

[visual.bermarte]

Macs are more picky
with

Code:

p = InvertC ? domainMap(-p) : p;

I get

Code:

Error: Condition must be of type bool

[3dickulus]

hmmm... I get...

Code:

Fragment shader compiled with warnings: Fragment info
-------------
0(1166) : warning C7509: OpenGL requires the selection first expression to be a scalar boolean
0(1166) : warning C7011: implicit cast from "vec3" to "bvec3"

Compiled script in 85 ms.

just warning, no error, so it's a 3 way bool opperation that acts a bit different than a single bool switch?

[Syntopia]

I was also quite puzzled about this. The standard says that: "The ternary selection operator (?. It operates on three expressions (exp1 ? exp2 : exp3). This
operator evaluates the first expression, which must result in a scalar Boolean. ", so I don't think there is a 3-way ternary operator.

Your image looks great. Would you mind posting the entire DE?

[3dickulus]

I'm not sure exactly how it gets handled internally by the compiler (although I should have a look at the asm dump) but...
using a single bool flag for deciding to do the operation or not,
using vec3(0,0,0) or
using cast to bvec3 (implemented by compiler with warning)

the first 2 produce the same result while bvec3 does not seem to have  this effect

the settings are identical for the pics except for the (single) bool being switched, I think that when using bVec3 transitioning through 0 it either never exactly hits 0 or when @0 it switches out the distortion from the domainMap() function, but when using a bool flag it's on through 0... does that make sense?
my understanding is that when casting to bool from float in GLSL 0 == false and anything else, + or -,  == true

I believe you are correct re:3-way ternary operator 

The DE is MandelayBox.frag as provided by knighty using the mod described above (attached), no other changes
using support files 3DKn-1.0.1.frag  BufferShader-1.0.1.frag  DE-Kn2.frag  MathUtils.frag

[3dickulus]

my assumptions about GLSL booleans...

A == B ? C = A : C = B

using vec3 would go something like this...

A.x == B.x ? C.x = A.x : C.x = B.x
A.y == B.y ? C.y = A.y : C.y = B.y
A.z == B.z ? C.z = A.z : C.z = B.z

which is a very easy thing for GPU to do

the error is only generated when InvertC (float vec3) is tested by itself against true/false (bool single), when tested against another vec3 there is no error reported, hence my assumption

edit: I think that the compiler should cast the single bool to match the type required before the test without complaining because vec3(0) is valid