the “setSort” works perfectly for me,
thank all for helping me.
Setting the order is not important for many cases. I think that’s why there wasn’t an option for that.
This is something tricky that people may forget about easily. A FAQ or a page with a list of pitfalls to avoid may be a much more effective way to deal with this.
Added, but I don’t know if this is the correct place:
panda3d.org/manual/index.php/Known … imitations
But this might be even fixed (I hope) if Josh gets the time to look at my example more than once and notice that the second or third time he runs it he gets a different texture on the panda. 
By the way. It’s odd that it doesn’t happen if the node where I assign the stuff to doesn’t contain subnodes.
No, I’ve removed that “bug” from the bug page.
If you don’t specify any particular order for the textures, they’ll turn up in some arbitrary order. That’s not a bug. That’s logical.
The reason people thought it was a bug is because they assumed that textures are sorted sequentially according to the order in which you do your setTexture statements - or at least, that’s what I gather they assumed. But that’s just not right - they’re sorted according to their sort order number, not by the order in which they’re setTextured.
I was thinking that the sort is made by the priorities of the textures. ( little confusion with setSort )
Josh Yelon, i would say that both illogical and prone to error. I specify the order when i write them in code. 1,2,3 they both have orders by who gets inserted when. This way it creates more code and more possibility for error I know this bug since the beginning and it always bugged me but since i switched to the shader input system (thanks for providing it) it solved lots - i mean lots of headache with the odd texture stage system.
I understand the problem, and see that I’ve made wrong assumptions in the past.
However, I personally think it’s very illogical that the order of the textures sent to the shader can change every time the program is run if setSort() is not enabled.
I think they should be sorted default by the order they are added to the nodepath. I see no reason for this not to work out well for everybody.
Yeah, this worked in previous versions as well.
pro-rsoft, yeah it only worked for simple stuff. If you get to my complexity they where random then too.
There is some precedent for this: this is also the way that Panda handles sorting of children of nodes. For instance, if you specify node.reparentTo(newParent, 10), then it requests an explicit sort order of 10 among the other children of newParent. But if you omit this sort order (as one usually does), it means a sort order of 0, and all children with the same sort order end up being sorted in the order in which they were added. So it means that Panda has two mechanisms to control sort order among children of nodes: an explicit sort number, or the implicit order in which you added the children. If you never use the explicit sort, you get the implicit sort. If you use the explicit sort, it overrides the implicit sort.
This same dual-sort behavior is possible with the ordering of the TextureStages. It’s just kind of tricky, because of the complexity of the whole thing. We’re not just talking about a list of textures added to a NodePath; it’s actually the whole scene graph we have to order now. This is because textures inherit from above. So, if I do, for instance:
nodeA.setTexture(tsA, texA)
nodeB = nodeA.attachNewNode('B')
nodeB.setTexture(tsB, texB)Now nodeB has both stages tsA and tsB. Which one should be on top? Logically, it should be tsB, since I’ve applied that one last. But what about:
nodeB = nodeA.attachNewNode('B')
nodeB.setTexture(tsB, texB)
nodeA.setTexture(tsA, texA)Now which one is on top? I say it’s still tsB–I think the rule should be that lower-level nodes are always applied “on top of” parent nodes. But you could make a good argument that it should be the other way, since chronologically I’ve applied tsA last.
And what about:
nodeA.setTexture(tsA, texA)
nodeB = nodeA.attachNewNode('B')
nodeB.setTexture(tsB, texB)
nodeB.setTexture(tsA, texC)Now we’ve shadowed texA. nodeB has two textures visible: texB and texC, but texC is applied onto the same slot that used to hold texA. Does it inherit texA’s original position, or does it move to the end of the stacking order? I say it moves to the end, but again, you could make a case that it should preserve its original order.
But these are just nitpicky arguments. If your situation is this convoluted, you can use the explicit sort order to resolve any difficulties (provided you know that it is available). In the majority of cases, the naive programmer only wants to stack textures onto the same node, and he expects them to stack up in the order he has added them. Fine.
I’ll implement these rules, in the interest of making Panda as intuitive to use as possible. It involves some significant code changes, and might have unexpected side effects, so I don’t think it should be considered a bugfix for the 1.5.1 release. Let’s instead save it as a new feature for the later 1.6 release.
treeform, can you tell me more about your problems (2) and (3)? I’m not sure I fully understand the problems or your proposed solutions.
David
I’ve got a new problem that’s seem to be linked here.
The TextureStage.setSort() works really well.
But we’ve just changed all our computers.
On all but one, everything is fine.
On this one machine though, the setSort() is sorting by decreasing values instead of increasing ones.
how can that be possible ?
the hardware and code used are the same. So i can only imagine flawed hardware ( seams to work fine on other application ) or library version / config file
Is there a config file in Panda that can cause this ?
I’ve check my version panda3d. This one machine has panda3d 1.5.1 installed, ( other are still in 1.5.0 )
surely, this is caused by the texture implicit order ?
in the code, the textures are set in increasing priorities values:
tex1 = loader.loadTexture('tex1')
ts1 = TextureStage('tex1')
ts1.setSort(0)
tex2 = loader.loadTexture('tex2')
ts2 = TextureStage('tex1')
ts2.setSort(5)
tex3 = loader.loadTexture('tex1')
ts3 = TextureStage('tex1')
ts3.setSort(10)
tex4 = loader.loadTexture('tex1')
ts4 = TextureStage('tex1')
ts4.setSort(15)
[......]
node.setTexture(ts1, tex1, 0)
node.setTexture(ts2, tex2, 5)
node.setTexture(ts3, tex3, 10)
node.setTexture(ts4, tex4, 15)
[...]I’m not able to reproduce this. Textures are always sorted in increasing order by setSort(). It’s hard to imagine how it could do otherwise; there’s just a sort() call in Panda.
Note that the third parameter to setTexture() is a priority override, not a sort value, and has nothing to do with the sort order of textures. You should remove this parameter to reduce confusion.
I don’t know how your textures could possibly be sorting backwards, though. Are you absolutely sure that’s what’s happening?
David
Oops, I just got the repro. You’re absolutely right: it’s sorting exactly backwards in 1.5.1. And I see the stupid typo that caused it.
I’ll check in a fix pronto. My deepest apologies.
David
I just uploaded panda3d 1.5.2 - the ONLY change from 1.5.1 is that the TextureStage sort order should be fixed.