 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In TextureA below I have a texture_map based on a slope pattern. One of the
textures in the texture_map has a normal{} entry.
Should this normal be taken into account when evaluating the slope? I don't
know. What I do know is that sometimes it is and sometimes it isn't!
If an object is just textured with TextureA, then it isn't, but if an object
is textured with TextureB, which has a texture_map with TextureA as an
entry, then it is!
Can anybody explain which of the two is the correct behavior? I assume that
one of them ought to be a bug. If not, then could somebody explain the logic
behind this inconsistent behavior?
light_source {<0,1,-1>*1000, color 1}
#declare TextureA =
texture {
slope y
texture_map {
[0.4 pigment {red 1}]
[0.5 pigment {green 1} normal {spotted 5}]
[0.6 pigment {blue 1}]
}
}
#declare TextureB =
texture {
spotted
texture_map {[0,TextureA][1,TextureA]}
}
union {
cylinder {-y, y, 1}
sphere {-y, 1}
sphere {y, 1}
translate 5*z
//texture {TextureA} // normal not used in slope
texture {TextureB} // normal is used in slope
}
Rune
--
3D images and anims, include files, tutorials and more:
rune|vision: http://runevision.com
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Oh, and I'm using POV-Ray for Windows Version 3.6.0.icl8.win32 on a WinXP
machine.
Rune
--
3D images and anims, include files, tutorials and more:
rune|vision: http://runevision.com
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The oddness continues. Try to have a look at the scene below...
camera {orthographic location -6*z}
light_source {<0,1,-1>*1000, color 1}
#declare TextureA =
texture {
slope y
texture_map {
[0.4 pigment {red 1}]
[0.5 pigment {green 1} normal {spotted 5}]
[0.6 pigment {blue 1}]
}
}
#declare TextureB =
texture {
gradient y+x
texture_map {[0,TextureA][1,TextureA]}
}
#declare TextureC =
texture {
gradient y-x
texture_map {[0,TextureB][1,TextureB]}
}
#declare Object =
union {
cylinder {-y, y, 1}
sphere {-y, 1}
sphere {y, 1}
translate 5*z
}
object {Object texture {TextureA} translate -3*x}
object {Object texture {TextureB}}
object {Object texture {TextureC} translate 3*x}
Rune
--
3D images and anims, include files, tutorials and more:
rune|vision: http://runevision.com
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hiya Rune.
Okay... you are asking about the slope pattern being, or not being, applied
where a normal exists depending on it being a part of the original texture
within the slope pattern, or used later as another pattern containing it as
a whole slope pattern.
My way of thinking would be this: The normal shouldn't be able to be used as
a virtual surface, and as so, not be applicable to the slope pattern when
the texture is within the pattern list. However, this obviously shows it
does if used later in another texture pattern, neither of which might not be
incorrect or any bug.
Have to ask if you'd rather have the slope be effected by normals or instead
retain original texturing, which is why it reasons to me that it works as
expected. That is, keeping the non-slope texturing for individual patterns
(your TextureA) but perhaps use the normal if the slope pattern itself is
reused in another pattern later (TextureB).
Not sure if I made all that clear enough to everyone reading this. It could
be something done differently I suppose, just that I see it doing what I'd
expect of it after a little thought here.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm not sure I'm following you. Anyway, I think that a slope pattern should
never be affected on normals that are on a lower level, since it creates a
mutual dependency that makes it difficult to predict the result. The amount
of the normal applied is dependent on the slope, but the slope is also
dependent on the normal. I'm not even sure how it's implemented in the
current code, no matter if the mutual dependency behavior is a bug or not.
Either way, there certainly is a bug. Have a look at the code below:
camera {orthographic location -6*z}
light_source {<0,1,-1>*1000, color 1}
#declare BaseTexture =
texture {
slope y
texture_map {
[0.4 pigment {red 1}]
[0.5 pigment {green 1} normal {spotted 5}]
[0.6 pigment {blue 1}]
}
}
#declare TextureA =
texture {
gradient y
texture_map {
[0.0,BaseTexture]
[1.0,BaseTexture]
}
}
#declare TextureB =
texture {
gradient y
texture_map {
[0.0,BaseTexture]
[0.5,BaseTexture]
[1.0,BaseTexture]
}
}
#declare Object =
union {
cylinder {-y, y, 1}
sphere {-y, 1}
sphere {y, 1}
translate 5*z
}
object {Object texture {BaseTexture} translate -3*x}
object {Object texture {TextureA}}
object {Object texture {TextureB} translate 3*x}
TextureA and TextureB should look completely identical, yet they don't. The
extra entry in the texture_map of TextureB clearly shows up even though it
should make no difference. The thing is - the normal is taken into account
for the slope at the beginning of map entry ranges but not in the end of map
entry ranges. So in TextureA the slope is affected by normal decreasingly
from pattern value 0.0 to 1.0, while in TextureB it's affected decreasingly
from pattern value 0.0 to 0.5, then starting over at 0.5 and having
decreasing effect again from 0.5 to 1.0.
There is absolutely no logic in this, and I'm very sure it's a bug. I'm just
not sure what the intended correct behavior is, but it certainly can't be
this.
Rune
--
3D images and anims, include files, tutorials and more:
rune|vision: http://runevision.com
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I think this might be something to do with 'altitude', mainly if not
entirely so.
Having now tried it by using (just now realized you did not use curly
braces):
slope {
y
altitude y*4, -2, 2
}
I see that it seems to clean up your "bug". Keeping in mind that those
gradient y patterns are still going to repeat over every unit of length
along the y axis. So I also tried replacing them with function {abs(y)},
too.
Perhaps this is all that is going on, simply a matter of defining the object
extents for the slope pattern, or vice versa, so it fits.
Back to my previous reply, just to try and clarify hopefully, what I was
thinking about mostly was the way normals might be applied by the slope
pattern initially. If they were used inclusive to the slope pattern, as well
as the physical surface of an object, then that could mess with the
texturing in an unwanted way, as in you might like to retain a predeclared
texture for use in the slope pattern yet not apply slope to it.
Your examples seemed to imply the normal pattern gets used only after
reusing the slope pattern within other patterns. I had thought you wanted it
to react in all cases. To my way of thinking I wouldn't expect it to be
involved at all, really, unless there were a way to apply slope over another
texture on purpose and then have it react to those normals just like the
object surface shapes.
This is all something I hadn't considered until after reading your first
message.
Bob Hughes
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
