This version of the granite macro has a couple of minor changes, mainly 
name changes, and a couple of major changes suggested by Bald Eagle: 
colour_map entries are now based on 2D arrays, and the srgb conversion 
macro has been streamlined. Many thanks to the kind hinter :-)

-- 
Thomas

Post a reply to this message

Attachments:
Download 'dakotaredgranite_beta_1.2.mcr.txt' (22 KB)

Grrr... correction of a typo done here.

-- 
Thomas

Post a reply to this message

Attachments:
Download 'dakotaredgranite_beta_1.2.mcr.txt' (22 KB)

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

The render still looks good.  :)
Section (5) can be condensed using a similar array method.

In section 8 you have some scene code, but don't define the required parameters
(or SS) and you have those commented out at the top of the file.

IIRC, you can declare all the macro parameters to be optional, and then inside
the macro do what you're doing with some other parameters:

#ifndef (SN_Start) #local SN_Start = 0.2; #end

But maybe to alert the user to the fact that they may have inadvertently left
out a parameter or used a misspelling/typo, issue a warning in the #ifndef
block.

(I've been trying to figure out a way make a lot of the things that I write work
"straight out of the box" without having to do much figuring at all.)

Perhaps even have a line that declares a texture identifier with the default
parameters, so that all anyone would need to do to use it is include the file
and then "TdGGranite" is right there for use.
#debug "Default material {TdGGranite} defined."

Just some ideas.



I'm interested to hear a "behind-the-scenes" account of what you've discovered
and learned from assembling this mammoth texture definition.
Also, are there any specific ways that you envision modifying the texture for
other purposes?  I'm thinking about all of the other materials that may come
after this, and possible ways to make the customization of them a little easier.

So, just imagining - perhaps a small scene with 3 boxes.  on the left, the
default granite, or whatever material is being "edited".  In the center, is a
box where any given color map entry can be highlighted, so the user knows what
part of the material they want to change, and where it visually occurs in the
render.  On the left is a box with a macro call utilizing the new parameters to
show the edited/updated material {} definition.
Perhaps put a nice ruler in decimal subdivided centimeters along the top, and
fractionally subdivided American Imperial inches along the bottom to give an
indication of scale.

Maybe sets of boxes in different light groups to get a better idea about the
effect of lighting on these complex materials.

I would also love to experiment with ideas about how to further develop the
quartz vein feature and help visualize where it lives in 3D space.  So, a
"bounding box" that has a pigment pattern with rgbt1 and a high transmittance
white?  Media?



> Thomas

Post a reply to this message

Op 23-5-2021 om 16:25 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
> 
> The render still looks good.  :)
> Section (5) can be condensed using a similar array method.
>
Right. I was sure I would get this comment! ;-)
I was lazy of course and pushed it forwards.

> In section 8 you have some scene code, but don't define the required parameters
> (or SS) and you have those commented out at the top of the file.
> 
Yes, needs to be expanded/made more explicit.

> IIRC, you can declare all the macro parameters to be optional, and then inside
> the macro do what you're doing with some other parameters:
> 
> #ifndef (SN_Start) #local SN_Start = 0.2; #end
> 
> But maybe to alert the user to the fact that they may have inadvertently left
> out a parameter or used a misspelling/typo, issue a warning in the #ifndef
> block.
> 
Hmm... yes, that might be smart. I need to think about this a bit.

> (I've been trying to figure out a way make a lot of the things that I write work
> "straight out of the box" without having to do much figuring at all.)
> 
Which of course, is the way to go.

> Perhaps even have a line that declares a texture identifier with the default
> parameters, so that all anyone would need to do to use it is include the file
> and then "TdGGranite" is right there for use.
> #debug "Default material {TdGGranite} defined."
> 
Absolutely. I had been thinking about this and then it got submerged by 
development issues.

> Just some ideas.
>
Much appreciated, to be sure.

The following, I want to comment on separately. Needs more thoughts.

In the meantime, I am also working on a working sslt set... Not so easy! 
For instance, a layered texture (veins!) makes sslt go bad.

> 
> I'm interested to hear a "behind-the-scenes" account of what you've discovered
> and learned from assembling this mammoth texture definition.
> Also, are there any specific ways that you envision modifying the texture for
> other purposes?  I'm thinking about all of the other materials that may come
> after this, and possible ways to make the customization of them a little easier.
> 
> So, just imagining - perhaps a small scene with 3 boxes.  on the left, the
> default granite, or whatever material is being "edited".  In the center, is a
> box where any given color map entry can be highlighted, so the user knows what
> part of the material they want to change, and where it visually occurs in the
> render.  On the left is a box with a macro call utilizing the new parameters to
> show the edited/updated material {} definition.
> Perhaps put a nice ruler in decimal subdivided centimeters along the top, and
> fractionally subdivided American Imperial inches along the bottom to give an
> indication of scale.
> 
> Maybe sets of boxes in different light groups to get a better idea about the
> effect of lighting on these complex materials.
> 
> I would also love to experiment with ideas about how to further develop the
> quartz vein feature and help visualize where it lives in 3D space.  So, a
> "bounding box" that has a pigment pattern with rgbt1 and a high transmittance
> white?  Media?
> 

-- 
Thomas

Post a reply to this message

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

> Right. I was sure I would get this comment! ;-)
> I was lazy of course and pushed it forwards.

Sometimes it's best to just push it back out into the wild.

> > But maybe to alert the user to the fact that they may have inadvertently left
> > out a parameter or used a misspelling/typo, issue a warning in the #ifndef
> > block.
> >
> Hmm... yes, that might be smart. I need to think about this a bit.


>
> The following, I want to comment on separately. Needs more thoughts.
>
> In the meantime, I am also working on a working sslt set... Not so easy!
> For instance, a layered texture (veins!) makes sslt go bad.

I went looking for sslt scene code, and that rotating pyramid again...
and got sidetracked.

Here's some granite with HDR lighting and radiosity.
I noticed that I probably didn't scale the texture properly, and so I can't
really see any of the veins.  In my readings, clipka mentioned that having the
mm_per_unit setting was there to decouple the texture from POV-units and so be
independent of scaling effects.  We might want to do similar with a
default-if-not-supplied, and a debug/warning message saying what it got set to.

I think that sometimes it is a bit slow to render - depending on how the scene
is set up.   Maybe have some quick-color definitions set up.  For ridiculously
high quality, I'm guessing we'd want some switchable reflection built in as well
for the same not0 reasons.

Post a reply to this message

Attachments:
Download 'dakotaredradiosity.png' (3990 KB)

Preview of image 'dakotaredradiosity.png'

Op 24-5-2021 om 12:22 schreef Bald Eagle:
> Thomas de Groot <tho### [at] degrootorg> wrote:
>> In the meantime, I am also working on a working sslt set... Not so easy!
>> For instance, a layered texture (veins!) makes sslt go bad.
> 
> I went looking for sslt scene code, and that rotating pyramid again...
> and got sidetracked.
> 
> Here's some granite with HDR lighting and radiosity.
Looking good and interesting.

> I noticed that I probably didn't scale the texture properly, and so I can't
> really see any of the veins.  In my readings, clipka mentioned that having the
> mm_per_unit setting was there to decouple the texture from POV-units and so be
> independent of scaling effects.  We might want to do similar with a
> default-if-not-supplied, and a debug/warning message saying what it got set to.
> 
Something I noticed with sslt in my settings, is that veins seem to 
become really 'thin' or, more probably, 'transparent', and thus tend to 
/disappear/ from the view except with higher magnification.

There are still a lot of issues with the technique (the layered textures 
I mentioned for instance) which are not (fully) addressed in the 
documentation as-is. Not for nothing that the technique is still 
experimental. However, we may get at something workable if not 
breath-taking ;-) on the way.

The mm_per_unit setting is essential and its default (10) seems at first 
glance to be ok for the granite. I am trying to get a grip on how to 
tweak the translucency parameter. For instance, I experimented with the 
use of a complementary colour instead of a regular colour taken from the 
granite colour_map, with interesting results. Visual examples later on.

> I think that sometimes it is a bit slow to render - depending on how the scene
> is set up.   Maybe have some quick-color definitions set up.  For ridiculously
> high quality, I'm guessing we'd want some switchable reflection built in as well
> for the same not0 reasons.
> 
Yes, and yes, and yes.

-- 
Thomas

Post a reply to this message

For your consideration, concerning sslt:

(1) It looks like that when using the layered texture mode, i.e. with 
veins through the granite, sslt should *only* be switched on in the 
/lower/ layer and *not* in the top layer. Just comment it out there.

(2) Scaling of the granite material is related to the /original/ size of 
the object. In my system, I scale the bunny 10x /before/ applying the 
granite material. Consequently, I use the optional M_scale = 0.10; or 
close to that value in the macro.

-- 
Thomas

Post a reply to this message

Op 24-5-2021 om 15:01 schreef Thomas de Groot:
> For your consideration, concerning sslt:
> 
> (1) It looks like that when using the layered texture mode, i.e. with 
> veins through the granite, sslt should *only* be switched on in the 
> /lower/ layer and *not* in the top layer. Just comment it out there.
> 
See attached image. Translucency has been a bit exagerated:
  <0.669, 0.229, 0.198>*5;

> (2) Scaling of the granite material is related to the /original/ size of 
> the object. In my system, I scale the bunny 10x /before/ applying the 
> granite material. Consequently, I use the optional M_scale = 0.10; or 
> close to that value in the macro.
> 
In fact this has nothing to do with sslt;-)

-- 
Thomas

Post a reply to this message

Attachments:
Download 'dakotared_sslt_test1.jpg' (59 KB)

Preview of image 'dakotared_sslt_test1.jpg'

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

> Something I noticed with sslt in my settings, is that veins seem to
> become really 'thin' or, more probably, 'transparent', and thus tend to
> /disappear/ from the view except with higher magnification.

Yes, I think some of that happened in the early experiments with people applying
sslt to objects.  Some details nearly disappeared.

There should definitely be a parameter passed to the macro for width of the
vein, and frequency of occurrence.

Now that it's looking good, I'd say it's time to think about how to pass
alternative color maps into the texture - both to model other granite types, as
well as use the change to spot something in the current implementation that
might be hiding, but a different color scheme might bring out.

Piggybacking on that idea, there should be some triggerable material attribute
data output to #debug with numbered map entries, and then we could have a
mechanism to pass in a color for a single entry on-the-fly.  Then it would be
easy to plug the macro calls into a loop and render a ton of different samples
when tweaking a new material.

The macro should also top up my coffee or G&T while I'm working on a scene,
depending on the value of a required parameter.  :D


> I am trying to get a grip on how to
> tweak the translucency parameter.

The way clipka explained it that the translucency color is geared toward what
color you want the sslt effect to take on as it percolates through the material.
 So for skin, where the blood will add a red color and absorb the blue and
green, you set the color to a red-channel dominant rgb vector.

Maybe the best sslt test-bed would be a back-lit wedge of material, much like
what Ansel Adams would do with the Zone System when calibrating negatives and
prints.

Clipka also recommended in one thread to overlay the sslt texture layer with
something else and maybe(?) he specifically said to only set the sslt in the
lower layer...  I'd have to search and pull it up.

Have to head out and do some errands, so won't be back until later in case you
can't find it with a quick "sslt" search.

- Bill

Post a reply to this message

Thomas de Groot <tho### [at] degrootorg> wrote:
> I am trying to get a grip on how to
> tweak the translucency parameter. For instance, I experimented with the
> use of a complementary colour instead of a regular colour taken from the
> granite colour_map, with interesting results.

http://news.povray.org/povray.binaries.images/message/%3C4f5748d5%40news.povray.org%3E/#%3C4f5748d5%40news.povray.org%3
E

Post a reply to this message