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