 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 05.08.2021 09:28, Kenneth wrote:
> "pkoning" <nomail@nomail> wrote:
>>
>> ...the parser complains that the "warp" modifier is not expected. See
>> attached.
>>
>> Possible Parse Error: Unmatched {
>> ...
>> Parse Error: No matching }, warp found instead
>
> By the way: As Clipka pointed out in a another recent thread, those "unmatched
> {" warnings/errors are sometimes 'generic', in that they simply flag some kind
> of 'possible' error that isn't clearly known to the parser. Yeah, it's kind of
> confusing sometimes, to figure out what the true problem is. ;-)
Actually, the reason this is called "possible error" (my naming back
then) has to do with the message driven changes to output from POV-Ray
3.5 onward. Before, the parser would simply output to a text stream, so
it was perfectly feasible to output some text somewhere and the next
line would make sense out of it (from the user's perspective). However,
there might be a long and complex call chain of internal parser
functions between the place that detected the likely error and the place
that actually knows it is an error.
In modern integrated development environments (IDEs) it is at last
handled much better because the parsers hand them a full trace of all
the steps they took to get where they are and the user gets a kind of
trace where the parser went with each step and what it expected or
allowed. So yes, error reporting evolved over the last 15 years. But it
would require a very well structured parser, which POV-Ray doesn't have
due to its age (and no, it is not easy to rewrite either, nor is it a
beginner's task).
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmail com> wrote:
> "pkoning" <nomail@nomail> wrote:
>
> >
> > Just now I tried to reproduce it but I'm seeing a different baffling issue:
> > when I take out the "cells" pattern and replace it by a reference to a plain
> > texture, the parser complains that the "warp" modifier is not expected. See
> > attached.
> >
> > Possible Parse Error: Unmatched {
> >
> > line 100
> > Parse Error: No matching }, warp found instead
>
> Apparently, a warp{...} cannot be added to a previously-#declared texture. I
> sometimes run into similar problems; some things can be added, some can't.
>
> Your syntax is like this:
>
> #declare tmoon = texture
> {
> pbfr // [previously-#declared]
> scale <rfeature, rfeature * 2, 1>
> no_bump_scale
> warp {spherical}
> }
>
> Interestingly, the no_bump_scale *is* OK there. I was surprised at that.
Yes, that's documented to affect the texture it is applied to and all its
offspring.
It's strange that warp works the way you mentioned, it makes it very hard to
use. The fact that it's an undocumented behavior doesn't help. (I suppose it
makes sense if it's considered a bug -- I think it should be.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
> ...
> Apparently, a warp{...} cannot be added to a previously-#declared texture. I
> sometimes run into similar problems; some things can be added, some can't.
>
> Your syntax is like this:
>
> #declare tmoon = texture
> {
> pbfr // [previously-#declared]
> scale <rfeature, rfeature * 2, 1>
> no_bump_scale
> warp {spherical}
> }
>
> Interestingly, the no_bump_scale *is* OK there. I was surprised at that.
That doesn't seem to be the explanation. I rewrote it without any declared
identifiers and it still fails:
#declare tmoon = texture
{
pigment { color srgb <0.55 0.60 0.65> }
finish { moon_finish }
normal {
bump_map {
png "robo-bfr.png"
bump_size 8e-3 *5
}
}
warp {spherical}
scale <rfeature, rfeature * 2, 1>
no_bump_scale
}
Same message, complaining about the warp.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"pkoning" <nomail@nomail> wrote:
> That doesn't seem to be the explanation. I rewrote it without any declared
> identifiers and it still fails:
> Same message, complaining about the warp.
Because you have it in the wrong place.
You have a plain srgb pigment - no _pattern_. So there is nothing to warp.
Move the warp up into the normal statement and it works.
#declare tmoon = texture
{
pigment { color srgb <0.55 0.60 0.65> }
finish { specular 0.1 }
normal {
bump_map {
png "plasma2.png"
bump_size 8e-3 *5
}
warp {spherical}
}
scale <rfeature, rfeature * 2, 1>
no_bump_scale
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 8/5/21 6:10 PM, Bald Eagle wrote:
> "pkoning" <nomail@nomail> wrote:
>
>> That doesn't seem to be the explanation. I rewrote it without any declared
>> identifiers and it still fails:
>
>> Same message, complaining about the warp.
>
> Because you have it in the wrong place.
> You have a plain srgb pigment - no _pattern_. So there is nothing to warp.
> Move the warp up into the normal statement and it works.
>
> #declare tmoon = texture
> {
> pigment { color srgb <0.55 0.60 0.65> }
> finish { specular 0.1 }
> normal {
> bump_map {
> png "plasma2.png"
> bump_size 8e-3 *5
> }
> warp {spherical}
> }
>
> scale <rfeature, rfeature * 2, 1>
> no_bump_scale
> }
>
I think you've got it Bill. The behavior, though, looks inconsistent to
me. Maybe if I think about it more, it's how it must be?
Looking at something like this:
//---
#version 3.8;
global_settings { assumed_gamma 1 }
#declare pmoon = pigment {
color rgb <0.55 0.60 0.65> warp {spherical}
}
#declare tmoon = texture {
// pigment { color rgb <0.55 0.60 0.65> warp { spherical } }
pigment {
function { 0.5 }
color_map {
[ 0 color rgb <0.55 0.60 0.65> ]
[ 1 color rgb <0.55 0.60 0.65> ]
}
//warp {spherical}
}
finish { specular 0.1 }
normal {
bump_map {
png "plasma2.png"
bump_size 8e-3 *5
}
//warp {spherical}
}
warp {spherical} // Parser sees this as illegal
scale <1, 2, 1>
no_bump_scale
}
//---
I get :
File 'hmm.pov' line 7: Possible Parse Error: Unmatched {
File 'hmm.pov' line 26: Parse Error: No matching }, warp found instead
If I comment that last warp{}, and un-comment two warp{}s above - or use
instead the plain pigment inside the texture with the warp{}, I get no
complaint about any 'pointless' warps(a) - though some of them certainly
are.
There are likely situations where top level warps / turbulence could be
applied and passed to contained blocks, but I believe it would be hard
(impossible?) to do generally...
Drifting, the above examples touch on why I find myself sometimes
wanting to be able to declare warp ids.
(a) - Not done any debugging to see if the 'pointless' warps / modifiers
end up used.
Aside 1: turbulence{} trips this parse error too.
Aside 2: transforms can be pointless too and like turbulence and warp we
'sometimes' get PossibleError warnings for those though I'm not aware of
any hard errors there.
Aside 3: With image based mapping, the usual approach would be to use
the appropriate map type inside the bump_map{} block - here 'map_type 1'
spherical - though the warp{spherical} modifier should work too.
Aside 3a: There is too 'uv_mapping' for spheres which can be used inside
texture, pigment and normal blocks.
:-) Nothing if not lots of knobs, buttons and switches!
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William F Pokorny <ano### [at] anonymousorg> wrote:
> I think you've got it Bill. The behavior, though, looks inconsistent to
> me. Maybe if I think about it more, it's how it must be?
Well, there are so many ways to go about it.
> (a) - Not done any debugging to see if the 'pointless' warps / modifiers
> end up used.
>
> Aside 1: turbulence{} trips this parse error too.
>
> Aside 2: transforms can be pointless too and like turbulence and warp we
> 'sometimes' get PossibleError warnings for those though I'm not aware of
> any hard errors there.
Indeed. However, I would imagine that one might code up something that just
loops through a bunch of things that these may or may not have any visible
effect on, and it's just a throwaway operation for those instances.
> Aside 3: With image based mapping, the usual approach would be to use
> the appropriate map type inside the bump_map{} block - here 'map_type 1'
> spherical - though the warp{spherical} modifier should work too.
Probably the best approach, I would imagine. Tailor made for the purpose.
> Aside 3a: There is too 'uv_mapping' for spheres which can be used inside
> texture, pigment and normal blocks.
There is, though I still haven't figured out how to separate the the normal from
the uv mapped texture... Someday...
> :-) Nothing if not lots of knobs, buttons and switches!
No. Kidding.
There are days when I am truly astounded that all of the bits of things the user
wants to do and demands of the parser and modifier hierarchy all more or less
work after processing billions of cycles of under-the-hood raytracing black
magic.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 06.08.2021 um 02:20 schrieb William F Pokorny:
> If I comment that last warp{}, and un-comment two warp{}s above - or use
> instead the plain pigment inside the texture with the warp{}, I get no
> complaint about any 'pointless' warps(a) - though some of them certainly
> are.
The primary reason is that textures - in general - are nothing but mere
containers to bundle pigments, finishes and normal perturbations into a
coherent unit. As such, they provide no functionality of their own.
Specifically, they have no "hook" built into them to plug a warp into.
Exceptions to the rule are patterned and layered textures, which both
add extra functionality of their own. And patterned textures do provide
a "hook" for a warp to plug into.
Yes, in theory we could have non-patterned textures propagate any warps
to their pigments, finishes and normals. We mustn't do that for
patterned textures though. Also, what should happen if the pigment,
finish or normal already has a warp? Should the texture warp be ignored,
appended, prepended, or override the pigment/finish/normal warp? What
should happen in this context to things that may or may not be converted
into warps under the hood, such as turbulence?
It would also mean that we'd have to add room for extra data to the
generic texture data structure, at least during parsing, because we
can't propagate the warp before the scene has been fully assembled: The
texture could be re-used someplace else and the pigment replaced with a
different one, for instance, in which case that new one would also have
to have the warp propagated to it.
And currently we're using the same data structures for both parsing and
rendering, so any extra memory we reserve for the parsing step is also
memory that will be unavailable during the render proper for other
stuff, such as storing image data, radiosity samples, photon maps and
the like. It would also be unused memory sitting right in the middle of
other data we might need frequently, potentially displacing useful data
from the CPU caches and thus maybe even dragging down performance.
TL;DR: I think there are too many worms in that can to open it up
without need.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 2021-08-05 2:40 AM (-4), Kenneth wrote:
>
> Apparently, a warp{...} cannot be added to a previously-#declared texture. I
> sometimes run into similar problems; some things can be added, some can't.
I just remembered I ran into this problem a few years ago. Now that
clipka has convincingly explained why this falls squarely into "feature"
category, I should share the solution Thomas suggested to me, which
worked well.
https://news.povray.org/54eb1a57@news.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Cousin Ricky <ric### [at] yahoocom> wrote:
> On 2021-08-05 2:40 AM (-4), Kenneth wrote:
> >
> > Apparently, a warp{...} cannot be added to a previously-#declared texture. I
> > sometimes run into similar problems; some things can be added, some can't.
>
> ...I should share the solution Thomas suggested to me, which
> worked well.
>
> https://news.povray.org/54eb1a57@news.povray.org
That's an interesting trick!
Here's Thomas's example:
texture {
granite
texture_map {
[0 MyTexture1] // pre-#declared texture
[1 MyTexture2] // pre-#declared texture
}
warp {turbulence 1}
}
Modified a little, it works for the OP's problem:
#declare tmoon =
texture{
gradient x // [a simple DUMMY pattern, because some kind of pattern is
// needed for a texture_map]
texture_map{
[.5 pbfr] // the pre-#declared texture-- and only one entry
}
warp{turbulence .2}
}
My guess is that the 'dummy' pattern is not imposed on the pbfr texture
because there is only one entry in the texture_map's index... so the dummy
pattern doesn't matter.
Here's a small test scene of my own:
-------
#version 3.7; // or 3.8
global_settings{assumed_gamma 1.0}
camera {
perspective
location <.5, .5, -1>
look_at <.5, .5, 0>
right x*image_width/image_height
angle 67
}
background{rgb .1}
// my own pre-#declared texture
#declare pbfr =
texture{
pigment{hexagon rotate 90*x scale .1}
finish{ambient 1 emission 0 diffuse 0}
}
// adding a warp(...) to the #declared texture...
#declare tmoon =
texture{
gradient x // [DUMMY pattern]
texture_map{
[.5 pbfr]
}
warp{turbulence .2}
}
box{0,<1,1,.1>
texture{tmoon}
}
--------
BTW, warp{spherical} also works-- but with that I see tiny speckles that look
like coincident surface problems(??). It's not due to the earlier hexagon
pattern; I substituted 'bumps' there and still see some speckles. Maybe due to
the texture_map trick itself, somehow? Or the final box's position?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
> My guess is that the 'dummy' pattern is not imposed on the pbfr texture
> because there is only one entry in the texture_map's index... so the dummy
> pattern doesn't matter.
>
> ... and the texture_map supplies the 'hook' for the warp{...}, that Clipka
mentioned.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
