Mike Horvath <mik### [at] gmailcom> wrote:
>
> Is it possible to create an empty texture? In this case, I could swap
> out the current textures and instead apply one texture to the entire
> scene. Without too much effort on my part if it works.
>

Yes, you can create an empty texture, like this...  texture{}  .... which, as
far as I know, is the same as having no texture statement at all-- in which case
POV-Ray substitutes it's own default texture (the common black color which we've
all seen.)  BUT, if you create your *own* #default{....} texture, then the
'empty texture' statement will use that instead. Which leads to something
interesting...

> Stephen wrote:
> Why not put your textures in an INC file then you could put your
> alternative textures in another INC file. If they have the same names
> you can select which set of textures to use by using the #include command.

Combining Stephen's idea with the above #default texture scheme could produce
what you're looking for-- the 'color blend' on all the objects in your scene,
from z = 0 to z = *whatever distance*.  (I can't say that it's less WORK than
simply commenting-out your original scene textures, the way Thomas and I
mentioned earlier, but it's worth trying.)

The idea is to put all of your 'main' scene textures into one #include file, and
the RED-to-GREEN 'overall depth texture' into another #include file (this will
be your #default texture.) Then you #include one or the other of these files
into your scene. I just tried this scheme, and here's an example of how it would
work:

(Assume that you have only three objects in your scene, just as a
demonstration:)

--- main scene file--
// the three objects
sphere{.... texture{TEX_1}
box{.... texture{TEX_2}
cylinder{.... texture{TEX_3}


The two #include files would be written like this (simple text files):

--- 'main' textures file called "REAL TEXTURES" --
#declare TEX_1 =
 texture{
 pigment{srgb <.7,.3,.5>}
 finish{ambient .2 diffuse .8}
 }

#declare TEX_2 =   // different from TEX_1
 texture{
 pigment{srgb <.2,1.3>}
 finish{ambient .5 diffuse .5}
 }

#declare TEX_3 =   // different from TEX_1 and TEX_2
 texture{
 pigment{srgb .5}
 finish{ambient .2 diffuse .8}
 }


--- the 'color blend' texture file, called "COLOR BLEND TEXTURE" ---
#default{
 texture{  // blend of RED to BLUE along z-axis
  pigment{
   gradient z
   color_map{
    [0 srgb <1,0,0>] // RED
    [1 srgb <0,0,1>] // BLUE
    }
   scale 1000*z // or similar, to cover entire z-depth of scene
   }
  finish{ambient .2 diffuse .8}
  }
 }

#declare TEX_1 = texture{}
#declare TEX_2 = texture{}
#declare TEX_3 = texture{}

-----------
Then just #include one or the other of these files into your scene (at the
beginning somewhere.) The 'main' textures will all be changed to the single
color-blend texture, on all the objects.

The only drawback is how to get an exponential or logarithmic color blend in the
color_map, rather than a linear blend (referring to your other post); offhand, I
don't know how that could be done.

Post a reply to this message

Am 17.01.2016 um 09:39 schrieb Kenneth:
> Mike Horvath <mik### [at] gmailcom> wrote:
>>
>> Is it possible to create an empty texture? In this case, I could swap
>> out the current textures and instead apply one texture to the entire
>> scene. Without too much effort on my part if it works.
> 
> Yes, you can create an empty texture, like this...  texture{}  .... which, as
> far as I know, is the same as having no texture statement at all-- in which case
> POV-Ray substitutes it's own default texture (the common black color which we've
> all seen.)  BUT, if you create your *own* #default{....} texture, then the
> 'empty texture' statement will use that instead. Which leads to something
> interesting...

There are some differences between explicitly specifying "texture{}",
and not specifying any texture at all.

The first difference is in what version of the default you get: If you
specify "texture{}", you will get whatever the default is set to when
you /construct/ the object, whereas if you don't specify any texture at
all, you will get whatever the default is when you actually /insert/ the
object into the scene.

The second difference is in what happens if the object is used in a CSG
with an explicit texture: If you specify "texture{}", the object will
stubbornly cling to the default texture, whereas if you specify no
texture at all, the object will inherit any texture set on the parent.

Take the following example:

//==============================================

#version 3.7;

camera {
  location  <3,5,-7>
  right     x*image_width/image_height
  look_at   <0,1,0>
}

light_source{ <1,2,-3>*3000 colour rgb 1 }

//----------------------------------------------
#default { pigment { colour red 1 } }
//----------------------------------------------

// The plane and box have no texture at all,
// and will remain "open to new suggestions":
#declare Plane  = plane  { <0,1,0>, 0 }
#declare Box    = box    { <-2,0,-1>, <0,2,1> }

// The sphere's texture is fixed forever to red here:
#declare Sphere = sphere { <1,1,0>, 1 texture {} }

//----------------------------------------------
#default { pigment { colour green 1 } }
//----------------------------------------------

// The front union per se has no texture either,
// and will remain "open to new suggestions"
// (except for the sphere, which is fixed to red):
#declare Front = union {
  object { Sphere }
  object { Box }
  translate <0,0,-2>
}

// The back union's texture is fixed forever to green here
// (except for the sphere, which is fixed to red):
#declare Back = union {
  object { Sphere }
  object { Box }
  translate <0,0,2>
  texture {}
}

//----------------------------------------------
#default { pigment { colour rgb 1 } }
//----------------------------------------------

// All unfixed textures are fixed to white now:
object { Front }
object { Back }
object { Plane }

//----------------------------------------------
#default { pigment { colour blue 1 } }
//----------------------------------------------

// Changing the default yet again to blue has
// no further effect.

//==============================================

There is also a third difference, which I'll leave as an exercise to the
reader to verify experimentally, and which is of vital importance to the
original problem:

If you specify "texture{}", the default texture applied to the object
will be subject to any subsequent transformations applied to that
object, whereas if you specify no texture at all, a default texture
applied to the object will remain entirely untransformed (and a texture
inherited from a parent CSG object will only be subject to
transformations of that parent).


Thus, defining all textures as empty and using a gradient default will
most likely not achieve the desired results, as many objects will
probably include some transformation or the other.


The only currently viable solution I can imagine is to alway use some
macro to apply textures, and have it evaluate to /nothing at all/ when
rendering a depth-coded version of the scene, like so:

  #if (DepthRender)
    default { /* some gradient-based texture */ }
    #macro Texture(t) #end
  #else
    #macro Texture(t)
      texture { t }
    #end
  #end

Post a reply to this message

On 01/17/2016 09:28 AM, clipka wrote:
> Am 17.01.2016 um 09:39 schrieb Kenneth:
>> Mike Horvath <mik### [at] gmailcom> wrote:
>>>
>>> Is it possible to create an empty texture? In this case, I could swap
>>> out the current textures and instead apply one texture to the entire
>>> scene. Without too much effort on my part if it works.
>>
>> Yes, you can create an empty texture, like this...  texture{}  .... which, as
>> far as I know, is the same as having no texture statement at all-- in which case
>> POV-Ray substitutes it's own default texture (the common black color which we've
>> all seen.)  BUT, if you create your *own* #default{....} texture, then the
>> 'empty texture' statement will use that instead. Which leads to something
>> interesting...
>
> There are some differences between explicitly specifying "texture{}",
> and not specifying any texture at all.
>
> The first difference is in what version of the default you get: If you
> specify "texture{}", you will get whatever the default is set to when
> you /construct/ the object, whereas if you don't specify any texture at
> all, you will get whatever the default is when you actually /insert/ the
> object into the scene.
>
> The second difference is in what happens if the object is used in a CSG
> with an explicit texture: If you specify "texture{}", the object will
> stubbornly cling to the default texture, whereas if you specify no
> texture at all, the object will inherit any texture set on the parent.
>
> Take the following example:
>
> //==============================================
>
> #version 3.7;
>
> camera {
>    location  <3,5,-7>
>    right     x*image_width/image_height
>    look_at   <0,1,0>
> }
>
> light_source{ <1,2,-3>*3000 colour rgb 1 }
>
> //----------------------------------------------
> #default { pigment { colour red 1 } }
> //----------------------------------------------
>
> // The plane and box have no texture at all,
> // and will remain "open to new suggestions":
> #declare Plane  = plane  { <0,1,0>, 0 }
> #declare Box    = box    { <-2,0,-1>, <0,2,1> }
>
> // The sphere's texture is fixed forever to red here:
> #declare Sphere = sphere { <1,1,0>, 1 texture {} }
>
> //----------------------------------------------
> #default { pigment { colour green 1 } }
> //----------------------------------------------
>
> // The front union per se has no texture either,
> // and will remain "open to new suggestions"
> // (except for the sphere, which is fixed to red):
> #declare Front = union {
>    object { Sphere }
>    object { Box }
>    translate <0,0,-2>
> }
>
> // The back union's texture is fixed forever to green here
> // (except for the sphere, which is fixed to red):
> #declare Back = union {
>    object { Sphere }
>    object { Box }
>    translate <0,0,2>
>    texture {}
> }
>
> //----------------------------------------------
> #default { pigment { colour rgb 1 } }
> //----------------------------------------------
>
> // All unfixed textures are fixed to white now:
> object { Front }
> object { Back }
> object { Plane }
>
> //----------------------------------------------
> #default { pigment { colour blue 1 } }
> //----------------------------------------------
>
> // Changing the default yet again to blue has
> // no further effect.
>
> //==============================================
>
> There is also a third difference, which I'll leave as an exercise to the
> reader to verify experimentally, and which is of vital importance to the
> original problem:
>
> If you specify "texture{}", the default texture applied to the object
> will be subject to any subsequent transformations applied to that
> object, whereas if you specify no texture at all, a default texture
> applied to the object will remain entirely untransformed (and a texture
> inherited from a parent CSG object will only be subject to
> transformations of that parent).
>
>
> Thus, defining all textures as empty and using a gradient default will
> most likely not achieve the desired results, as many objects will
> probably include some transformation or the other.
>
>
> The only currently viable solution I can imagine is to alway use some
> macro to apply textures, and have it evaluate to /nothing at all/ when
> rendering a depth-coded version of the scene, like so:
>
>    #if (DepthRender)
>      default { /* some gradient-based texture */ }
>      #macro Texture(t) #end
>    #else
>      #macro Texture(t)
>        texture { t }
>      #end
>    #end
>

Thanks for the texture inheritance tutorial & example code. Got me 
thinking. I believe we can use the interior_texture feature something 
like so using your example scene to get what folks want :

...
// All unfixed textures are fixed to white now:
// object { Front }  // Comment this line and following 2
// object { Back }
// object { Plane }

// Then insert the following lines.
#declare AllObjects = union {
  object { Front }
  object { Back  }
  object { Plane }
  box { <2,2,2> <3.1,3.1,3.1> pigment { rgb <0.7,0.8,0> } } // added
  inverse
}

intersection {
    box { <-10,-10,-10> <10,10,10> }
    object { AllObjects }
    hollow on
    texture { pigment { rgbft <1,1,1,1,0> } }
    interior_texture {
       pigment { gradient z triangle_wave scale <1,1,20>
          color_map {
              [0.0 rgb <1,0,0>]
              [0.5 rgb <1,1,0>]
              [1.0 rgb <0,1,0>]
          }
       }
    }
    finish { ambient 1 diffuse 0 }
}
...

Bill P.

Post a reply to this message

The color map should be more like this:

pigment
{
	gradient (lookFrom - lookAt)
	color_map
	{
		[0/6 srgb <1,0,0,>]
		[1/6 srgb <1,1,0,>]
		[2/6 srgb <0,1,0,>]
		[3/6 srgb <0,1,1,>]
		[4/6 srgb <0,0,1,>]
		[5/6 srgb <1,0,1,>]
		[6/6 srgb <1,0,0,>]
	}
	scale vlength(lookFrom - lookAt) * 2
	translate lookFrom * -1
}

Post a reply to this message

On 1/17/2016 12:21 PM, Mike Horvath wrote:
> The color map should be more like this:
>
> pigment
> {
>      gradient (lookFrom - lookAt)
>      color_map
>      {
>          [0/6 srgb <1,0,0,>]
>          [1/6 srgb <1,1,0,>]
>          [2/6 srgb <0,1,0,>]
>          [3/6 srgb <0,1,1,>]
>          [4/6 srgb <0,0,1,>]
>          [5/6 srgb <1,0,1,>]
>          [6/6 srgb <1,0,0,>]
>      }
>      scale vlength(lookFrom - lookAt) * 2
>      translate lookFrom * -1
> }
>


Forgot to mention that the gradient should maybe not be linear, but 
rather tan() some angle. (Not 100% sure how to write the formula.)


Mike

Post a reply to this message

Am 17.01.2016 um 17:53 schrieb William F Pokorny:

> Thanks for the texture inheritance tutorial & example code. Got me
> thinking. I believe we can use the interior_texture feature something
> like so using your example scene to get what folks want :

The drawback there is, of course, that you can't do this if any of your
objects normally uses an interior_texture.

Post a reply to this message

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

>
> There are some differences between explicitly specifying "texture{}",
> and not specifying any texture at all.

Hmm, I have to admit that my example code (and scheme) were a wee bit too
simplistic(!), in regards to your various scenarios, which I hadn't thought
through in any detail  :-(  I also used really simple colors, and no CSG, so I
didn't notice the 'hidden errors' in the scheme.
>

>
> There is also a third difference, which I'll leave as an exercise to the
> reader to verify experimentally, and which is of vital importance to the
> original problem:
>
> If you specify "texture{}", the default texture applied to the object
> will be subject to any subsequent transformations applied to that
> object, whereas if you specify no texture at all, a default texture
> applied to the object will remain entirely untransformed (and a texture
> inherited from a parent CSG object will only be subject to
> transformations of that parent).
>
> Thus, defining all textures as empty and using a gradient default will
> most likely not achieve the desired results, as many objects will
> probably include some transformation or the other.
>

If I'm understanding you correctly, you're right: for my scheme to work at all,
I had to arrange an object's texture and transformation in a particular order,
which I forgot to mention :-0 ....

I had to write the main scene's objects like this (with more detail than in my
original post):

sphere{0,1
       translate <1,3,5>
       texture{TEX_1]
       }

and NOT like this:

sphere{0,1
       texture{TEX_1}
       translate <1,3,5>
      }

That's a BIG difference (especially concerning the 'real' textures, which
naturally need to be locked to the transformed object.) Yet, the 2nd example
screwed up the 'location' of the 'color blend' texture for that object, so I
couldn't write it that way either.

All in all, not a very well-thought-out scheme, sorry to say...

Post a reply to this message

On 01/17/2016 04:37 PM, clipka wrote:
> Am 17.01.2016 um 17:53 schrieb William F Pokorny:
>
>> Thanks for the texture inheritance tutorial & example code. Got me
>> thinking. I believe we can use the interior_texture feature something
>> like so using your example scene to get what folks want :
>
> The drawback there is, of course, that you can't do this if any of your
> objects normally uses an interior_texture.
>
Good point Christoph. Thanks.
Bill P.

Post a reply to this message

On 1/16/2016 4:54 AM, Kenneth wrote:
> Mike Horvath <mik### [at] gmailcom> wrote:
>> Is there a way to force an override of preconfigured textures and
>> materials of a scene?
>>
>
> I agree, that would be a *really* useful feature in POV-Ray. I've had need of
> something like what you've described; but as Thomas says, the only way at
> present is to (tediously) edit the scene file, then add a #default texture to
> apply to all the objects. Or else pre-plan the entire scene with your final
> results in mind from the very beginning (which, I admit, usually isn't
> practical, when the effect you're looking to create might simply be an
> afterthought or a 'what-if' experiment!)
>
>
>
>
>

Too bad POV does not have a DOM or you could go back and all the 
textures using a script.


Mike

Post a reply to this message

On 18-1-2016 0:00, Kenneth wrote:
> clipka <ano### [at] anonymousorg> wrote:
>
>>
>> There are some differences between explicitly specifying "texture{}",
>> and not specifying any texture at all.
>
> Hmm, I have to admit that my example code (and scheme) were a wee bit too
> simplistic(!), in regards to your various scenarios, which I hadn't thought
> through in any detail  :-(  I also used really simple colors, and no CSG, so I
> didn't notice the 'hidden errors' in the scheme.
>>

And it learns us to always carefully think out and build our 
texture-to-object relationships :-)

-- 
Thomas

Post a reply to this message