POV-Ray : Newsgroups : povray.unofficial.patches : Facets feature request Server Time
8 Jul 2024 16:24:19 EDT (-0400)
  Facets feature request (Message 1 to 9 of 9)  
From: Rune
Subject: Facets feature request
Date: 7 Aug 2001 06:45:11
Message: <3b6fc6b7@news.povray.org>
I've been looking at the facets pattern for normals and have thought a
little about it.

It has the following problems:

* The version for rounded surfaces work for rounded surfaces only, and give
very little control.

* The version for flat surfaces work both for flat and rounded surfaces, but
the illusion of depth is very bad, I think it looks more like a pigment than
a normal, i.e. as if it is painted on the surface.

* The two different version of facets really have not very much to do with
each other. It's almost as if it is two different workarounds.

* The pattern is not really a pattern as it works for normals only, and with
the rounded version you can't even scale it. (I know, this applies partly to
the slope pattern too, but anyway.)

I have this idea which would in my opinion make facets much more useful:

Facets shouldn't be a pattern but a normal modifier. Only the version for
rounded surfaces should be used. This would make it more logical that it
only works for normals (because it's a normal modifier.) It would also
explain why you can't scale it like most other patterns. However, the real
advantage is this:

You could use it in combination with any real normal pattern, for example
bumps. The facets modifier should take into account the normal pertubation.
This would mean that it would work for flat surfaces too, because they are
not flat but bumpy if you give them a bumpy normal. It would also give you
way better control over the facets, as you could use it together with any
normal pattern.

The syntax would also be easier. Just add "facets Float" to the normal
statement, where the Float would determine the number of facets, like the
factor value do in the current implementation.

So, what do you think? Isn't my idea both much more logical and useful than
the current implementation? :)

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk


Post a reply to this message

From: Ron Parker
Subject: Re: Facets feature request
Date: 7 Aug 2001 09:39:02
Message: <slrn9mvrro.3vi.ron.parker@fwi.com>
On Tue, 7 Aug 2001 12:10:58 +0200, Rune wrote:
>* The version for rounded surfaces work for rounded surfaces only, and give
>very little control.

True. The amount of faceting is directly related to the curvature of the 
surface, which leads to both limitations.

>* The version for flat surfaces work both for flat and rounded surfaces, but
>the illusion of depth is very bad, I think it looks more like a pigment than
>a normal, i.e. as if it is painted on the surface.

The version for flat surfaces could be replaced by some rethinking of the way
crackle solid works with normals; it's basically the same code.

>* The two different version of facets really have not very much to do with
>each other. It's almost as if it is two different workarounds.

Not "workarounds" exactly, but two different methods definitely.

>* The pattern is not really a pattern as it works for normals only, and with
>the rounded version you can't even scale it. (I know, this applies partly to
>the slope pattern too, but anyway.)

Actually, it scales with the object it's on, since it's based on curvature.
A big sphere will have exactly the same number of facets as a small one.

>So, what do you think? Isn't my idea both much more logical and useful than
>the current implementation? :)

I like it.  The combination of bumps and facets could be interesting;
it won't look like the current facets, but it will be unique.

-- 
plane{-z,-3normal{crackle scale.2#local a=5;#while(a)warp{repeat x flip x}rotate
z*60#local a=a-1;#end translate-9*x}pigment{rgb 1}}light_source{-9red 1rotate 60
*z}light_source{-9rgb y rotate-z*60}light_source{9-z*18rgb z}text{ttf"arial.ttf"
"RP".01,0translate-<.6,.4,.02>pigment{bozo}}light_source{-z*3rgb-.2}//Ron Parker


Post a reply to this message

From: Christoph Hormann
Subject: Re: Facets feature request
Date: 7 Aug 2001 13:29:01
Message: <3B70252F.5BCAF60E@gmx.de>
Rune schrieb:
> 
> [...]
> 
> 
> So, what do you think? Isn't my idea both much more logical and useful than
> the current implementation? :)
> 

It sounds interesting, if it's possible to implement it this way.
Another thought: why is it not possible to be used as a pigment, it
would probably look similar to crackle/crackle solid, but i don't really
see a reason for that restriction.

Christoph, 
being on vacation and therefore not very active...


Post a reply to this message

From: Ron Parker
Subject: Re: Facets feature request
Date: 7 Aug 2001 14:11:08
Message: <slrn9n0bpt.44k.ron.parker@fwi.com>
On Tue, 07 Aug 2001 19:28:15 +0200, Christoph Hormann wrote:
>Another thought: why is it not possible to be used as a pigment, it
>would probably look similar to crackle/crackle solid, but i don't really
>see a reason for that restriction.

The first (curved-surfaces-only) version doesn't work on pigments because the
way it works is by (essentially) quantizing the normal vector.  It's not really
a pattern at all; it's more of an operation.  The second version doesn't work
on pigments because it is identical to crackle solid except that it works with
vectors rather than pattern values.  In addition, the design of POV makes it 
impossible to make one set of parameters work with pigments and another not.

I have considered the possibility that the second method in facets should be 
dropped, but it does fill a niche that can't be filled with other existing 
patterns.  However, as an operator rather than a pattern, I wonder if the 
syntax should be changed somehow.

--
#macro R(L P)sphere{L __}cylinder{L P __}#end#macro P(_1)union{R(z+_ z)R(-z _-z)
R(_-z*3_+z)torus{1__ clipped_by{plane{_ 0}}}translate z+_1}#end#macro S(_)9-(_1-
_)*(_1-_)#end#macro Z(_1 _ __)union{P(_)P(-_)R(y-z-1_)translate.1*_1-y*8pigment{
rgb<S(7)S(5)S(3)>}}#if(_1)Z(_1-__,_,__)#end#end Z(10x*-2,.2)camera{rotate x*90}


Post a reply to this message

From: Rune
Subject: Re: Facets feature request
Date: 7 Aug 2001 18:54:41
Message: <3b7071b1@news.povray.org>
"Ron Parker" wrote:
> > * The two different version of facets really have not very
> > much to do with each other. It's almost as if it is two
> > different workarounds.
>
> Not "workarounds" exactly, but two different methods definitely.

And none of them very powerful IMHO. As if it were two different attempts to
obtain the same goal.

> Actually, it scales with the object it's on, since it's
> based on curvature.

I know, but real patterns only scale when you tell them to.

> A big sphere will have exactly the same number of facets
> as a small one.

I'm quite aware of how it works...! ;)

> I like it.  The combination of bumps and facets could
> be interesting; it won't look like the current facets,
> but it will be unique.

You could use it together with any zero-height normal (like bumps 0.0) to
get the current behavior. But you could do so much more... I think it would
also be interesting together with wrinkles... Or wood... Or even just a
heavily turbulated gradient x (it should be implemented so that it is always
applied *after* the turbulence; it should be the last thing applied at all).

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk


Post a reply to this message

From: Warp
Subject: Re: Facets feature request
Date: 7 Aug 2001 19:35:10
Message: <3b707b2e@news.povray.org>
Rune <run### [at] mobilixnetdk> wrote:
: I know, but real patterns only scale when you tell them to.

  So the slope pattern isn't a real pattern?

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -


Post a reply to this message

From: Thorsten Froehlich
Subject: Re: Facets feature request
Date: 8 Aug 2001 04:08:52
Message: <3b70f394@news.povray.org>
In article <3b707b2e@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   So the slope pattern isn't a real pattern?

In the sense that patterns in POV 'have volume' but the slope is a surface
property?

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org


Post a reply to this message

From: Rune
Subject: Re: Facets feature request
Date: 8 Aug 2001 07:51:57
Message: <3b7127dd$1@news.povray.org>
"Warp" wrote:
> Rune wrote:
> : I know, but real patterns only scale when you tell them to.
>
>   So the slope pattern isn't a real pattern?

It's not what I would call a real pattern in the traditional sense (though
it's partly a real pattern if you use altitude). Real patterns can be made
using functions that return a given value for a given point.

Anyway, what do you think of my suggestion?

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk


Post a reply to this message

From: Christoph Hormann
Subject: Re: Facets feature request
Date: 14 Aug 2001 18:05:02
Message: <3B79A10C.A5901DF6@gmx.de>
Ron Parker wrote:
> 
> The first (curved-surfaces-only) version doesn't work on pigments because the
> way it works is by (essentially) quantizing the normal vector.  It's not really
> a pattern at all; it's more of an operation.

This way it has some similarity to 'slope'. Maybe it could be interesting
to make it work just like that in pigments, being only defined on the
object's surface.

>  The second version doesn't work
> on pigments because it is identical to crackle solid except that it works with
> vectors rather than pattern values.  In addition, the design of POV makes it
> impossible to make one set of parameters work with pigments and another not.
> 

Then making crackle solid a 'special' pattern when used in normals would
be the best solution for that IMO.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/


Post a reply to this message

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