"Kenneth" my namesake, wrote:

> ...take all of
> the arrays' eval_pigment color values (and positions in the image), and somehow
> shove them into a FUNCTION of some sort-- to ultimately be applied as a *single*
> pigment function to a single flat box. But HOW to do this has always eluded me.

Because it's hiding under you nose - under the hood.
It the image_map "function" that is all shoved into ... one pigment pattern.

Throughout all of my experiments over the years, I've used POV-Ray to help teach
myself math, and computer graphics, which has helped me learn about POV-Ray, and
what actually goes on (or is supposed to go on) under the hood.

I dabble in ShaderToy because there is no (or very little) "under the hood".
You have to write it all yourself.  And that dispels the illusions of things
like light source, shadows, camera, 3D space....   it's all just "one function"
that evaluates to a certain rgb value at every x,y position of the screen, or
image file.

So how does a function work?
We take <x, y, z> and plug those into the function, which computes a color
value.

But you could also pre-calculate the color values, and store them - in a file -
to reference when you're looping through all of the position values - and that's
called an image file.  That gets implemented via the pigment {image_map} syntax.
Because IIRC POV-Ray even has a mechanism whereby you can "render" something in
memory and use that as an image_map style thing, without even rendering it, or
saving it to an image file first.

Now, you could manually construct a function as a giant polynomial that
intersects all the right rgb values given the right xyz values --- but that's
just encoding the image file data into an equation - which is probably wasteful
of effort, time, and storage.  But it's also likely the kind of thing that _I'd_
be likely to do, in order to learn how to do it, prove that it's possible, and
possibly learn another dozen things and raise 34 more questions in the process.

You likely don't have to store ALL of the image data, if a lot of it is the same
- and then you can write a function, or an algorithm that encodes a lot of data
with - less data.   That is image compression.
In the 80's, I was making a world map on an Atari 800 XL, and it seemed silly to
store EVERY "pixel" of the map, when I was only dealing with 2 colors, and I had
long stretches of same-color pixels.  So I defined them as "lines" (or "boxes")
and just saved the starting point and the length.  Like assembling a hardwood
floor.

So how does one take 48,000 boxes and color them all with one function?

union {
.... all your boxes ...
pigment {image_map}
}

All those boxes get immersed into the region where the image_map correlates to
the 3D space coordinates.  It creates a 1:1 correspondence - a look-up table - a
function - that does what you'd essentially be doing from scratch, or through a
roundabout way with a hand-written function.


At least that's how it all works in my head at this point in time.   There may
be some nuances and POV-Ray specific source code things that don't quite work in
exactly that way...   but I hope this helps you "wrap your head around it"?


- Bill

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
>
> Because it's hiding under you nose - under the hood.
> It the image_map "function" that is all shoved into ... one pigment pattern.
> [snip]
> So how does a function work?
> We take <x, y, z> and plug those into the function, which computes a color
> value.
>
> But you could also pre-calculate the color values, and store them - in a
> file-- to reference when you're looping through all of the position values -
> and that's called an image file.  That gets implemented via the pigment
> {image_map} syntax.

Yeah, I guess that my 'dream scheme' of...
     trace --> eval_pigment --> a SINGLE function{pigment...} [somehow?]
....is kind of an attempt to mimic what goes on 'under the hood'... a sort of
'reverse engineering' scheme, devised in SDL.

The seemingly effortless way that POV-ray itself can take an image_map and turn
it into a single function{pigment...}-- with all of the original pixels in the
correct order-- is like Black Magic to me.
>
> Now, you could manually construct a function as a giant polynomial that
> intersects all the right rgb values given the right xyz values --- but that's
> just encoding the image file data into an equation - which is probably
> wasteful of effort, time, and storage.

Yeah, those little caveats did occur to me. :-[
I agree: My hoped-for scheme seems to be not-so-elegant after all. Compared to
that, my older scheme of...
       trace --> eval_pigment --> 480,000 colored boxes
.... suddenly looks like an elegant and simple stroke of genius! :-P
>
> So how does one take 48,000 boxes and color them all with one function?
>
> union {
> .... all your boxes ...
> pigment {image_map}
> }
>
Yes, very straightforward-- once my single and way-too-elaborate function itself
is created! But I guess I need to discard my eval_pigment idea itself as
unworkable (i.e., initially evaluating every *individual* pixel of an input
image, to ultimately create some sort of single function to represent all the
colors and pixel positions.)

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Bald Eagle" <cre### [at] netscapenet> wrote:
> >
> > Because it's hiding under you nose - under the hood.
> > It the image_map "function" that is all shoved into ... one pigment pattern.
> > [snip]
> > So how does a function work?
> > We take <x, y, z> and plug those into the function, which computes a color
> > value.
> >
> > But you could also pre-calculate the color values, and store them - in a
> > file-- to reference when you're looping through all of the position values -
> > and that's called an image file.  That gets implemented via the pigment
> > {image_map} syntax.
>
> Yeah, I guess that my 'dream scheme' of...
>      trace --> eval_pigment --> a SINGLE function{pigment...} [somehow?]
> ....is kind of an attempt to mimic what goes on 'under the hood'... a sort of
> 'reverse engineering' scheme, devised in SDL.

But what you're essentially doing is exactly that.  Because there is no
"function" - it's a look-up table - reading in the color values for each x,y
pixel in the image.   It's simply the fact that it's done under the hood, via
compiled source code, that makes it seem "different".

povray-3.7-stable/povray-3.7-stable/source/backend/support/imageutil.cpp

bool image_map(const VECTOR EPoint, const PIGMENT *Pigment, Colour& colour)
{
 int reg_number;
 DBL xcoor = 0.0, ycoor = 0.0;

 // If outside map coverage area, return clear

 if(map_pos(EPoint, ((const TPATTERN *) Pigment), &xcoor, &ycoor))
 {
  colour = Colour(1.0, 1.0, 1.0, 0.0, 1.0);
  return false;
 }
 else
  image_colour_at(Pigment->Vals.image, xcoor, ycoor, colour, &reg_number,
false);

 return true;
}

"If the x,y position is outside of the image area, return a clear value, else
return the color of the image at that x,y value."
No function.   Just an algorithm in a loop.

> The seemingly effortless way that POV-ray itself can take an image_map and turn
> it into a single function{pigment...}-- with all of the original pixels in the
> correct order-- is like Black Magic to me.

Why?  Can we even count the number of software packages that can do that?
What about a movie player that can read them in fast enough to give you greater
than 15 fps?

> Yeah, those little caveats did occur to me. :-[
> I agree: My hoped-for scheme seems to be not-so-elegant after all. Compared to
> that, my older scheme of...
>        trace --> eval_pigment --> 480,000 colored boxes
> .... suddenly looks like an elegant and simple stroke of genius! :-P

I've done that kind of the opposite way - tracing objects, and converting the
height to a color value, but I realized it was just as easy to do with a
gradient pigment pattern...

Now, what I have wanted, and suggested in the past, is for there to be a
mechanism by which the compiled source code stores all the color data for an
image file in an SDL-accessible 2D array.   Which would kinda give you what you
want without all of the mucking around.

> > So how does one take 48,000 boxes and color them all with one function?
> >
> > union {
> > .... all your boxes ...
> > pigment {image_map}
> > }
> >
> Yes, very straightforward-- once my single and way-too-elaborate function itself
> is created! But I guess I need to discard my eval_pigment idea itself as
> unworkable (i.e., initially evaluating every *individual* pixel of an input
> image, to ultimately create some sort of single function to represent all the
> colors and pixel positions.)

what about function {pigment {image_map}}  ?

And I guess I should point out that _form_ follows _function_.
What do you want to do with the function once you've got it, that you need to
have it in function form?

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:

> But what you're essentially doing is exactly that.  Because there is no
> "function" - it's a look-up table - reading in the color values for each x,y
> pixel in the image.   It's simply the fact that it's done under the hood, via
> compiled source code, that makes it seem "different".
>
> [aource-code snippet]
>
> "If the x,y position is outside of the image area, return a clear value, else
> return the color of the image at that x,y value."
> No function.   Just an algorithm in a loop.

Fascinating! Thanks; that actually helps me to understand what's going on--
MUCH more than I knew previousy! The Black Magic mystery is slowly starting to
become clear...

>
> Now, what I have wanted, and suggested in the past, is for there to be a
> mechanism by which the compiled source code stores all the color data for an
> image file in an SDL-accessible 2D array.   Which would kinda give you what
> you want without all of the mucking around.

YES, that would be an interesting feature, and I '2nd' the vote.

> And I guess I should point out that _form_ follows _function_.
> What do you want to do with the function once you've got it, that you need to
> have it in function form?

That's a good question. My main answer would be, just to see if could be done.
And to try and better-understand the real power of function use in SDL. I've
used functions for years in POV-ray, but in relatively simplistic ways; I
haven't yet grasped the 'how-to's' of more complex combinations and usages.
(E.g., trying to turn a bunch of eval_pigment colors into a function, *via* pure
SDL equations. Etc.)

[Btw, my apologies to Robert M for going off-topic here]

Post a reply to this message

I started working on this CSG starship asset a few days ago. It's built using
only tori, cones, cylinders, spheres and superellipsoids.

My working scene file for building the ship has multiple instances of the object
rotated and translated in various ways so I can see it from many angles
at once, which makes it much easier to tweak things.

Just for fun I'm planning to make a short animation of the ship coming out of
hyperspace and heading to the alien moon...

Post a reply to this message

Attachments:
Download 'spaceshipmultiview.jpg' (322 KB)

Preview of image 'spaceshipmultiview.jpg'

Op 25/02/2021 om 18:26 schreef Robert McGregor:
> I started working on this CSG starship asset a few days ago. It's built using
> only tori, cones, cylinders, spheres and superellipsoids.
> 
> My working scene file for building the ship has multiple instances of the object
> rotated and translated in various ways so I can see it from many angles
> at once, which makes it much easier to tweak things.
> 
> Just for fun I'm planning to make a short animation of the ship coming out of
> hyperspace and heading to the alien moon...
> 

Good modelling! This is where a new version of Moray would be welcome...

-- 
Thomas

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> Op 25/02/2021 om 18:26 schreef Robert McGregor:
> > I started working on this CSG starship asset a few days ago. It's built using
> > only tori, cones, cylinders, spheres and superellipsoids.

Well that's some clever usage, because it leaves me puzzling over the main body.


> Good modelling! This is where a new version of Moray would be welcome...

I'll say.  The placement of all of those little pieces makes me wonder if it was
done by eye and feel, or if there was some analytical geometry involved.
Tapping an arrow key to nudge a shape in a modeler is vastly more attractive for
most projects than calculating the depth of an arc, given a certain span it
needs to nestle into, or any of that stuff....

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> Good modelling! This is where a new version of Moray would be welcome...

Thanks Thomas, and I agree, when building complex CSG models it sure would be
nice to be able to use a modeler that works with POV-Ray primitives.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:

> Well that's some clever usage, because it leaves me puzzling over the main body.

Ah, I forgot to mention that I used planes for differencing also, to carve off
sections of supellipsoids at 45 degree angles, etc.


> The placement of all of those little pieces makes me wonder if it was
> done by eye and feel, or if there was some analytical geometry involved.
> Tapping an arrow key to nudge a shape in a modeler is vastly more attractive for
> most projects than calculating the depth of an arc, given a certain span it
> needs to nestle into, or any of that stuff....

All of this was done by eye and feel. I started with the engine as a couple of
cones and some tori at the origin and just started making little parts that are
unioned into subassemblies and rotated around. Each piece was done the same way,
as working at the origin is pretty straightforward and assemblies can be easily
moved into final position.

Cheers,
Rob

Post a reply to this message

I'm pretty happy with the ship model overall. I fine-tuned a few things on the
engine assembly and started texturing the engines with some greebling, etc. I'm
also working on a media glow "exhaust" that's triggered by a boolean switch in
my main scene file to render with engines either on or off:

#declare EngineActive = 1; // On/off to toggle powered-up engines

Here's the source for the engine assembly, without textures. As you can see it's
really not very complicated:

//------------------------------------------------------------------------------
// EngineAssembly.inc
//------------------------------------------------------------------------------

#declare EngineColor = SummerSky+White;
#declare EngineHole = sphere { 0, 0.75 translate y*1 }
#declare EngineTailBase = cone { 1*y,  0.75, -1*y, 1.25 }
#declare Glow = sphere { 0, 1 pigment { rgbt 1 }}  // coming soon

#declare widget1 = union {
   cylinder {  <0, 1, 0><0, -1, 0>, 0.1 }
   sphere { <0,1,0>, 0.1 }
   sphere { <0,-1,0>, 0.1 }
   scale 0.75
   translate -y*0.25
   rotate z*14
   translate x*1
}

#declare widget2 =
superellipsoid { <0.2, 0.2>
   scale <0.1, 0.8, 0.1>
   translate y*0.25
}

#declare widget3 =
superellipsoid { <0.2, 0.2>
   scale <0.15, 0.1, 0.2>
}

#declare widget4 = union {
   object { widget2 }
   object { widget3 translate -y*0.5 }
   object { widget3 translate y*0.5 }
   rotate z*14
   translate x*1
   rotate y*45
}

#declare widget5 = union {
   object { widget2 }
   object { widget3 translate -y*0.5 }
   object { widget3 translate y*0.5 }
   scale y*1.25 translate -y*0.5
}

#declare rot1 = 360/12;
#declare rot2 = 360/6;
#local cnt = 0;

#declare widget1_Assembly =
union {
   #while (cnt < 12)
      object { widget1 rotate y*rot1*cnt }
      #local cnt = cnt + 1;
   #end
}

#declare cnt = 0;
#declare widget4_Assembly =
union {
   #while (cnt < 6)
      object { widget4 rotate y*rot2*cnt }
      #local cnt = cnt + 1;
   #end
   rotate -y*15
}

#declare EngineTail =
union {
   torus { 0.8, 0.05 scale y*3 translate y*1 }
   torus { 1.25, 0.05 scale y*3 translate -y*1 }
   difference {
      union {
         difference {
            object { EngineTailBase }
            object { EngineHole }
         }
         object { widget4_Assembly }
      }
      object { widget1_Assembly }
   }
}

#declare EngineTailTop = cone { 1.65*y,  0.75, -1*y, 1.25
   rotate x*180
   translate -y*2
}

#declare EngineDoodad = object { EngineTail
   scale 0.35
   rotate -x*104
   translate -y*2.25
   translate -z*1
   rotate y*90
}

#declare Engine =
union {
   object { EngineTail }
   #if (EngineActive)
      sphere { 0, 0.5
         pigment { EngineColor*0.7 }
         finish { emission 0.9 ambient 0.9 diffuse 0 }
         translate y*0.7
      }
      object { Glow }
   #end

   object { EngineTailTop }
   object { EngineTail
      scale 0.7
      rotate x*180
      translate -y*4
   }
   object { EngineDoodad rotate y*360/6*1 }
   object { EngineDoodad rotate y*360/6*2 }
   object { EngineDoodad rotate y*360/6*3 }
   object { EngineDoodad rotate y*360/6*4 }
   object { EngineDoodad rotate y*360/6*5 }
   object { EngineDoodad rotate y*360/6*6 }
   rotate x*180
}

Post a reply to this message

Attachments:
Download 'engineassembly.jpg' (547 KB)

Preview of image 'engineassembly.jpg'