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