POV-Ray : Newsgroups : povray.binaries.images : Patterns / functions. Obscure details. Noise etc. : Re: Patterns / functions. Obscure details. Noise etc. Server Time
25 Apr 2024 08:25:45 EDT (-0400)
  Re: Patterns / functions. Obscure details. Noise etc.  
From: William F Pokorny
Date: 9 Apr 2020 03:55:53
Message: <5e8ed509$1@news.povray.org>
On 4/8/20 2:23 PM, Bald Eagle wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> 
...
> 
>> To this end I've been thinking about additional pattern related
>> documentation; The form it might take. See attached
>> dentsPatternDistDoc.png image for an idea on how this could be done. The
>> distribution show in green is the linear value distribution for the
>> dents pattern.
> 
> I'm still interested in this, especially from a design and implementation
> stance.
> 
> While creating new documentation is a good idea, it's extremely arduous to craft
> language of sufficient breadth and specificity to communicate something as
> complex as a 3D pattern function, especially with all the modifiers.
> 
> We all know that a render if worth 1000 lines of docs, so maybe the step
> preceding any writing would be to illustrate the intent of the documentation
> with scene files/renders/animations that show ranges, variations, and best
> practices.
> 
> Will there be a simple way to install and update
> povr at some point so that folks can play along at home?
> 

Yes, I'll publish a release at some point - assuming the virus, or 
something else, doesn't take this old guy out beforehand...

I'm an example, or ten, is better guy too. I was leaning toward 
additional documentation here because to get the histograms shown I was 
using an external utility and another to glue the images together.

A thought experiment I've been playing with for a while is decoupling 
textures and interiors from our shape-shapes. Breaking - except where we 
have triangles / patches - from the model which ties everything together 
on the 'shape' surfaces.

The idea would be to maintain completely different internal structures 
for the material aspects of a scene - excepting perhaps a surface ior in 
addition today's interior one. Related too to today's inefficiency with 
interior tests, using complex object patterns to texture and even I 
think to multiple camera views - been thinking about internal self 
contained scenes with shapes as interior, texturing / inside test 
mechanisms.

It's part of the general idea of exploiting the fact we are in a 
ray-tracer and have bounding and search structures set up for tracing 
rays. As a scene renders there would be the visible scene and then - 
potentially - many additional scenes internally getting rendered ray by 
ray for information which helps render the top scene. I think of the 
concept at a high level as ray tracer folding.

Today, it's not uncommon to create a scene used only to create a texture 
map image. I did this with that isosurface pumpkin years ago. It was 
really two scenes - one for the texture map and the second the final 
scene. Why not enable a mechanism the lets us do all of this and much 
more in one go.

We introduced an object uv_mapping mechanism, but it's buggy and very 
unlikely to ever work through CSG in any clean-ish way (interpolation at 
edge boundaries is the key hang up I see). It's also in my opinion today 
not very useful - excepting, maybe, with parametric surfaces (bicubic 
patch?) - mostly because we don't have with it good ways to create the 
uv mapped textures. With povr, the feature is squarely on my try to lose 
it list.

In the simplest folded scene as texture method the shapes natural 
surface normal would create a ray traced into the texture-scene which 
would return a pigment etc. I see it as potentially a much more powerful 
object pattern method - which better exploits what a ray tracer can do.

So, back to the scenes as documentation idea. With such a mechanism it 
would be easier to create such feature-self documentation scenes as one 
render.

Aside: Had the thought last night it might be possible to create an 
inbuilt f_histogram function which would calculate the histogram pixels
on the fly. Though, it's simplest implementation wouldn't be very 
efficient. As a debug/doc thing maybe it would be OK...

Anyway, wild dreams. Today. Off to kill the spotted pattern, f_spotted, 
f_bumps, f_bozo and change bozo's inbuilt default color_map to black and 
white. Simpler things first.

Bill P.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.