 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
If you have a little bit time and experience at your hand, you can help
me to find my error.
When calling the texture macro directly from another file, it works. But
when calling it from within the parameter liner of another macro, I get
the error message you cans see as comment behind one of the lines. Why?
Why? Why?
--------------------------
#declare MyShipTex = on;
#declare MyRandom = seed(now*24*60*60);
include "Rand.inc"
include "SL - Woods.inc"
#macro MyBrownSimpleQuoVadis(MyOrientation)
#declare MySeeder = seed(now*24*60*60);
#declare MyDirection = MyOrientation*<1,2,3>;
#declare MyAlignment = MyDirection.x+MyDirection.y+MyDirection.z;
#switch(MyAlignment)
#case(1)
texture { MyBrownDarkwood rotate < 00.0, 90.0, 00.0 > rotate < 00.0,
00.0, 00.0 > scale 0.5+rand(MySeeder)*1.5 translate < rand(MySeeder),
rand(MySeeder), rand(MySeeder) > } // X
texture { MyBrownSimple } // Parse Error: Expected ")", # found instead
#break
#case(2)
texture { MyBrownDarkwood rotate < 90.0, 00.0, 00.0 > rotate < 00.0,
00.0, 00.0 > scale 0.5+rand(MySeeder)*1.5 translate < rand(MySeeder),
rand(MySeeder), rand(MySeeder) > } // Y
texture { MyBrownSimple }
#break
#case(3)
texture { MyBrownDarkwood rotate < 00.0, 00.0, 90.0 > rotate < 00.0,
00.0, 00.0 > scale 0.5+rand(MySeeder)*1.5 translate < rand(MySeeder),
rand(MySeeder), rand(MySeeder) > } // Z
texture { MyBrownSimple }
#break
#end
#end
#macro
PostsSideRailing(MyLength,MyPlankHeight,MyMinimum,MyMaximum,MyIncrease,MyR,
MyT,MyRY,MyX,MyMacroTexture)
// 1.99,0.15,0.55,1.45,0.30,2.5,0.02,0.0,9.90,MyYellowSimple
union
{
#declare MyLevel = MyMinimum;
#declare AllLevels = MyMaximum;
#while(MyLevel<=AllLevels)
box { < -MyLength, 0.00, -0.025 > < MyLength, MyPlankHeight, 0.00
> MyMacroTexture rotate < 0.0, 0.0, RRand(-MyR,MyR,MyRandom) > rotate <
0.0, MyRY, 0.0 > translate < 0.0, MyLevel+RRand(-MyT,MyT,MyRandom),
-MyX > scale < 1.0, 1.0, 1.0 > }
box { < -MyLength, 0.00, -0.025 > < MyLength, MyPlankHeight, 0.00
> MyMacroTexture rotate < 0.0, 0.0, RRand(-MyR,MyR,MyRandom) > rotate <
0.0, MyRY, 0.0 > translate < 0.0, MyLevel+RRand(-MyT,MyT,MyRandom),
-MyX > scale < 1.0, 1.0, -1.0 > }
#declare MyLevel=MyLevel+MyIncrease;
#end
}
#end
object {
PostsSideRailing(0.725,0.30,0.60,4.50,0.65,1.5,0.02,-90.0,6.675,MyBrownSimp
leQuoVadis(x))
translate < -20.9, 0.0, 0.0 > }
---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 22/04/2018 à 07:47, Sven Littkowski a écrit :
> If you have a little bit time and experience at your hand, you can help
> me to find my error.
>
> When calling the texture macro directly from another file, it works. But
> when calling it from within the parameter liner of another macro, I get
> the error message you cans see as comment behind one of the lines. Why?
> Why? Why?
>
>
>
> --------------------------
>
> #declare MyShipTex = on;
> #declare MyRandom = seed(now*24*60*60);
>
> include "Rand.inc"
> include "SL - Woods.inc"
>
I guess the missing # before include are not part of the issue, right ?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
No, that's not the problem - I just forgot them inside this demo scene.
The source of the error must be somewhere else.
---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 22/04/2018 à 07:47, Sven Littkowski a écrit :
> If you have a little bit time and experience at your hand, you can help
> me to find my error.
>
> When calling the texture macro directly from another file, it works. But
> when calling it from within the parameter liner of another macro, I get
> the error message you cans see as comment behind one of the lines. Why?
> Why? Why?
>
Macro call inside macro call...
I'm not sure the parser is expecting such thing, at least in its design
& specification.
Foo( Bar() )
The above line, I would avoid, and use instead
#local BarValue = Bar():
Foo( BarValue )
I'm not a big fan of meta-programming in SDL, so even if there could be
legitimate use cases of a macro invocation from within another macro, I
do not know which path should be followed to handle Foo( Bar() )
1. Bar() is evaluated and its value is used as the parameter (or rather,
the text of the parameter is replaced with the value of Bar() and parsed
every time the parameter is used inside the macro Foo.
2. Bar() is copied as the parameter, and parsed every time the parameter
is used inside the macro Foo.
when Bar() has side effect, it results in something different.
Such as
#declare BarCounter = 0;
#macro Bar()
#declare BarCounter = BarCounter+1;
BarCounter
#end
Should the parser become painful and more complex by forbidding such
macro in macro ? I'm not sure.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 22.04.2018 um 08:47 schrieb Le_Forgeron:
> Macro call inside macro call...
> I'm not sure the parser is expecting such thing, at least in its design
> & specification.
"What design & specification?"
> do not know which path should be followed to handle Foo( Bar() )
>
> 1. Bar() is evaluated and its value is used as the parameter (or rather,
> the text of the parameter is replaced with the value of Bar() and parsed
> every time the parameter is used inside the macro Foo.
>
> 2. Bar() is copied as the parameter, and parsed every time the parameter
> is used inside the macro Foo.
Whenever the tokenizer encounters an existing macro name `Bar` (except
in special contexts such as `#undef Bar`, `#define Bar` or `#macro
Bar`), it immediately invokes the macro, and effectively inserts the
"results" of the macro in-place. So for instance the following SDL code
is perfectly legitimate, as the apparent single parameter `Bar()`
actually happens to resolve to two parameters:
#macro Bar()
"4711", "42"
#end
#macro Foo(A,B)
#debug concat(A,"\n")
#debug concat(B,"\n")
#end
Foo(Bar())
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 22.04.2018 um 07:47 schrieb Sven Littkowski:
> When calling the texture macro directly from another file, it works. But
> when calling it from within the parameter liner of another macro, I get
> the error message you cans see as comment behind one of the lines. Why?
> Why? Why?
The parser is a bit old and creaky in the joints, and some of its
features may interfere in unexpected ways.
For instance, while parsing the parameter list of a macro invocation,
the parser doesn't like directives (`#if`, `#else`, `#break`, ...) after
a `texture{}` statement -- presumably as an unintended side effect of
the layered textures feature (`texture{} texture{}`).
A simple workaround is to first assign the result of the texture macro
to a temp variable, and then use that temp variable in the object macro
invocation.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
You mean, calling the texture macro at first before calling the object
macro, and saving the texture macro's result in a DECLARE, and using
that Declare inside the object macro?
---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymous org> wrote:
> The parser is a bit old and creaky in the joints, and some of its
> features may interfere in unexpected ways.
>
> For instance, while parsing the parameter list of a macro invocation,
> the parser doesn't like directives (`#if`, `#else`, `#break`, ...) after
> a `texture{}` statement -- presumably as an unintended side effect of
> the layered textures feature (`texture{} texture{}`).
>
> A simple workaround is to first assign the result of the texture macro
> to a temp variable, and then use that temp variable in the object macro
> invocation.
I would argue that the layered texture feature is defective by design. It is
pretty much the only case where two blocks of the same kind without any wrapper
have a special meaning. For other cases, namely with the addition of "material"
this has been fixed a long time ago. Maybe it is time to force something similar
for layered textures... at least outside scene objects.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 22.04.2018 um 16:04 schrieb Sven Littkowski:
> You mean, calling the texture macro at first before calling the object
> macro, and saving the texture macro's result in a DECLARE, and using
> that Declare inside the object macro?
I /think/ what you're trying to say is what I was trying to say, yes ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 22.04.2018 um 20:15 schrieb Thorsten Froehlich:
> I would argue that the layered texture feature is defective by design. It is
> pretty much the only case where two blocks of the same kind without any wrapper
> have a special meaning. For other cases, namely with the addition of "material"
> this has been fixed a long time ago. Maybe it is time to force something similar
> for layered textures... at least outside scene objects.
I do agree that the current syntax was a bad idea. I would even argue
that its use in a geometric object is also broken, because it assigns
different semantics to the `texture{}` statement in different
situations; for example, in the following code,
#declare O0 = sphere { ... }
#declare O1 = object { O0 texture { T1 } }
#declare O2 = object { O1 texture { T2 } }
the statement `texture{T2}` has the semantics "replace the object's
texture with T2", while in
#declare O0 = sphere { ... }
#declare O1 = object { O0 texture { T1 } texture { T2 } }
the statement `texture{T2}` has the semantics "layer T2 on top of the
object's current texture".
I guess a more reasonable syntax for creating layered textures would be:
texture {
layered
texture { ... }
texture { ... }
...
}
One problem however -- besides the need to maintain backward
compatibility for legacy scenes -- is that with all the additions and
changes that have been made since the introduction of the layered
texture feature, it's probably difficult to identify (a) which portions
of the parser code actually constitute the implementation of this
feature in its current form, and (b) which of these portions have by now
been co-opted by other features.
And then there is the limitation of being unable to layer patterned
textures on top of one another, which I find pretty... well, limiting.
But that has (almost) nothing to do with parsing, and instead is a
limitation of the current rendering engine implementation.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Thorsten Froehlich" <nomail@nomail> wrote:
> I would argue that the layered texture feature is defective by design. It is
> pretty much the only case where two blocks of the same kind without any wrapper
> have a special meaning.
I would agree.
Also, Sven, whenever you see something expected, another thing found instead,
then what you need to do is think about why POV-Ray is looking for, in this case
")". This is a very valuable general debugging skill that will serve you well
in the future.
I think _one_ simple fix could be for Sven to wrap the layered texture in a
material {} definition, and then call the macro before trying to invoke the
texture{} ---> material{}.
Then he can do something like
MyBrownSimpleQuoVadis(x) // "returns" a #declared CurrentMaterial
object {
PostsSideRailing
(0.725,0.30,0.60,4.50,0.65,1.5,0.02,-90.0,6.675,CurrentMaterial)
translate < -20.9, 0.0, 0.0 > }
I'm sure there are many more solution permutations.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The problem with layered textures and another texture on top of that, is
easy to bypass:
- creating a layered texture
- putting this layered texture on a declared (named) shape
- calling this object and applying now another texture to it
I believe, I did that a few times. Or something similar to this. Not the
perfect solution for all needs, but it works.
But what can be done about my real problem, the macro-macro situation?
Can any fix be done?
The suggestion to call first the texture macro and only afterwards the
object macro, would cause many, many, many more new code lines. If I can
avoid that, I would. Sounds like an urgent patch reason to me...
---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 23.04.2018 um 02:26 schrieb Sven Littkowski:
> But what can be done about my real problem, the macro-macro situation?
> Can any fix be done?
>
> The suggestion to call first the texture macro and only afterwards the
> object macro, would cause many, many, many more new code lines. If I can
> avoid that, I would. Sounds like an urgent patch reason to me...
Yes, actually there's a way: You can move the assignment to a variable
into the macro itself, essentially using the following construct:
#macro MyBrownSimpleQuoVadis(...)
...
#local Result =
#switch(...)
#case(1)
texture { ... }
texture { ... }
#break
...
#end
Result
#end
...
object {
PostsSideRailing(..., MyBrownSimpleQuoVadis(x))
... }
This way, the `texture{...} texture{...}` followed by `#break` doesn't
technically occur in the context of the `PostsSideRailing` macro
invocation, but rather in the context of a `#local` assignment, where it
doesn't lead to a problem. In the context of the `PostsSideRailing`
macro invocation, all that's visible is the `Return` variable
identifier, which also is unproblematic.
I guess I can't repeat this too often: When writing a macro to construct
an individual texture, object, pigment or what-have-you, it is very good
practice to first assign the thing to a local variable (which I tend to
call `Result`), and then have the macro "emit" just that variable itself.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
So, essentially what you're saying is, when writing a macro to construct
an individual texture, object, pigment or what-have-you, it is very good
practice to first assign the thing to a local variable (which I tend to
call `Result`), and then have the macro "emit" just that variable itself?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Sounds good! I will give a try. It is kinda new to me, I might need some
more practical help. But I am going ahead now and add the RESULT
variable, and will then find out how to use the RESULT variable inside
the object macro.
Thanks for this great advise.
---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 23.04.2018 um 18:50 schrieb Bald Eagle:
> So, essentially what you're saying is, when writing a macro to construct
> an individual texture, object, pigment or what-have-you, it is very good
> practice to first assign the thing to a local variable (which I tend to
> call `Result`), and then have the macro "emit" just that variable itself?
Yes, when writing a macro to construct an individual texture, object,
pigment or what-have-you, it is very good practice to first assign the
thing to a local variable, and then have the macro "emit" just that
variable itself.
:)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Yes, that new construct really works. Interesting.
Thanks, Clipka.
---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
>
> And then there is the limitation of being unable to layer patterned
> textures on top of one another, which I find pretty... well, limiting.
>
Yes!! ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Yes!
---
Diese E-Mail wurde von AVG auf Viren geprüft.
http://www.avg.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
