Op 11/04/2021 om 18:47 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
>> My initial - and still main - purpose is to provide an /ancient/ code in
>> more /modern/ context.
> 
> Than you, Thomas - I'm sure it's a LOT of tedious editing to get these things
> into shape.  I have not looked over your code or image zips yet - but since
> these are old, historic scene codes, perhaps consider including the
> "deprecate(d)" keyword to show the "new" way of writing "old" code.

It /was/ tedious, and a lot of "goose chasing" in the Cousin Ricky 
meaning of the term :-)

I need to look up (again) the "deprecated" keyword. I think you have a 
point here indeed.

> 
> The discussion so far highlights some interesting things.
> _I_ thought the second image was better - probably because I'm used to seeing
> more polished granite in such shapes, whereas the first might be ok for curbs
> and dry loose rock here in The Granite State.  The second also has more contrast
> and a pleasing color map than the first.  So interesting to see what some people
> find "better".

Absolutely.

> 
> It also suggests that here, at the outset, we should start to compile a list of
> "all those things we've learned in the past 20 years..." and then apply them to
> the same classes of texture to see what improvements we can make.
> 
> srgb
> radiosity
> layering fractal noise
> different noise generator functions
> ways of incorporating and balancing diffuse, specular, metallic, ior,
> subsurface, fresnel, ...  and a lot of other things that I'm missing.
> 

Agreed.

> 
> One thing we might try is - rather than having static definitions of the
> textures where the include file has to be hunted down and edited - what if we
> wrote them as macros that generated the texture?
> 
> You could have a default, a little #debug blurb that summarizes the parameters
> and usage syntax, and maybe an index macro that summarizes all of the available
> texture macros in the include file.  ("Is it granite_03, or Granite03, or....?")
> Perhaps think of naming the macros to indicate how many [optional] parameters
> there are, or have a default texture macro call the "real" texture macro with
> the proper number of parameters.  If any argument is suplied to the default
> macro, it will trigger a verbose help mode for the real texture macro that barfs
> out a bunch of stuff to #default text stream.
> 
> Then we could have boilerplate texture structure that would incorporate all of
> the important points that have been addressed over the years, and the user could
> adapt the texture from within the scene file, leaving the core macro code
> untouched.
> Something akin to quality levels could be integrated into the texture itself,
> shutting off very slow features like subsurface, reflection, etc during scene
> development, but making them instantly available for a final render.
> 

I have to think about this. I believe you are right but I need to let it 
percolate through my thick braincase.

> I also have come across old examples of people writing .map files for color
> maps.  I think this would be incredibly useful in the present context, and
> something I have not seen done in a long time.  The .map could be a macro
> parameter, allowing the user to use the "defaults" in the include directory, or
> employing a color map written in the scene code. (#declare Granite08_map =
> color_map {...})
> 
> In this way, we could choose one texture type - granite, metal, wood, glass, etc
> - and write a prototype macro and texture, then have the experts on implementing
> such textures chime in on what features to include and what values to select,
> perhaps with #warning notes about certain feature and value combinations.  This
> would provide a solid basis for people learning to write their own, more
> involved and complicated textures of the same type.
> 

Yes. More to think about...

> Again - thanks for diving into this, I'm sure it's been needed for a long time.
> 

You are welcome. I believe we are at a stage where something like this - 
POV-Ray wide - is needed. I shall try to improve the granites package 
first of all.

-- 
Thomas

Post a reply to this message