Waveset drawing itself in front of object

[ardent red]

There's an area in my age where the player is in a glass dome underneath a waveset, and it's having a few problems. The waveset renders in front of the dome, but behind objects inside the dome- I want it to render behind both the dome and the objects in the dome. The dome has ztransp enabled, could this be contributing to the problem?

Cheers

[ardent red]

Anyone have a solution? This is really bugging me. Here's a screenshot of what I mean:


I've been playing around with the passindex numbers, which seem to be important from what I've read, but no matter what I set them to the waveset still appears over the glass.

[Nadnerb]

I have no idea what that picture is depicting, but it looks shiny.

[ardent red]

lol, it is indeed. Do you have any ideas on how to make the shiny appear behind the non-shiny? (I know, I know- why would I want to make the shiny go away? You can't have too much of a good thing, right ?)

[Jojon]

Well, from what people have been saying in the past, it kind of seems that whenever wavesets are involved, any system we've been thinking ouselves perceiving, is out. :P

I suppose you have been playing around with the Ztransp button highlighted also for the waveset's material?

[ardent red]

Sure have. The problem isn't effected by any setting of ztransp on the waveset- wether the waveset zoffs (which I assume are only enabled when ztransp is pressed) is lower or higher than the dome's zoffs has no effect at all.

[Jojon]

ZOffs *USED* to fill the very function that PassIndex does today, but on a per material basis, as opposed to per object, as it is now. Today it sets a flag, if set to any other value than zero.

*digging up an old post by GPNMilano*

ok..:

ZTransp sets a flag named "kznowrite"
ZOff sets a flag names "kzinclayer"

..so judging by their names, I guess the former makes us not write an entry (if there is such a thing, dunno how'tworks :7) to the Zbuffer and the latter bumps an overlay index of some kind, assumedly putting either us on top, or whatever comes next. These guys are good for making overlapping meshes not duke it out over who gets to get rendered, apparently. :P

People seem to have less problems using only the first one and leaving the second one alone...


There was also a mention about trying setting the "hard" option in the (material) mapto tab, which apparently sets another couple of flags: "kmiscindexnext" and "kmiscrestartpasshere"...

Seems to be a lot of these flag thinges... "Black" and "White" sounds very interesting - a single button to make a material that's just plain black, under any circumstances, probably quickly rendered too, could have its uses. :7

[GPNMilano]

Just to be clear. Z-Transp sets a flag known as ZNoZWrite. This flags is used mostly for blending of materials. So, if you have an object with two or more layers, your first layer gets no special flags, your second layer would get the kBlendAlpha (which is automatic if you have more than one vertex color, and one of them is named Col. Which IMO is just a stupid way to do it as it then sets EVERY layer on that object to have a KBlendAlpha flag) and it would get the ZnoZWrite flag (Same as the above reason why its stupid) It doesn't blend the materials all that well when you have multiple layers and they're all getting the exact same flags.

One of the reasons I advocate using my mat_classes for the next PyPRP release. People will have to adjust a few settings in their current ages, but blending, transparencies, will be ALOT easier to do with alot less headaches.

[Jojon]

Thanks for that, Chloe.

Many might disagree, since it adds complexity, that many many of us are likely to trip over (..and then go bother devs about), but it seems that it would probably be best, if the user could get full explicit access to all the flags and friendly descriptions on what they do, rather than having things happen in automagic, hidden ways. :7


EDIT: Here's hoping the touted Blender custom interface API will include tooltips...

[Paradox]

Flags can be set on objects individually through AlcScript to give greater control over the DrawableSpans. Unfortunately in the current release, everything must be done in hexadecimal, but you can grab my edited DrawClasses.py file here to set the flags by name.

Firstly, all Spans have a RenderLevel. This applies to all of the objects in that span. The RenderLevel has a Major and a Minor component.

Code: Select all

0 = opaque
1 = fb
2 = defrend
4 = blend
8 = late

All default spans have a render level of (Major = opaque; minor = opaque).

If an object has any sort of transparency, it must be exported in a BlendSpan, which has a render level of (M=defrend;m=opaque). Your can force objects to be exported in a BlendSpan using the TRANSP button in the Object Properties.

Wavesets are always automatically exported with a render level of (M=late;m=opaque).


You can control these in AlcScript using the visual.renderlevel.major and visual.renderlevel.minor properties.

Code: Select all

[ObjectName]:
    visual:
        renderlevel:
            major:
              - blend
            minor:
              - opaque

Uru seems to render the spans in a specific order, sorting them first by the major renderlevel in increasing order, and then within that order by minor level in increasing order, and finally by the suffix number at the end of the span (controlled by the PassIndex setting).

Hence, if you have 5 DrawableSpans with various settings they would be rendered as follows:

Code: Select all

#1 M=Opaque    m=Opaque    Spans0    (0 0 0)
#2 M=Opaque    m=Opaque    Spans1    (0 0 1)
#3 M=Opaque    m=Blend     Spans0    (0 4 0)
#4 M=DefRend   m=Opaque    Spans0    (2 0 0)
#5 M=Late      m=Opaque    Spans0    (8 0 0)