On 4/12/20 1:43 PM, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
>> I ran into considerable confusion back when I was playing with the
>> peeling paint isosurface stuff and trying to come up with ways to
>> implement the method on the fly. I was trying something similar to what
>> you are trying with the color channels.
> 
> Thanks for confirming what I suspected.
> I'll just have to figure out a way to code the normal of an isosurface function
> into another function.

One thing long on my todo list is to dive into core isosurface code. Not 
sure how it today handles the normals, though I can imagine ways to do it.

> 
>> Aside: I think it probably makes sense for the block patterns to have
>> default color maps. I cannot think of a good reason for continuous
>> patterns to have defaults other than black to white. Is there, or was
>> there one back in the early days of many gammas or something?
> 
> I think the block patterns should have scalar values, such that a black/white
> color map will return shades of gray.  It's simpler, more consistent, and less
> confusing.
> You might consider having "default" or standard color maps for those patterns
> that are pre-defined and easily available.
> 
> pigment {brick color_map{CM_brick_default}}

Yes, think you are right on this. I'd not been burned by the default 
color maps on the block patterns. I happened to see the brick colors at 
ag2.2 while removing maps from continuous patterns.

I have it in my head unless accessing the color channels with .red or 
whatever we do today get the pattern's value back (it acts like a black 
to white map). And with a quick test with f_brick -> function {pattern { 
brick }} looks like this is so. For some quirks I am trying to flatten, 
finding the vm / function / pattern inter-workings quite clean.

Reminds me, our .grey and general color to grey conversion also has 
issues with being - off standard, I guess. A question on my - think more 
deeply about it someday - list, is whether on the fly color to grey 
conversion should get pulled from povr. I have this feeling it isn't 
'really' necessary today.

> 
>> New users should not be pulling colors out of colors
>> inc. Those color definitions today correspond to no common standard that
>> I can see.
> 
> I do because I'm lazy :D  but I do think that there are a lot of legacy code
> snippets and practices that need to be re-examined.
> I've been working on a few ideas to make POV-Ray more usable and flexible, and
> might help code-up and debug scenes much faster.
> 
> Ping / email me if you're interested in the details.
> 
> 
I don't have much for free bandwidth beyond what I'm trying to do 
currently, but, is your email as used in your posts to the news groups 
one I can use?

Might not always be apparent, but I do read most all news group posts - 
though perhaps I don't completely digest them all. The parser dictionary 
changes and rules are still really fuzzy to me, for example.

Your posts, John Greenwood's on the -1 to 1 blobbing, and many others 
over the years, all influencing to some degree whatever hacking I'm 
doing, not doing or might do in povr.

Bill P.

Post a reply to this message