"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