Is there a way to apply a gradient texture to multiple objects, such that the
texture map at 0 is one texture, but the texture map at 1 is a texture unique to
the 2 individual objects?

I'm picturing something along the lines of a pane of glass in a box, and there's
a gradient of texture applied across the whole (unioned ?) object, such that the
texture at 0 is something bland or transparent, and as the gradient sweeps
across both objects, it affects them both equally along the same plane, as
though the entire multiple-primitive "object" in the scene had this special
gradient type applied to it.

I hope that's clear?

Post a reply to this message

On 19-7-2014 23:27, Bald Eagle wrote:
> I hope that's clear?
>
>
I am not sure but maybe a trick proposed by Janet (aka Parrotdolphin) 
may be what you need. I add the necessary example files as a zip here.

Thomas

Post a reply to this message

Attachments:
Download 'janettrick.zip' (92 KB) Download 'janets trick.png' (317 KB)

Preview of image 'janets trick.png'

Thanks Thomas!  The pigment_pattern and related image_pattern look like VERY
interesting tools to explore.  I've got a few things to do this morning, but
hopefully I'll get a halfway decent scene worked up to see how close I can get
to what I want.

Looking back through some older threads, it looks like the major issue is being
unable to override the texture that the object is defined to have.  I've gotten
a sort of really messy work-around to give me an approximation of what I wanted,
but  it's pretty limited, and I'm still not that good at layered textures or
scene construction to get something more elegant.

I didn't really understand this from the documentation:
"In the PLAIN_TEXTURE, each of the items are optional but if they are present
the TEXTURE_IDENTIFIER must be first. If no texture identifier is given, then
POV-Ray creates a copy of the default texture. See "The #default Directive" for
details.
Next are optional pigment, normal, and/or finish identifiers which fully
override any pigment, normal and finish already specified in the previous
texture identifier or default texture. Typically this is used for backward
compatibility to allow things like: texture { MyPigment } where MyPigment is a
pigment identifier."

Not assigning a texture gives a default texture (black), which looks like it CAN
be textured in a union. It would be useful to be able to have access to that
default texture, or to be able to assign NO texture WITH a texture statement.

I thought that maybe using a function to define the texture might somehow get
POV-Ray to reevaluate it, but I see there's major impediments to the
implementation of that as well.

I'll try to post some WIPS so you can see where this is going.

Post a reply to this message

Am 20.07.2014 15:37, schrieb Bald Eagle:

> I didn't really understand this from the documentation:
> "In the PLAIN_TEXTURE, each of the items are optional but if they are present
> the TEXTURE_IDENTIFIER must be first. If no texture identifier is given, then
> POV-Ray creates a copy of the default texture. See "The #default Directive" for
> details.
> Next are optional pigment, normal, and/or finish identifiers which fully
> override any pigment, normal and finish already specified in the previous
> texture identifier or default texture. Typically this is used for backward
> compatibility to allow things like: texture { MyPigment } where MyPigment is a
> pigment identifier."
>
> Not assigning a texture gives a default texture (black), which looks like it CAN
> be textured in a union. It would be useful to be able to have access to that
> default texture, or to be able to assign NO texture WITH a texture statement.

The default texture mentioned here is the thing you can set via:

     default {
       texture { ... }
     }

Whenever you specify a texture without a TEXTURE_IDENTIFYER to "inherit" 
from, POV-Ray plugs in whatever this default texture is /currently/ set 
to; thus, the following are perfectly equivalent:

     // (A)
     default { texture {
        ... // some default texture settings
     }}
     #declare Foo = texture { ... }
     default { texture {
        ... // some other default texture settings
     }}
     #declare Bar = texture { ... }


     // (B)
     #declare DEFAULT = texture {
        ... // some default texture settings
     }
     #declare Foo = texture { DEFAULT ... }
     #declare DEFAULT = texture {
        DEFAULT
        ... // some other default texture settings
     }
     #declare Bar = texture { DEFAULT ... }

Post a reply to this message

> Is there a way to apply a gradient texture to multiple objects, such that the
> texture map at 0 is one texture, but the texture map at 1 is a texture unique to
> the 2 individual objects?
>
> I'm picturing something along the lines of a pane of glass in a box, and there's
> a gradient of texture applied across the whole (unioned ?) object, such that the
> texture at 0 is something bland or transparent, and as the gradient sweeps
> across both objects, it affects them both equally along the same plane, as
> though the entire multiple-primitive "object" in the scene had this special
> gradient type applied to it.
>
> I hope that's clear?
>
>

Whenever you group several objects in an union, if you apply any texture 
to the union itself, then that texture will be applyed to every objects 
of the union. The exeption is any object that already have their own 
texture that will retain that individualy applyed texture.

So, you can have this:
union{
  object{GlassPane}
  object{MyBox}
  pigment{gradient x+y color_map{[0 rgb 1][1 rgbt 1]}scale 3}
}



Alain

Post a reply to this message

> Whenever you specify a texture without a TEXTURE_IDENTIFYER to "inherit"
> from, POV-Ray plugs in whatever this default texture is /currently/ set
> to; thus, the following are perfectly equivalent:
>
>      // (A)
>      1.      default { texture {... // some default texture settings}}
>      2. #declare Foo = texture {... }
>      3.      default { texture {... // some other default texture settings}}
>      4. #declare Bar = texture {... }
>
>
>      // (B)
>      1. #declare DEFAULT = texture {... // some default texture settings}
>      2. #declare Foo =     texture { DEFAULT ... }
>      3. #declare DEFAULT = texture {DEFAULT... // some other default texture
settings}
>      4. #declare Bar =     texture { DEFAULT ... }

Thanks Christoph,
If I follow that, in (A), textures 1&2 are identical, and 3&4 are identical.
And, as you say, the same is true for (B).

I think what I'm actually up against here is that when an object is declared,
its associated texturing is fixed at the time it's declared.  Changing the
texture after that has no effect.

{For example, I grabbed an intersection of some objects, differenced away those
pieces, and planned on adding back the retextured intersected parts - but they
already have the static texture they were defined with.}

object {INTERSECTION texture {NEW}}  doesn't work.

Part of my clunky solution was to define my objects with no texture in a union
which was instantiated by a macro.  Then I defined a texture to be applied to
the objects, and re-instantiated the unioned objects using the new texture.
Just getting back to this now, so I'll see what logical and practical headway I
make...

Post a reply to this message

Am 20.07.2014 22:09, schrieb Bald Eagle:
>
> {For example, I grabbed an intersection of some objects, differenced away those
> pieces, and planned on adding back the retextured intersected parts - but they
> already have the static texture they were defined with.}

Note that you /can/ specify objects without any texture at all; if you 
use such objects in CSG, they will "inherit" the texture of the union 
(or merge, difference, intersection) you put them in, rather than the 
default texture.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

> Note that you /can/ specify objects without any texture at all;

Right, I've played with that a bit.

> if you
> use such objects in CSG, they will "inherit" the texture of the union
> (or merge, difference, intersection) you put them in, rather than the
> default texture.

Indeed.  I don't know how the back end of things works, but it would be useful
to be able to reset to the default texture or override the existing texture.
I'm sure there are things firmly rooted in the basic code structure of how it
all works that might make that difficult to implement.  I don't know how hard it
would be to slip in a no_texture flag that would trigger a new instantiation of
the object and cause any defined textures to be ignored...

Post a reply to this message

So, after some more dabbling, in the absence of being able to override an
object's texture, or have a texture applied to a union, etc. be layered over all
other existing textures, it seems that the fundamental issue is getting a
mapping of the  texture intended to be common to all the objects aligned along
the individual components.

I haven't done that much exploring in the texture world, so I see a lot of
experimentation and calculation ahead.

Let's say we have 4 cylinders.  2 upright, and 3 horizontal: |==|
What I'm envisioning is texturing the left side of the "slice" through all of
the objects with one texture, and having all of the remaining stuff on the right
side of the "slice" showing whatever other textures they are defined with.

|=\=|

I'm _guessing_ that if I define a texture and don't translate it, then it's
"centered" around the origin, and when I translate the object itself, it sort of
"travels through a cloud of texturing" in POV-space. Like a gradient x.  (If I
translate the texture, then I slide the texture cloud through POV-space over the
stationary object)  Save me from myself if I'm woefully wrong about this.

Then I rotate it around -z, and I get my "slice" effect.  Hopefully all the
cylinders with the split texture-mapping will have the gradients line up in
register.

The Janet trick is intriguing, though I haven't had much success with blending a
rastered grid texture at [0] to a solid pigment at [1].  A-POVving I shall go...

Post a reply to this message

Am 22.07.2014 03:35, schrieb Bald Eagle:

> I'm _guessing_ that if I define a texture and don't translate it, then it's
> "centered" around the origin, and when I translate the object itself, it sort of
> "travels through a cloud of texturing" in POV-space. Like a gradient x.  (If I
> translate the texture, then I slide the texture cloud through POV-space over the
> stationary object)  Save me from myself if I'm woefully wrong about this.

That depends: If you explicitly specify a texture for an object, and 
/then/ translate the object around, the texture travels around with the 
object.

Post a reply to this message