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.

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".

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.


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 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.

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

Post a reply to this message