Is there a way to force an override of preconfigured textures and 
materials of a scene? I would like to set the texture of my scene to a 
special texture used to render ChromaDepth 3D images. However, I don't 
want to go back and edit every single object in my scene. Thanks.


Mike

Post a reply to this message

On 16-1-2016 5:54, Mike Horvath wrote:
> Is there a way to force an override of preconfigured textures and
> materials of a scene? I would like to set the texture of my scene to a
> special texture used to render ChromaDepth 3D images. However, I don't
> want to go back and edit every single object in my scene. Thanks.
>

My experience is that you will have to comment the old ones out or 
delete them. Later textures do not override previous ones in a scene file.

-- 
Thomas

Post a reply to this message

On 1/16/2016 8:10 AM, Thomas de Groot wrote:
> On 16-1-2016 5:54, Mike Horvath wrote:
>> Is there a way to force an override of preconfigured textures and
>> materials of a scene? I would like to set the texture of my scene to a
>> special texture used to render ChromaDepth 3D images. However, I don't
>> want to go back and edit every single object in my scene. Thanks.
>>
>
> My experience is that you will have to comment the old ones out or
> delete them. Later textures do not override previous ones in a scene file.
>
Are you sure about that Thomas?

I use Bishop3D which does not support PovRay 3.7. So if I want to use 
PovRay 3.7 textures I will use a 3.6 texture in the Bishop3D scene but 
redifine the tecture before the object is declared.

Sample code generated by Bishop3D.


#version 3.7;

global_settings {
adc_bailout       0.0039
ambient_light     rgb <1.000,1.000,1.000>
assumed_gamma     1 //2.200
irid_wavelength   rgb <0.250,0.180,0.140>
max_trace_level   5
number_of_waves   10
noise_generator   3
charset           ascii
}

background { color rgb <0.000,0.000,0.000> }

// 
****************************************************************************
// referenced scene items and forced visible scene items declaration begin
// 
****************************************************************************

#declare Shadow_Clouds_Mid =
pigment {
bozo
color_map {
[0.000 rgbft <0.850,0.850,0.850,0.000,0.000>]
[0.100 rgbft <0.750,0.750,0.750,0.000,0.000>]
[0.500 rgbft <1.000,1.000,1.000,0.000,1.000>]
}

rotate    <0.0,0.0,90.000>
rotate    <180.000,0.0,0.0>
scale     <1.000,6.000,6.000>
rotate    <-180.000,0.000,-90.000>
turbulence <0.650,0.650,0.650>
octaves 6
lambda 2.000
omega 0.700
}

#declare Shadow_Clouds_Bot =
pigment {
bozo
color_map {
[0.000 rgbft <0.850,0.850,0.850,0.000,0.000>]
[0.100 rgbft <0.750,0.750,0.750,0.000,0.000>]
[0.500 rgbft <1.000,1.000,1.000,0.000,1.000>]
}

rotate    <0.0,0.0,90.000>
rotate    <180.000,0.0,0.0>
scale     <1.000,6.000,6.000>
rotate    <-180.000,0.000,-90.000>
translate <0.000,-0.150,0.000>
turbulence <0.650,0.650,0.650>
octaves 6
lambda 2.000
omega 0.700
}

#declare Shadow_Clouds_Top =
pigment {
color rgbft <0.196,0.600,0.800,0.000,0.000>
}

#declare Red_Texture =
texture {
pigment {
color rgbft <1.000,0.000,0.000,0.000,0.000>
}

}

#declare Blue_White_Tiles2 =
texture {
checker
texture {
pigment {
color rgbft <1.000,1.000,1.000,0.000,0.000>
}

}

texture {
pigment {
color rgbft <0.000,0.502,1.000,0.000,0.000>
}

}

rotate    <0.0,0.0,180.000>
rotate    <-90.000,0.0,0.0>
scale     <-300.000,-300.000,-1000.000>
rotate    <90.000,0.000,-180.000>
rotate    <0.000,-180.000,0.000>
scale     <0.010,0.010,0.010>
}

#declare Camera0 =
camera {
perspective
location <-3.5,46.0,-195.0>
up y
right 1.333*x
angle 33.000
sky <0.0,1.0,0.0>
look_at < 0.000, 7.500, 0.000 >
}


// 
****************************************************************************
// referenced scene items and forced visible scene items declaration end
// 
****************************************************************************

union {
light_source {
< 0.00, 0.00, 0.00 >, color rgb <1.000,1.000,1.000>
fade_power 0.000
fade_distance 100.000
media_attenuation off
media_interaction on
translate <15.0,100.00,-200.0>
}

light_source {
< 0.00, 0.00, 0.00 >, color rgb <1.000,1.000,1.000>
fade_power 0.000
fade_distance 100.000
media_attenuation off
media_interaction on
translate <-25.0,55.0,-200.0>
}

}

sky_sphere {
pigment{ Shadow_Clouds_Top }
pigment{ Shadow_Clouds_Mid }
pigment{ Shadow_Clouds_Bot }

}

plane {
y , 0
texture{ Blue_White_Tiles2 }
scale     <10.00,1.00,10.00>
}


//------- Sphere0 Raw Script Begin -------
#declare Red_Texture =
texture {
   pigment {
     color rgbft <1.000,1.000,0.000,0.000,0.000>
   }

}

//------- Sphere0 Raw Script End ---------

sphere {
0.0, 1.00
texture{ Red_Texture }
scale     <5.954000,5.954000,5.954000>
rotate    <90.00,0.00,0.00>
translate <0.00,5.6490,0.00>
}


camera{ Camera0 }



-- 

Regards
     Stephen

Post a reply to this message

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!)

Post a reply to this message

On 1/16/2016 9: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!)
>
>
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.

-- 

Regards
     Stephen

Post a reply to this message

On 16-1-2016 10:42, Stephen wrote:
> On 1/16/2016 8:10 AM, Thomas de Groot wrote:
>> On 16-1-2016 5:54, Mike Horvath wrote:
>>> Is there a way to force an override of preconfigured textures and
>>> materials of a scene? I would like to set the texture of my scene to a
>>> special texture used to render ChromaDepth 3D images. However, I don't
>>> want to go back and edit every single object in my scene. Thanks.
>>>
>>
>> My experience is that you will have to comment the old ones out or
>> delete them. Later textures do not override previous ones in a scene
>> file.
>>
> Are you sure about that Thomas?

Yes, when you have an object already textured to which you apply a 
second texture:

object{
   MyObject //with predefined texture
   texture {MyTexture}
}
This does not work.

>
> I use Bishop3D which does not support PovRay 3.7. So if I want to use
> PovRay 3.7 textures I will use a 3.6 texture in the Bishop3D scene but
> redifine the tecture before the object is declared.
>

You may get away with that provided you use identical texture names 
declared /before/ the object is opened/used.

As you say in answer to Kenneth, using an alternative texture file can 
do the trick, especially in typical mesh2 file builds.

#include "MyObjectTexture.inc"
#declare MyObject = mesh2{....}

As long as the texture names defined inside the alternative .inc file 
are identical to those defined inside the mesh2 file.

-- 
Thomas

Post a reply to this message

On 1/16/2016 5:15 AM, 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.
>

The problem in my case is that the individual textures are oriented to 
the local coordinates of each object, whereas I need a texture that is 
tied to the global coordinate system. I don't know how to compensate for 
this.


Mike

Post a reply to this message

On 1/16/2016 1:39 PM, Mike Horvath wrote:
> On 1/16/2016 5:15 AM, 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.
>>
>
> The problem in my case is that the individual textures are oriented to
> the local coordinates of each object, whereas I need a texture that is
> tied to the global coordinate system. I don't know how to compensate for
> this.
>
>
> Mike

I misunderstood. I thought you wanted to swap between textures. Thomas 
was right. (As usual.)

I just had a quick look at what Chromadepth is and it looks quite 
interesting. Designing a scene where the depth information is in the 
colour will be, as I said, interesting. With red being in front, and 
blue being back.
I think you might be able to do it with a bit of jiggery pokery in the 
way you write your textures and scene.
I’ll dwell on’t. ;-)


-- 

Regards
     Stephen

Post a reply to this message

Mike, you mean something like discussed in the thread "NEW FEATURE:
Suggesting "aka" (Textures)" of the "p.beta-test" section of our
newsgroups here?

Post a reply to this message

On 1/16/2016 1:09 PM, Sven Littkowski wrote:
> Mike, you mean something like discussed in the thread "NEW FEATURE:
> Suggesting "aka" (Textures)" of the "p.beta-test" section of our
> newsgroups here?
>

I don't know... I wasn't able to understand your suggestion.

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.


Mike

Post a reply to this message

On 16-1-2016 15:20, Stephen wrote:
> On 1/16/2016 1:39 PM, Mike Horvath wrote:
>> On 1/16/2016 5:15 AM, 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.
>>>
>>
>> The problem in my case is that the individual textures are oriented to
>> the local coordinates of each object, whereas I need a texture that is
>> tied to the global coordinate system. I don't know how to compensate for
>> this.
>>
>>
>> Mike
>
> I misunderstood. I thought you wanted to swap between textures. Thomas
> was right. (As usual.)

Not counting all the times I was wrong ;-)

-- 
Thomas

Post a reply to this message

On 1/17/2016 7:55 AM, Thomas de Groot wrote:
> On 16-1-2016 15:20, Stephen wrote:
>> On 1/16/2016 1:39 PM, Mike Horvath wrote:
>>> On 1/16/2016 5:15 AM, 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.
>>>>
>>>
>>> The problem in my case is that the individual textures are oriented to
>>> the local coordinates of each object, whereas I need a texture that is
>>> tied to the global coordinate system. I don't know how to compensate for
>>> this.
>>>
>>>
>>> Mike
>>
>> I misunderstood. I thought you wanted to swap between textures. Thomas
>> was right. (As usual.)
>
> Not counting all the times I was wrong ;-)
>

But you don't post them ;-)

-- 

Regards
     Stephen

Post a reply to this message

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