Possible improvement

[Chacal]

Take a look at this thread:
viewtopic.php?f=11&t=2650

Tikibear uses a manual workaround for a scaling difference between Blender and Plasma. Maybe this could be handled automatically by the exporter.

[GPNMilano]

This is one of the many reasons that I suggest to merge some of my changes to the Mat Classes, to get around issues like decals. On a single object they only require two plasma flags to be set in Blender, You have your buttom layer (the first texture in blender) that gets no flags than the top layer (which in Blender is the second texture) that gets the flags of kBlendAlpha and kZnoZWrite.

Neither of these work in the current implentation of blender without setting the flags for both layers. Which is why i took all the flags that were mapped to buttons in the materials section (that would set the flags for every layer on a material) and moved all individual flags to the Map Input section.

For a single object on top of another, like you get with lamp flares or decals that are on separate objects, you need three plasma flags (kBlendAlpha, kZnoZWrite and kMiscRestartPassHere). I mapped it so that flags can still be set for materials if its going to be a separate object (like a lamp sprite or separate object decal) and then you just need to make sure your passindexes are in the correct order (whatever gets drawn first gets a lower number. so if you have a wall, then a lamp,then the sprite it would go 0, 1, 2).

[Jojon]

@GPNMilano:

Oho... Sounds like stuff that might explanain why I just can not get the results I want, with any combinations of flags and passindices I try in my AP shell, least of all those that seem logical to me...

What can you say about the other thing tikibear said, about setting drawing order by parenting objects and then immediately deparenting them again? That stuff left me with the words: "Uuuuh? How, what, ghaa... where did that come from?" spinning in my head. :P

[GPNMilano]

Yeah, I have no clue where tikibear got that from. The draw order is controlled by the passindex. (Anything with a 0 goes into the main plDrawableSpans) while anything above gets sorted into a plDrawableSpans which is a special spans called a blend spans. These are arranged from 1 to whatever number you're last drawable is. The only thing that should go into a blend spans, is any layer with a texture that has alpha in the texture itself.

So if you look at it as sheets of paper layed out onto one another from top to bottom. The bottom layer is your regular objects (these are any objects with materials that don't have an alpha layer in their texture. It gets a passindex of 0, which is the default for all materials. Then objects that get drawn in front of all objects with a 0 gets a 1. All objects that are drawn infront of objects with a 1 get a 2 and so on and so on.

The only time this isn't the case is when you have a texture with an alpha layer thats getting overlayed over a layerwithout an alpha texture. In which case it can go into the main drawable spans.

[Nadnerb]

The parenting trick changes the order that the objects are stored in blender's internal arrays, and consequently, the order which they are written to the drawable spans during export, which in turn affects the order that those objects are drawn. (unless sorting is enabled on that DSpans group) I used the parenting trick to get things to render in the right order all the way back in pyprp 0.x, and it still works. Admittedly it is a weird hack, rather like a bug exploit for blender, but it works, and I don't know of any other way to change the draw order in blender itself. <.< (which doesn't do any sorting of it's own)

The reason the parenting trick works is that when an object is parented to another object, it becomes a child of that object, and is thus removed from the root object list. Then, when the object is de-parented, the child objects are appended back onto the end of the root object list. (not where they were originally taken from) Thus changing the list order, and as a side effect, the export order and the rendering order.

[Jojon]

Ok, would have thought Blender did some form of sorting, but apparently not. This use-order-of-appearence-in-Blender's-internal-list thing is only between objects with the same passindex, then?

[Nadnerb]

PassIndex has nothing to do with the real-time rendering order in blender. (which has no sorting) It is only applied during raytracing. (which doesn't need sorting) For raytracing, PassIndex separates the scene into different groups of objects which are rendered as separate images and then composited. PassIndex is used in the pyprp export to split the objects into different DrawableSpans groups, which may be rendered in order.

[Jojon]

PassIndex has nothing to do with the real-time rendering order in blender. (which has no sorting) It is only applied during raytracing. (which doesn't need sorting) For raytracing, PassIndex separates the scene into different groups of objects which are rendered as separate images and then composited. PassIndex is used in the pyprp export to split the objects into different DrawableSpans groups, which may be rendered in order.

Yes, it was PyPRP's use of it that I was concerned with, however unably I express myself. Hmm, so not only do we have "stuff" sorted into these "drawable spans", but the spans themselves are grouped somehow... *steadies head with both hands and tries not to think of it all -- no doubt it'll make sense even to me one day* :7