I am wondering what people really think about how normals and scaling should
work.  If you're interested in this topic, please see this page and take the
'surface normal survey'.  You can reply by emailing me or reply to this
post.

http://nathan.kopp.com/normals.htm

-Nathan

Post a reply to this message

Nathan Kopp wrote:
> 
> I am wondering what people really think about how normals and scaling should
> work.  If you're interested in this topic, please see this page and take the
> 'surface normal survey'.  You can reply by emailing me or reply to this
> post.
> 
> http://nathan.kopp.com/normals.htm
> 
> -Nathan

Question 1: answer A

Question 2: answer B

Question 3: answer A

Question 4: good question... it doesn't matter to me provided it's
clearly documented

Question 5: answer B

Question 6: same as question 4

	To summarize, I think that when you scale the object to which the
normal is applied, you should scale the whole normal (size of pattern
and bump depth), when you only scale the normal, it doesn't matter
provided it's clearly documented.

		Jerome
-- 
*******************************
* Always listen to experts,   * Jérôme M. BERGER
* they'll tell you what can't * mailto:ber### [at] inamecom
* be done and why...          * http://www.enst.fr/~jberger
* Then do it.                 *
*******************************

Post a reply to this message

Nathan Kopp wrote:
> 
> I am wondering what people really think about how normals and scaling should
> work.  If you're interested in this topic, please see this page and take the
> 'surface normal survey'.  You can reply by emailing me or reply to this
> post.
> 
> http://nathan.kopp.com/normals.htm
> 
> -Nathan

1.) A
2.) B
3.) B
4.) B
5.) B
6.) B


Rational for some of the answers -

If you glue sand to the surface of a box, like the one used in your examples,
as you scale the x & z directions the sand will be further apart but the
relative height of the roughness on the surface will remain unchanged. Since
we are talking surfaces here, if you glued sand to a thicker box, all you
would have is sand with the same granular size on a larger box. It's surface
roughness would remain unchanged. Therefore it is important to remember that
scaling an object should not change the surface normals depth. It may change
the slope and scale of the pattern but not it's physical depth.


-- 
Wishing you Seasons Greetings, A Merry Christmas, and A Happy New Year !
Ken Tyler -  1200+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

No answers here, but an idea: can't you just add some more keywords so the user
can have all the possibilites? Especially the one where the normal depth is
flattened depending how you scale the object.

Nathan Kopp wrote:

> I am wondering what people really think about how normals and scaling should
> work.  If you're interested in this topic, please see this page and take the
> 'surface normal survey'.  You can reply by emailing me or reply to this
> post.
>
> http://nathan.kopp.com/normals.htm
>
> -Nathan

--
Samuel Benge

E-Mail: STB### [at] aolcom

Visit the still unfinished isosurface tutorial: http://members.aol.com/stbenge

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote ...
>
> 1.) A
> 2.) B
> 3.) B
> 4.) B
> 5.) B
> 6.) B
>

I understand your rationale but I wonder why you chose A for 1 and B for 2
and 3.  To be consistent, I would think that if 2 and 3 were B, then 1
should be B also.

-Nathan

Post a reply to this message

Ken wrote:
> 
> If you glue sand to the surface of a box, like the one used in your examples,
> as you scale the x & z directions the sand will be further apart but the
> relative height of the roughness on the surface will remain unchanged. Since
> we are talking surfaces here, if you glued sand to a thicker box, all you
> would have is sand with the same granular size on a larger box. It's surface
> roughness would remain unchanged. Therefore it is important to remember that
> scaling an object should not change the surface normals depth. It may change
> the slope and scale of the pattern but not it's physical depth.
> 
	I understand you reasoning, but I have to disagree: it has happened
several times to me that I had to scale my whole scene (otherwise some
parts of an object made in sPatch were so small that they disappeared (I
don't mean that they were too small to be seen, more like they were
optimized away...). In such a case, the normal depth should follow the
general scaling. It's the same thing as when you see a map at several
scales: the fact that the scale changes doesn't change the relative size
of the terrain features (and shouldn't).
	The reasoning you present here is the reason why I am undecided for
questions 4 and 6 (and I should have said the same thing for question 5
now that I think about it...)

		Jerome
-- 
*******************************
* Always listen to experts,   * Jérôme M. BERGER
* they'll tell you what can't * mailto:ber### [at] inamecom
* be done and why...          * http://www.enst.fr/~jberger
* Then do it.                 *
*******************************

Post a reply to this message

SamuelT. <STB### [at] aolcom> wrote...
> No answers here, but an idea: can't you just add some more keywords so the
user
> can have all the possibilites? Especially the one where the normal depth
is
> flattened depending how you scale the object.
>

I am trying to find a way to do this.

My personal preference is: A,B,A,A,B,A
The rule here is: scaling ALWAYS affects depth.
I have found a way to implement this.

My close second choice is: B,B,B,B,B,B
The rule here is: scaling NEVER affects depth.
I have not yet found a way to implement this perfectly, but I'm looking.
<< Ohhh... brainstorm... I just thought of something that I'll have to try.
:-) >>

My third choice is: A,B,A,B,B,B
The rule here is: scaling the object ALWAYS affects depth
and scaling the normal NEVER affects depth.
This could be quite difficult to implement.  Please don't say you want it to
act this way.

What does the official version do?
Patterns such as waves/bumps: B,B,B,B,B,B
Patterns such as waves/bumps within normal_map: B,B,B,B,B,B
Patterns such as granite/bozo: B,B,B,B,B,B
Patterns such as granite/bozo within normal_map: A,A,B,A,A,B

( see a trend?  maybe keeping b,b,b,b,b,b would be good now that I look at
it this way... )

-Nathan

Post a reply to this message

Nathan Kopp <Nat### [at] Koppcom> wrote...
> 
> What does the official version do?
> Patterns such as waves/bumps: B,B,B,B,B,B
> Patterns such as waves/bumps within normal_map: B,B,B,B,B,B
> Patterns such as granite/bozo: B,B,B,B,B,B
> Patterns such as granite/bozo within normal_map: A,A,B,A,A,B
> 
I take that back.

That should be:

Official version:
Patterns such as waves/bumps: A,A,B,A,A,B
Patterns such as waves/bumps within normal_map: A,A,B,A,A,B
Patterns such as granite/bozo: B,B,B,B,B,B
Patterns such as granite/bozo within normal_map: A,A,B,A,A,B

-Nathan

Post a reply to this message

Nathan Kopp wrote:
> 
> Ken <tyl### [at] pacbellnet> wrote ...
> >
> > 1.) A
> > 2.) B
> > 3.) B
> > 4.) B
> > 5.) B
> > 6.) B
> >
> 
> I understand your rationale but I wonder why you chose A for 1 and B for 2
> and 3.  To be consistent, I would think that if 2 and 3 were B, then 1
> should be B also.
> 
> -Nathan

I was undecided about A and shot from the hip with my answer. For most
of my answers I was influenced by the images and the functions they
represented.

-- 
Wishing you Seasons Greetings, A Merry Christmas, and A Happy New Year !

Post a reply to this message

My answers:

1) A
2) B
3) A
4) A
5) B
6) A

Reasoning:  Take a heightfield.  Paste it onto the object.  Scale the
object.  A normal applied to an object should act like this.

Mark

Post a reply to this message

Hello Nathan,

What a lot of job from you again!!

There are a simple rule to find the good way to implement normal:

1) When you scale UNIFORMLY an OBJECT, and if you place the camera 
   in a proper way, you cannot see a change for the normal (and also 
   for the complete texture!!).

2) When you scale NON-UNIFORMLY an OBJECT, you can see a difference 
   for its normal (and also for its texture), because the modification 
   are not the same in all direction. One can also understand this as 
   follow: because the scaling is NON-UNIFORM, you don't have the same 
   object at the end of the scaling and its texture must follow this 
   change also! But when you scale UNIFORMLY en OBJECT, in fact, you 
   get the same object! You can see that there are a scaling only if 
   the object is compare to another (which is not scale). With other 
   words, if I scale a scene uniformly, I get the same scene, exactly 
   the same scene!
   
3) When you scale UNIFORMLY a NORMAL, of course, you must see a 
   difference for the appearance of the surface of the object 
   (you get a different object: it keeps the same shape but not 
   the same surface). 
   Because here, by scaling the normal, you change the 
   caracteristic of the surface. But this must be uniform in all 
   direction. So there are wider and deeper, slope unchange.

4) When you scale NON-UNIFORMLY a NORMAL, you must see a difference 
   also but the change is no-uniform so the slope will change.

Remark : the points 2) and 4) are automatic and come from the points 
         1) and 3). When you make the code to implement 
         the point 1) and 3) (value for scaling for x = value for 
         scaling for y = value for scaling for z), if you put now 
         different value for the scaling along each axis, you will
         get the behavior describe for the points 2) and 4) 

All this behavior are not a question of felling this must be like it.
This is logical. Moreover all other soft work like this (even if this is
shader instead of texture/material)

So here is my answer:

1) A
2) B
3) A
4) A
5) B
6) A

Ho! I am just looking the other message and I see that we are ok with 
this :)

Thank again Nathan for your work!

Fabian.
 


Nathan Kopp wrote:
> 
> I am wondering what people really think about how normals and scaling should
> work.  If you're interested in this topic, please see this page and take the
> 'surface normal survey'.  You can reply by emailing me or reply to this
> post.
> 
> http://nathan.kopp.com/normals.htm
> 
> -Nathan

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote:
: If you glue sand to the surface of a box, like the one used in your examples,
: as you scale the x & z directions the sand will be further apart but the
: relative height of the roughness on the surface will remain unchanged. Since
: we are talking surfaces here, if you glued sand to a thicker box, all you
: would have is sand with the same granular size on a larger box. It's surface
: roughness would remain unchanged. Therefore it is important to remember that
: scaling an object should not change the surface normals depth. It may change
: the slope and scale of the pattern but not it's physical depth.

  Note that there is a difference between scaling the object before or
after applying the texture.
  It's like with pigment. If you don't want the scaling of the object to
affect its pigment, you should scale the object before applying the pigment.
The same with normals: If you don't want the scaling to affect the normals,
you should scale the object first.

  Now there's an interesting question: What if you want the scaling of the
object to affect the pigment but not the normals?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Nieminen Juha wrote:

>   Now there's an interesting question: What if you want the scaling of the
> object to affect the pigment but not the normals?

object
{....
    pigment {...}
    scale <...>
    normal {...}
}

-- 
Wishing you Seasons Greetings, A Merry Christmas, and A Happy New Year !

Post a reply to this message

1: A

  Of course the slope should not change if we are scaling uniformly.

2: B

  This is a tricky question. Since the normal modifier simulates a kind
of heightfield, one should expect this kind of non-uniform scale to affect
its depth. Thus, I think that B is the most correct behaviour.
  The tricky part is what happens with the other sides of the box.
Unfortunately you didn't show them in the pictures, so I can't judge.
Since we are scaling more in the x and z directions, the slopes in the
sides of the box should get deeper (and the pattern "squeezed" in the y
direction due to the scale, of course), as a heightfield applied to the
sides of the box would. Does it do this?
  If the slopes in the sides of the box get also less deep (as in the top),
then I think that it's not a correct behaviour.

3: A

  This is the same as question 2 but in the other direction. If it works
like 2, then it's ok.

4: A
5: B
6: A

  I don't think that there's any difference between these and the three
previous.

  If megapov already works this way, then I apologize for my behaviour.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

I think that the behaviour of the normal modifier should not be
dependant on the pattern type.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Nieminen Juha wrote:
> 
>   I think that the behaviour of the normal modifier should not be
> dependant on the pattern type.

I agree. The model, whatever it is, should be consistant for all patterns.

-- 
Wishing you Seasons Greetings, A Merry Christmas, and A Happy New Year !

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote:
:>   Now there's an interesting question: What if you want the scaling of the
:> object to affect the pigment but not the normals?

: object
: {....
:     pigment {...}
:     scale <...>
:     normal {...}
: }

  But does this work? The pigment and the normal are part of the same
texture.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Nieminen Juha wrote:
> 
> Ken <tyl### [at] pacbellnet> wrote:
> :>   Now there's an interesting question: What if you want the scaling of the
> :> object to affect the pigment but not the normals?
> 
> : object
> : {....
> :     pigment {...}
> :     scale <...>
> :     normal {...}
> : }
> 
>   But does this work? The pigment and the normal are part of the same
> texture.

  If you avoid the texture wrapper it does. Try this and you will see that
the pigment pattern scales with the box but the normal remains uneffected.
It is all in how you order the operations in the object statement.

camera { location z*-4 >look_at 0}

light_source{<-10,10,-10>rgb 1}

box{-1,1
    pigment {gradient y color_map{[.5 red 1][.5 blue 1]}}
    scale <1,1,1>
    normal {crackle 1 scale .5}
  translate x*-1
}


box{-1,1
    pigment {gradient y color_map{[.5 red 1][.5 blue 1]}}
    scale <1,.5,1>
    normal {crackle 1 scale .5}
  translate x*1
}

-- 
Wishing you Seasons Greetings, A Merry Christmas, and A Happy New Year !

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote:
:>   But does this work?

:   If you avoid the texture wrapper it does.

  Ok. Then I think there should not be any problem with the ABAABA behaviour.

  (Yes, there still is a problem with declared textures...)

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Let me put it this way:

*If you scale the object (uniformly), all the attributes of the object
should look the same, ie: you zoom out the appropriate ammount, and it looks
the same.
*If you scale the normal (uniformly), the normal should scale, but the depth
remain the same. To control depth, use bump_size.
*If you scale the object (non-uniformly), all the attributes of the object
should fit in the same space as before scaling, ie: like if they were pasted
to it and squished or stretched with it.
*If you scale the normal (non-uniformly), the normal should squish or
stretch, with the depth remaining the same. Again, to control depth, use
bump_size.

So, in conclusion, the depth should maintain itself along with the scale, so
the object looks the same, no matter what scale. To change the depth, use
bump_size. This is my humble opinion. Now, to answer your survey:

1) A
2) B
3) A
4) None of the above? I don't understand what "slope" is, but I know that
all the attributes of the normal should scale according to the scale, thus
becoming deeper and larger, or shallower and smaller, depending on the scale
applied.
5) In this case, the normal should be more tightly packed in the y region
than in the x and z regions, and thus B?
6) None of the above. Here, it should stretch in the y direction, but the
depth should remain the same.
A) The normal is part of the texture "glued" to the object, so it should
"stick" to it and look the same. Perhaps B, although it looks too deep for
my taste.
B) B
C) A
D) B

I hope I was consistent in my responses and reasonings, Mom interrupted me
like 10 times to call people to thank them for my graduation presents. I
even got a cell phone! =)

Post a reply to this message

>Reasoning:  Take a heightfield.  Paste it onto the object.  Scale the
>object.  A normal applied to an object should act like this.


Aha! We think alike! This is what I was trying to say in my reply.

Post a reply to this message

1) A
2) A
3) A
4) A
5) A
6) A
A) A
B) A
C) A
D) A

And I think I will use MegaPov very soon.


Merry Christmas


Philippe

Post a reply to this message

Nathan Kopp wrote:
> 
> I am wondering what people really think about how normals and scaling should
> work.  If you're interested in this topic, please see this page and take the
> 'surface normal survey'.  You can reply by emailing me or reply to this
> post.
> 
> http://nathan.kopp.com/normals.htm
> 
> -Nathan

for object{ box{...normal{...} scale<x,y,z>} it definitely should
act the same as if the normal were real geometry.

So 1-A, 2-B, 3-A

If only the normal is scaled, it's more of a tricky question.
I think I'd have to go with scaling the pattern but not the depth
though I'm not real happy about that because it's inconsistent.

4-B, 5-B, 6-B
but still with reservations :(

Anyway, it's good to get all this thrashed out before any more
patching gets done.

Cheers, PoD.

Post a reply to this message

Nieminen Juha <war### [at] punarastascstutfi> wrote...

>   The tricky part is what happens with the other sides of the box.
> Unfortunately you didn't show them in the pictures, so I can't judge.
> Since we are scaling more in the x and z directions, the slopes in the
> sides of the box should get deeper (and the pattern "squeezed" in the y
> direction due to the scale, of course), as a heightfield applied to the
> sides of the box would. Does it do this?

Yes, it does to this.

> 3: A
> 
>   This is the same as question 2 but in the other direction. If it works
> like 2, then it's ok.

It does work like 2.

>   I don't think that there's any difference between these and the three
> previous.

I agree.

>   If megapov already works this way, then I apologize for my behaviour.

I encourage you to test it with these examples.

-Nathan

Post a reply to this message

TonyB <ben### [at] panamaphoenixnet> wrote...
> *If you scale the object (uniformly), all the attributes of the object
> should look the same, ie: you zoom out the appropriate ammount, and it
looks
> the same.
> *If you scale the normal (uniformly), the normal should scale, but the
depth
> remain the same. To control depth, use bump_size.
> *If you scale the object (non-uniformly), all the attributes of the object
> should fit in the same space as before scaling, ie: like if they were
pasted
> to it and squished or stretched with it.
> *If you scale the normal (non-uniformly), the normal should squish or
> stretch, with the depth remaining the same. Again, to control depth, use
> bump_size.

This would be very difficult to implement in the existing code.  I do hope
that this is not the rule-set that is agreed upon.  But I do see your logic
and agree at least somewhat.  ;-)

> 6) None of the above. Here, it should stretch in the y direction, but the
> depth should remain the same.

The top of the box has a normal of 'y' so stretching it in the Y direction
should leave it
the same (well, maybe the pattern changes a bit).

-Nathan

Post a reply to this message

You are totally right! This is the good way to find the good behavior.

Fabian.

Mark Wagner wrote:
> 
> My answers:
> 
> 1) A
> 2) B
> 3) A
> 4) A
> 5) B
> 6) A
> 
> Reasoning:  Take a heightfield.  Paste it onto the object.  Scale the
> object.  A normal applied to an object should act like this.
> 
> Mark

Post a reply to this message

I agree with TonyB.

It is my understanding that bump_size has a single vector that scales the bumps
the same amount in x, y & z vectors.

Shouldn't the bump_size have x, y & z vectors - or does it already?

- Tony


Nathan Kopp wrote:

> TonyB <ben### [at] panamaphoenixnet> wrote...
> > *If you scale the object (uniformly), all the attributes of the object
> > should look the same, ie: you zoom out the appropriate ammount, and it
> looks
> > the same.
> > *If you scale the normal (uniformly), the normal should scale, but the
> depth
> > remain the same. To control depth, use bump_size.
> > *If you scale the object (non-uniformly), all the attributes of the object
> > should fit in the same space as before scaling, ie: like if they were
> pasted
> > to it and squished or stretched with it.
> > *If you scale the normal (non-uniformly), the normal should squish or
> > stretch, with the depth remaining the same. Again, to control depth, use
> > bump_size.
>
> This would be very difficult to implement in the existing code.  I do hope
> that this is not the rule-set that is agreed upon.  But I do see your logic
> and agree at least somewhat.  ;-)
>
> > 6) None of the above. Here, it should stretch in the y direction, but the
> > depth should remain the same.
>
> The top of the box has a normal of 'y' so stretching it in the Y direction
> should leave it
> the same (well, maybe the pattern changes a bit).
>
> -Nathan

Post a reply to this message

Tony Vigil <tvi### [at] emc-inccom> wrote ...
> I agree with TonyB.
>
> It is my understanding that bump_size has a single vector that scales the
bumps
> the same amount in x, y & z vectors.
>

Actually, bump_size is a single scalar that scales the bumps only in the
direction of the surface normal.

-Nathan

Post a reply to this message

On Thu, 16 Dec 1999 21:51:08 -0500, "Nathan Kopp" <Nat### [at] Koppcom> wrote:

>I am wondering what people really think about how normals and scaling should
>work.  If you're interested in this topic, please see this page and take the
>'surface normal survey'. 

1  A
2  B
3  A
4  A
5  B
6  A

I get strange results from normal { crackle } in MegaPatch.
See posting in p.b.i.
------------
dav### [at] cwcomnet
http://www.hamiltonite.mcmail.com
------------

Post a reply to this message

>1) A
>2) A
>3) A
>4) A
>5) A
>6) A
>A) A
>B) A
>C) A
>D) A


Are you Canadian, per chance? ;)

Post a reply to this message

TonyB wrote:
> >1) A
> >2) A
> >3) A
> >4) A
> >5) A
> >6) A
> >A) A
> >B) A
> >C) A
> >D) A
>
>
> Are you Canadian, per chance? ;)
>
>

No, I'am Belgian.
I suppose there is a joke/pun of some kind here, but I do not get it...


Confusedly

Philippe

Post a reply to this message

Aaaaargh... I got this wrong.

I wanted to answer the survey _quickly_ before the week-end. I shouldn't
have. Now, I look dumb once again (I'am getting used to it).

It tortured me the whole week-end (and no internet access - aaargh).

Please, let me restate this:
1) A.
2) B.
3) A.
4) A.
5) B.
6) A.
A) A.
B) A..
C) A.
D) A.

I also wanted do download MegaPov this Week-end, but *sigh* no internet
acces...

:-(


I'am dumb, I'am a moron, please forgive me



Merry christmas to everybody.


Povingly,


Philippe

Post a reply to this message

On Mon, 20 Dec 1999 10:33:11 +0100, "Philippe Debar"
<phi### [at] hotmailcom> wrote:

>No, I'am Belgian.
>I suppose there is a joke/pun of some kind here, but I do not get it...

  Philippe, it probably lost something while crossing the Atlantic <s>.
Supposedly, Canadians use the expression, "Eh?", a lot, usually at the
end of a sentence. I cannot verify this.

-- 
Alan - ako### [at] povrayorg - a k o n g <at> p o v r a y <dot> o r g
http://www.povray.org - Home of the Persistence of Vision Ray Tracer

Post a reply to this message

I would like to see normals act the same as if they were 'real', 
(heightfields for flat objects). Besides just making more sense to me, 
it keeps open the possibility of a 'deform' keyword some day that 
actually does the deformation that the normal is pretending to do, with 
the obvious speed penalty.

It may never happen, but it has been a dream of mine... to dream... the 
impossible dream...

Jerry

Post a reply to this message

"eh" sounds like long vowel "a", just to further point out.

Bob

"Alan Kong" <ako### [at] povrayNO-SPAMorg> wrote in message
news:c6as5soem97eju5s2kligkosl2aejep82g@4ax.com...
> On Mon, 20 Dec 1999 10:33:11 +0100, "Philippe Debar"
> <phi### [at] hotmailcom> wrote:
>
> >No, I'am Belgian.
> >I suppose there is a joke/pun of some kind here, but I do not get it...
>
>   Philippe, it probably lost something while crossing the Atlantic <s>.
> Supposedly, Canadians use the expression, "Eh?", a lot, usually at the
> end of a sentence. I cannot verify this.
>
> --
> Alan - ako### [at] povrayorg - a k o n g <at> p o v r a y <dot> o r g
> http://www.povray.org - Home of the Persistence of Vision Ray Tracer

Post a reply to this message

Not normals exactly but displacement mapping is something that does that.
The 'function' in isosurfaces can do it.  No idea why the normal statement
is not considered for such a thing as "deform" or displacement as you say;
makes sense to me.  Probably since it is a =faked= surface deformation
already and that would make it obsolete maybe? : )  In any case the change
would need the system used in the current patches using isosurface
functions.

Bob

"Jerry" <jer### [at] acusdedu> wrote in message
news:jerry-B58105.11121720121999@news.povray.org...
> I would like to see normals act the same as if they were 'real',
> (heightfields for flat objects). Besides just making more sense to me,
> it keeps open the possibility of a 'deform' keyword some day that
> actually does the deformation that the normal is pretending to do, with
> the obvious speed penalty.
>
> It may never happen, but it has been a dream of mine... to dream... the
> impossible dream...
>
> Jerry

Post a reply to this message

1. A
2. B
3. A
4. A
5. B
6. A


I straddled the fence for long time on this question before 
falling gracelessly on the side of making normals more like
the surface displacements they emulate. Even if this means 
adding a #version switch or potentially breaking every scene 
ever made for POV, (backward compatibility is a tyrrant!), but 
I just can't help liking the displacement emulating paradigm 
better than having to separately adjust bump_size. It's simply
more intuitive. I *could* learn to live with it either way,
as long as whatever paradigm is chosen is applied consistantly
to all kinds of normals, but automatically adjusting normals 
with scale statements is more sensible in the long term. 


Charles

---
Nathan Kopp wrote:
> 
> I am wondering what people really think about how normals and scaling should
> work.  If you're interested in this topic, please see this page and take the
> 'surface normal survey'.  You can reply by emailing me or reply to this
> post.
> 
> http://nathan.kopp.com/normals.htm
> 
> -Nathan

Post a reply to this message

:-)

Post a reply to this message

In article <385e8587@news.povray.org>, "omniVERSE" <inv### [at] aolcom> 
wrote:

>Not normals exactly but displacement mapping is something that does that.
>The 'function' in isosurfaces can do it.  No idea why the normal statement
>is not considered for such a thing as "deform" or displacement as you say;
>makes sense to me.  Probably since it is a =faked= surface deformation
>already and that would make it obsolete maybe? : )  In any case the change
>would need the system used in the current patches using isosurface
>functions.

I doubt that true displacement will ever be as fast as faked 
displacement. That's one of the reasons it would be nice to use them 
both interchangeably--assuming it is possible at all.

Or there could be an added 'quality' number that causes normals to be 
'real'. "My POV-Ray goes up to 11."

Jerry

Post a reply to this message

Charles Fusner wrote:

> 1. A
> 2. B
> 3. A
> 4. A
> 5. B
> 6. A

> I straddled the fence for long time on this question before
> falling gracelessly on the side of making normals more like
> the surface displacements they emulate. Even if this means

> adding a #version switch or potentially breaking every scene
> ever made for POV, (backward compatibility is a tyrrant!), but
> I just can't help liking the displacement emulating paradigm
> better than having to separately adjust bump_size. It's simply

This is exactly what I think (and even tried (and possibly failed)
to express a few months ago (I interpreted it as a bug)): Modifiying
a normal on a scaled surface is different from modifying the
surface and then computing it's modified normal.
Vanilla povray does the former, which not only is (IMHO)
counterintuitive, but even constructs normals which cannot belong
to any surface (they fail to fulfill the integrability condition).
This should be visible if a modified copy of example 5 with
"<5,1,1>" instead of "<5,1,5>"is run.

Many thanks to Nathan for creating a web page which makes
this distinction very clear (it goes far beyond the examples
which I intended to make, but never found the time to do).

Btw., even if ABAABA does not win the election, I'd wish to see
1=4, 2=5, 3=6.

Ralf

Post a reply to this message