Thomas de Groot <tho### [at] degrootorg> wrote:

> I changed every <0.000, 0.000, 0.000> to <0.004, 0.004, 0.004> (which
> corresponds to 1/256)

Thank you, Sir.

I am playing a bit with the macro thing and a simple demo scene, and I will post
both as soon as it's far enough along to warrant some code pong.

Perhaps you can guide me a bit in crafting a prototype texture since you're
likely better/more knowledgeable than I.  After briefly going through your code,
I like what I see so far.
Some small observations:
You have some #declares in your macros where you should probably use #locals.
Maybe use some underscores or GraniteInc_ prefixes to construct a unique
namespace that won't potentially clash with a user's scene file declares.





I'm using the "Mahogany (sp) granite - polished surface" as a starting point,
and I'm noticing a few things:

we have       diffuse 0.6      specular 0.9
Which adds up to over 1.0   Is this proper?   Should the sum never exceed unity?

(it would be nice if we had some dot-notation type stuff to work with, but it
would be a CSG-tree type nightmare)

This is a layered texture, but both texture have finish blocks.  Should there
only be a single finish block for the whole object?
What about sslt and interior {ior} ?


There is also the issue of scale.
"The granite patterns have been scaled in such a way that, when applied to a
unit-sized POV-Ray object, they correspond most closely to the real world
examples from which they have been modeled. (sp)"

and for sslt we have:
"The mm_per_unit algorithm is designed to give realistic results at a scale of
10 mm per POV-Ray unit by default"

So we may have some things to think about there, so that everything is playing
together in harmony, without too much mucking about by inexperienced users.


With more complex textures using ior, sslt, and layered textures, should we have
a full texture_map mechanism, or material_map rather than color_map?


Thanks!   :)

Post a reply to this message