Okay, here's a very noddy question:

I have an object with complex textures attached to it. I wish to render
the object with different, much simpler textures (a simple pigment, in
fact). However, if I try to create an instance of the object with my new
texture, I just get the error:

    Parse Error: Cannot layer over a patterned texture.

For various reasons I can't change the original object.

Is there any way to get Povray to create a new instance of an object,
discarding all the texture information and letting me replace it with
new textures?

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────
http://www.cowlark.com ─────
│
│ "I have a mind like a steel trap. It's rusty and full of dead mice."
│ --- Anonymous, on rasfc

Post a reply to this message

David Given wrote:

> For various reasons I can't change the original object.

I think you have to - even if it is generated you can
automate the process using a scripting language.

Unless all you want to do is to get quick test renders,
in which case you can use the +q command line option to
reduce render quality (textures will be ignored at low
levels).

Post a reply to this message

David Given <dg### [at] cowlarkcom> wrote:
> Okay, here's a very noddy question:
>
> I have an object with complex textures attached to it. I wish to render
> the object with different, much simpler textures (a simple pigment, in
> fact). However, if I try to create an instance of the object with my new
> texture, I just get the error:
>
>     Parse Error: Cannot layer over a patterned texture.
>
> For various reasons I can't change the original object.
>
> Is there any way to get Povray to create a new instance of an object,
> discarding all the texture information and letting me replace it with
> new textures?
>
> --
> ┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────
http://www.cowlark.com ─────
> │
> │ "I have a mind like a steel trap. It's rusty and full of dead mice."
> │ --- Anonymous, on rasfc

Perhaps you could use #if...#else...#end, something like this:

#declare use_simple_texture=1;

object{
  my_object
  #if (use_simple_texture=1)
    texture{simple_texture}
  #else
    texture{complex_texture}
  #end
}

Post a reply to this message

On 12/07/11 01:07, Christian Froeschlin wrote:
[...]
> I think you have to - even if it is generated you can
> automate the process using a scripting language.

Well, I have managed to rearrange my source to allow this, but it was
quite a faff to do so, and my source is now considerably messier than it
was before (because I've had to split my object definition in two parts
just so that I can insert one of two texture definitions between the two).

This strikes me as being a really odd restriction; is there a good
reason for it?

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─────
http://www.cowlark.com ─────
│
│ "I have a mind like a steel trap. It's rusty and full of dead mice."
│ --- Anonymous, on rasfc

Post a reply to this message

Le 13/07/2011 01:17, David Given nous fit lire :
> On 12/07/11 01:07, Christian Froeschlin wrote:
> [...]
>> I think you have to - even if it is generated you can
>> automate the process using a scripting language.
> 
> Well, I have managed to rearrange my source to allow this, but it was
> quite a faff to do so, and my source is now considerably messier than it
> was before (because I've had to split my object definition in two parts
> just so that I can insert one of two texture definitions between the two).
> 
> This strikes me as being a really odd restriction; is there a good
> reason for it?
> 
The way the code is handling it...old heritage of old conception.

Initially it was not even possible to clone an object, you had too
duplicate its full declaration and updates the end of it to move it
somewhere else.

There might be a need for a reset_texture / reset_material /
reset_finish / reset_normal / reset_pigment / reset_interior...

maybe not all of them actually make sense. And maybe the need is deeper:
removing layer k of a layered texture/pigment, or replacing it...
 (push/pop/swap operation with indexed layers... yummy!)

Post a reply to this message