Hi,

Povrays texturing system is quite powerful but when thinking about how I 
would design a texturing system I came up with the following idea:

Since all things should be mapable we dont have a seperation of pigment, 
finish and normal anymore but this:

specular{..}
diffuse{..}
phong{..}
reflection{..}
transparency{..}

and so on...

All these can take a normal{} modifier but we can also specify a general 
normal modifier which applies to all of them.
They can be combined like this:

texture{
	substract{
		diffuse{...}
		specular{...}
	}
	multiply{
		transparency{...}
		ambient{...}
	}
}

Possible combinators could be add, average, substract, multiply, ...
The default combinator for texture could be additive.
I dont know where to put pigment{} yet but possibly all of them could 
have one or you could again specify a general pigment for one combinator.

What do you think of this idea?

Post a reply to this message

Simon Adameit wrote:
> 
> texture{
>     substract{
>         diffuse{...}
>         specular{...}
>     }
>     multiply{
>         transparency{...}
>         ambient{...}
>     }
> }
> 
> [...]

Instead of suggesting syntax formulations you should better explain how 
you think the color of the surface should be calculated - i have no idea 
how this should work from what you have written.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 25 Oct. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

Simon Adameit <gom### [at] gmxnet> wrote:
> What do you think of this idea?

  Can you suggest an implementation which doesn't consume tons of memory
and is as fast to render as the current when those extra features are not
used?
  Each extra feature you add to a texture will increase the amount of
memory taken by that texture, even if the feature is not used (because
the code needs to somehow be prepared to support that feature if it is
used) and extra checks need to be implemented to see if the extra
features are used or not.
  It isn't heavy to have a possible map for a texture, pigment and
normal, but if you are going to add support for a map go each and every
feature inside them...

  I'm not saying it wouldn't be possible to do it without noticeable
speed/memory penalty, I'm just thinking out loud as a coder. Implementation
details always need to be considered when suggesting new features.

  And would there be some advantage over texture maps?

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Christoph Hormann wrote:
> Instead of suggesting syntax formulations you should better explain how 
> you think the color of the surface should be calculated - i have no idea 
> how this should work from what you have written.
> 

The color of the surface is made up from different components like 
diffuse, ambient, specular, ... which all give you a color for this 
point on the surface. The final color is somehow a combination of them. 
For example you could substract the specular component from the diffuse. 
This is something I often did using layered textures and negative colors.
I dont know if this could be efficiently implemented or if it even would 
be practical..

Post a reply to this message

Warp wrote:
> Simon Adameit <gom### [at] gmxnet> wrote:
> 
>>What do you think of this idea?
> 
> 
>   Can you suggest an implementation which doesn't consume tons of memory
> and is as fast to render as the current when those extra features are not
> used?
Unfortunately I do not know the current implementation.

>   Each extra feature you add to a texture will increase the amount of
> memory taken by that texture, even if the feature is not used (because
> the code needs to somehow be prepared to support that feature if it is
> used) and extra checks need to be implemented to see if the extra
> features are used or not.
>   It isn't heavy to have a possible map for a texture, pigment and
> normal, but if you are going to add support for a map go each and every
> feature inside them...

But often this is exactly what one wants.. Having for example the 
reflection and irid vary with a different pattern seems to be impossible 
with the current texturing system. Even giving color and transparence a 
different pattern is diffecult although we have pigment maps.

I can see that beeing able to combine all the different components is 
not needed often and could be done by implementing new patterns like 
average for texture maps ,i.e. add, multiply, ...(if this is possible)

>   I'm not saying it wouldn't be possible to do it without noticeable
> speed/memory penalty, I'm just thinking out loud as a coder. Implementation
> details always need to be considered when suggesting new features.

I hope I have not created the impression of suggesting to implement this 
in some future megapov. It was just an idea I wanted feedback about.

>   And would there be some advantage over texture maps?
> 
I am not sure about this anymore ;)

Post a reply to this message

Simon Adameit wrote:
> 
> The color of the surface is made up from different components like 
> diffuse, ambient, specular, ... which all give you a color for this 
> point on the surface. The final color is somehow a combination of them. 
> For example you could substract the specular component from the diffuse. 
> This is something I often did using layered textures and negative colors.
> I dont know if this could be efficiently implemented or if it even would 
> be practical..

I don't think anything but additive combination of finish components 
would be of practical use  (note subtracting is already possible using 
negative values).

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 25 Oct. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

>   Can you suggest an implementation which doesn't consume
> tons of memory and is as fast to render as the current when
> those extra features are not used?

Without having much experience with C or C++ not to mention the POV-Ray
source, I have an idea:

When the scene parses, optimised code for each texture can be generated in
memory. By optimised I mean, a block of memory is set aside for each unique
material and the code necessary to produce that material is generated. This
leaves out checking if features are on/off during rendering. It does consume
a bit of extra memory, but hardly tons of it. The same memory block could
even be used for several textures with different values to them, as long as
they use only the same set of features.

By the way, I wonder how much computation time is needed for a material to
have a 'switch / case' statement. Each 'case' being a feature on/off. It
doesn't sound like a big penalty?

Regards,
Hugo

Post a reply to this message