I want to know how do I go about implementing a new pigment type. It's not a
pattern, and it's not a new bitmap file format for image_map; I have to get
a x,y,z point as input and return a rgbt color.

Would be also good if someone could give me some basic pointers on where to
start modifying the parser to read parameters for it (although that's kind
of low priority, especially considering I have yet to look at the parser
code).

I've been reading 3.7 code. Congratulations and thanks on the new C++ified
structure of the primitive shapes, even if other stuff (like pigments) are
still C-ish :) I wonder what does the Post_Pigment function do? The 21-line
comment before it (like before every other function) is, as usual,
content-less, and I can't figure out its purpose (at least not at 1:30 am).

Post a reply to this message

> -----Original Message-----
> From: Nicolas Alvarez [mailto:nic### [at] gmailcom]
> I want to know how do I go about implementing a new pigment type. It's
> not a
> pattern, and it's not a new bitmap file format for image_map; I have
to
> get
> a x,y,z point as input and return a rgbt color.

Have you implemented it as a function in SDL?


...Ben Chambers
www.pacificwebguy.com

Post a reply to this message

Chambers wrote:
>> -----Original Message-----
>> From: Nicolas Alvarez [mailto:nic### [at] gmailcom]
>> I want to know how do I go about implementing a new pigment type. It's
>> not a pattern, and it's not a new bitmap file format for image_map; I
>> have to get a x,y,z point as input and return a rgbt color.
> 
> Have you implemented it as a function in SDL?

No. I haven't implemented it yet :) Although I will surely start my C++
hacking by implementing a *very* simple pigment that you could just do in
SDL!

My final goal is something that I don't think is possible at all from SDL.

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailcom> wrote:
> Chambers wrote:
> >> -----Original Message-----
> >> From: Nicolas Alvarez [mailto:nic### [at] gmailcom]
> >> I want to know how do I go about implementing a new pigment type. It's
> >> not a pattern, and it's not a new bitmap file format for image_map; I
> >> have to get a x,y,z point as input and return a rgbt color.
> >
> > Have you implemented it as a function in SDL?
>
> No. I haven't implemented it yet :) Although I will surely start my C++
> hacking by implementing a *very* simple pigment that you could just do in
> SDL!
>
> My final goal is something that I don't think is possible at all from SDL.

I think what Chambers meant is have you tried using a pigment-related function
in SDL.  You can use a custom function as your pigment pattern, and it can take
an x,y,z point (or x,y,z,t,a,b,c,...) and spit out a value to be used with a
color map.  This value is a float, not a vector, but you could have variation
of your function for each channel.

Then, there are also pigment functions, in which you can specify an x,y,z
coordinate, and a the color vector associated with that coordinate is returned.

Can you describe what the desired end result is?


-Reactor

Post a reply to this message

Reactor wrote:
> Can you describe what the desired end result is?

Hmm fine...

Ability to use a svg in a pigment, like an image_map, without first
rendering it as a fixed-resolution bitmap.

If you think that's possible from SDL, you're welcome to try :)

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailcom> wrote:
> Reactor wrote:
> > Can you describe what the desired end result is?
>
> Hmm fine...
>
> Ability to use a svg in a pigment, like an image_map, without first
> rendering it as a fixed-resolution bitmap.
>
> If you think that's possible from SDL, you're welcome to try :)

Offhand, I'd probably make a macro to read the SVG file and produce and object
for use with the an object pigment.  That way, you have the arbitrary
resolution that the SVG file permits, and you could, in theory, implement just
about all of the features that SVG 1.2 has.


-Reactor

Post a reply to this message

Reactor wrote:
> Offhand, I'd probably make a macro to read the SVG file and produce and
> object
> for use with the an object pigment.  That way, you have the arbitrary
> resolution that the SVG file permits, and you could, in theory, implement
> just about all of the features that SVG 1.2 has.

There is no object pigment, just an object pattern.

And I hope you didn't mean "macro" as in "POV-Ray #macro". It would be
*hell* to try parsing XML from SDL!

Post a reply to this message

Nicolas Alvarez <nic### [at] gmailcom> wrote:
> Reactor wrote:
> > Offhand, I'd probably make a macro to read the SVG file and produce and
> > object
> > for use with the an object pigment.  That way, you have the arbitrary
> > resolution that the SVG file permits, and you could, in theory, implement
> > just about all of the features that SVG 1.2 has.
>
> There is no object pigment, just an object pattern.
>
> And I hope you didn't mean "macro" as in "POV-Ray #macro". It would be
> *hell* to try parsing XML from SDL!

Sorry, that is what I meant, object pattern.  Since you could use a full pigment
for list item A and B, you could, in theory, make it do whatever you need,
including use the colors from the SVG.

I did mean parsing from SDL, I only recommended it because I don't know what
other languages you know.  That being said, an SVG reading script would be very
nice for your purposes and others, if you add it to the library.  I know this
came up before when someone was using InkScape as a path editor for lathe and
prism objects by reading the SVG file.

-Reactor

Post a reply to this message

Reactor wrote:
> I did mean parsing from SDL, I only recommended it because I don't know
> what other languages you know.

I'm good at C++, not quite good enough at understanding foreign code, and
bad enough at maths to not understand most of POV-Ray code :D

Post a reply to this message

Nicolas Alvarez wrote:
> I want to know how do I go about implementing a new pigment type. It's not
> a pattern, and it's not a new bitmap file format for image_map; I have to
> get a x,y,z point as input and return a rgbt color.
> 
> Would be also good if someone could give me some basic pointers on where
> to start modifying the parser to read parameters for it (although that's
> kind of low priority, especially considering I have yet to look at the
> parser code).

I want to report I got a very basic pigment working in like 15 minutes.

sphere {
  <0,0.5,0>,0.5
  pigment {
    my_test
  }
}

Renders a green sphere. "my_test" is a new keyword, not a pre-#declared
pigment. The code that calculates the pigment color is pretty simple:

      case MY_PATTERN:
        Make_Colour(Colour, 0.0, 1.0, 0.0);
        Colour_Found = true;
        break;

Post a reply to this message