I’m finally upgrading to panda 1.5 ! ( in fact i was still in panda 1.32 !! )
but i have a problem.
now my terrain have a strange behavior. it doesn’t seems to use my shader ( no shader compilation error ) and just display one of his textures, randomly ( always the same for the same heightfield )
I’m also getting really odd behavior of my shaders (each time I run my game the texturing on my terrain looks different)
It seems to be grabbing a random texture each time indeed. Maybe this has to do with texture ordering? I really hope this could be fixed soon, I was planned to release a techdemo of my game this week but now it is delayed.
Haha, I first thought it was my terrain class which did it all wrong… I totally rewrote it from scratch but the problem still occurs…
EDIT: Treeform pointed me on the IRC to the fact that I had to set the texture priorities, but that still didn’t work…
I’ve experienced this too… Was going to post it but I wanted to isolate the error first.
I’m was using PGMM in 1.5 but didn’t have time to debug it so I went back to 1.4.2 and didn’t think about it more.
I’m not 100% sure what was happening but it seemed like the order of the textures for shaders was getting mixed up.
Nodepaths were even getting textures they weren’t suppoed to use, for example ocean was receiving my terrain textures, etc.
A temporary solution which might actually work:
instead of just doing setTexture, assign your textures using the shader inputs, and access them using k_texname. Of course, this is just a hacky solution, and I’d really like to have this fixed soon.
Treeform suggested on IRC I’d also do setSort on my TextureStages apart from just the texture priorities, and everything works now! Yay! Looks like the old again!
I really don’t like how the texture stage system works and resorted to always setting shader inputs precisely for weirdness like this:
1 random ordering ( fixed with setOrder )
fix: each texture stage gets added with priority lower (last index +1) then the one before it.
2 parent texture bleeds into the children:
fix: when adding a new texture stage check if there is a texture stage with that name already then replace it instead of just adding
3 model with texture metal and metal bump has text attach to it but the metal bump (being second texture) bleeds into the TextNode as second texture so you get both characters and metal bump rendered:
fix: add ability to specify “null” texture that would turn off that texture stage.
Then why bother fixing the texture stage system when the setShader input works great? I hacked my nodepath and setTexture use set shader inputs so i never see it causing problems any more
Using the system that was causes one problem - egg files. Can we get shader inputs instructions into the egg files and I guess load shader itself? - that will be great
Here’s example code.
Note that it does work when i supply the textures directly to the pandaActor.
Python file:
from direct.directbase import DirectStart
from pandac.PandaModules import TextureStage
from direct.actor import Actor
dummy=render.attachNewNode('tmpnode')
#Load the panda actor, and loop its animation
pandaActor = Actor.Actor("models/panda-model",{"walk":"models/panda-walk4"})
pandaActor.setScale(0.005,0.005,0.005)
pandaActor.reparentTo(dummy)
pandaActor.loop("walk")
#set the second and third texture
dummy.setTexture(TextureStage("blah"), loader.loadTexture("maps/noise.rgb"), 20)
dummy.setTexture(TextureStage("werh"), loader.loadTexture("maps/envir-treetrunk.jpg"), 30)
pandaActor.setShader(loader.loadShader("test.sha"))
run()
pro-rsoft: when this renders on my computer, I see a bear that looks sort of brown and swirly. As far as I can tell, this is correct behavior given the code.
The code is nondeterministic - the TextureStages all have the same sort order, which means that the system is allowed to apply them in any order. Therefore, tex_0, tex_1, tex_2 will be the three textures, but in no predictable order.
Is this what you’re seeing (ie, a brown swirly bear?)
That might be… However, in Panda 1.4.2 it’s been deterministic… Textures were always sent to the shader in the order they are assigned to the node, even if no sorting is done.
It was never intended to be deterministic. Actually, as it happens, it used to be very nearly deterministic, especially for simple scenes where the same textures always appeared together always in the same context. But it’s important to remember that this previous apparently-deterministic behavior was just accidental.
It was in the edge conditions of this old behavior that was causing some other, more serious problems with graphics state confusion. We fixed these problems recently, and one (also accidental) side-effect of the fix is that the texture order is now more likely to be obviously random.
We haven’t technically changed the API, though; we just made some indeterminate code more obvious. We never noticed the change here, because we didn’t have any code that triggered it.
It could be argued that it would be desirable to support some deterministic sorting in the absence of an explicit texture order, and I’d be inclined to agree. However, it’s not at all clear how this would be implemented. Which texture would come first when you have texture A on a parent node and textures B and C together on the same child node?
Note that RenderAttrib priorities have nothing to do with texture sorting order. Texture sorting order is entirely controlled via TextureStage.setSort(), as described in the manual.
I think the problem is that bjarnia didn’t know about the sort-order field in the TextureStage. Not knowing about sort-order numbers, he made a reasonable but incorrect assumption about how TextureStages were sorted.
May I make a suggestion? Perhaps we should add an explicit nonoptional sort-order parameter to the TextureStage constructor.