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