Some initial thoughts and actions involving the below.

Op 14-4-2021 om 08:40 schreef Thomas de Groot:
> Op 13/04/2021 om 21:00 schreef Bald Eagle:
>> 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.

Also changed the remaining 0.000 values (only a few left) to 0.004.

>>
>> 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.
>>
> 
> Good! I think the macro suggestion is the way to go. Might become quite 
> complex...
> 
>> Perhaps you can guide me a bit in crafting a prototype texture since 
>> you're

>> 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 shall look into that.
> 
So I wrapped the environment code to be used in each pov-file into a 
macro, where the parameters start with a g21_ prefix (thanks jr!).

The next step I intend to do is try to formulate a single pov file from 
where each and all the granites can be rendered, name and all.

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


>> exceed unity?
>>
> I did not go too deep into the original code, but you are right I think; 
> I need to look up my notes on this. There is also a comment in one of 
> the Clipka Voodoo's which talks about diffuse values in a srgb 
> environment...
>
In my notes I found the 'rule' for realistic finish should be:
   "diffuse albedo" + "reflection {Value fresnel} < 1
and:
   "specular albedo" + "phong albedo" < Value in the finish block;
   with the mention that a good use would be specular + phong = Value/2

I have still to browse the Clipka grimoire though...

>> (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?
> 
> Something I wondered about too. My gut feeling is that only one finish 
> should be used.
> 
I tested this and indeed a single finish in the top texture seems to be 
enough.

>> What about sslt and interior {ior} ?
> 
> I don't think that those are to be used with granites. It would not add 
> anything imo.
> 
Well... I retract my words. At least, this should be tested more fully.

Fwiw, https://pixelandpoly.com/ior.html is a list of ior's that could be 
useful.

> 
>> 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.
>>
> 
> Indeed. Note however that the scale of the texture is rather arbitrary 
> and open to change by the user. I felt I had to provide something at 
> least visually "correct".
> 
>>
>> 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?
>>
> Maybe, and depending on "complexity". Personally, I would prefer the 
> texture_map/material_map structure indeed.
> 
>>

>>
> 
> <grin>
> 

back to the drawing board...

-- 
Thomas

Post a reply to this message