Bugs in 1.6.0cvs, not in 1.5.4

Scripting Issues
#1

I’ve been encountering some weird bugs that only occur in the 1.6.0 cvs trunk and not in 1.5.4. They have been annoying me for weeks now and I so far failed to solve them myself.

First bug: texture stages are limited to 4, even with shaders
(1) My card only supports 4 texture stages (GeForce 8600M). However, I can use more than 4 stages when I use a shader. Not anymore, the fifth texture is black in 1.6.0, while it does show up fine in 1.5.4:
(the shader is made to just display the fifth texture)

from pandac.PandaModules import *
import direct.directbase.DirectStart
cm = CardMaker("blah")
cm.setFrame(-1, 1, -1, 1)
b = render2d.attachNewNode(cm.generate())

#TEXUNIT0
b.setTexture(loader.loadTexture("maps/panda-model.jpg"))
ts = TextureStage("blah")
ts.setSort(10)
#TEXUNIT1
b.setTexture(ts, loader.loadTexture("maps/panda_hat.rgb"))
ts = TextureStage("ahah")
ts.setSort(20)
#TEXUNIT2
b.setTexture(ts, loader.loadTexture("maps/panda_head.rgb"))
ts = TextureStage("werwer")
ts.setSort(30)
#TEXUNIT3
b.setTexture(ts, loader.loadTexture("maps/panda_viser.rgb"))
ts = TextureStage("blamama")
ts.setSort(40)
#TEXUNIT4
b.setTexture(ts, loader.loadTexture("maps/envir-treetrunk.jpg"))

b.setShader(Shader.make("""//Cg
void vshader(out float4 l_position : POSITION,float4 vtx_position : POSITION,
uniform float4x4 mat_modelproj,
float2 vtx_texcoord0 : TEXCOORD0,
out float2 l_texcoord0 : TEXCOORD0) {
l_position=mul(mat_modelproj, vtx_position);
l_texcoord0=vtx_texcoord0;
}
void fshader(out float4 o_color : COLOR,
uniform sampler2D tex_4 : TEXUNIT4,
float2 l_texcoord0 : TEXCOORD0) {
o_color = f4tex2D(tex_4, l_texcoord0);
}"""))
run()

Second bug: buffer card texture is scaled wrongly
(2+3) Try running samples/Cartoon-Shader/Tut-Cartoon-Advanced.py in 1.6.0 – there are two problems. (2) the onscreen card is scaled and (3) the vertex colors have disappeared.
If I turn off automatic texture scaling (with textures-power-2 none) it works fine. In 1.5.4 it worked fine, too, even without ‘textures-power-2 none’.
It’s not just the Cartoon Shader sample, but everything that uses buffers (or the FilterManager)

Version 1.5.4, default configuration

Version 1.6.0, default configuration

Version 1.6.0, with ‘textures-power-2 none’

#2

and it’s still 0 fps :open_mouth: ?

#3

No, I just called renderFrame twice and then base.screenshot instead of run(), so the frame rate meter didn’t even get the chance to update.

#4

Hmm, these look troublesome. I can look into them sometime next week maybe, but this weekend I’m swamped with our Pirates release.

David

#5

Do you maybe have time to look at it this week? I don’t mean to steal your time but I really think we should get 1.6 out the door soon.

#6

Yeah, I’ll see what I can do. :slight_smile:

David

#7

All three problems appear to be fixed now. I fixed the texture-count issue and rescaling issue, but I didn’t actually do anything specifically to fix the vertex color problem–that was already working by the time I got to look at it. Maybe that had already been fixed.

David

#8

Excellent, thanks! You’re the best :slight_smile:

I noticed however that the vertex colors still don’t show up, in the Tut-Cartoon-Advanced.py. Weird…

#9

Hmm, they do for me. Wonder what’s different between us? Are you running this on Linux? Does it work on other platforms?

David

#10

CVS build (just now) using ppremake, 64-bits linux, Tut-Cartoon-Advanced.py from the samples (which haven’t been modified since 1.5.4). I don’t have the chance to test other platforms right now.

(PS. On a sidenote: I’ll be leaving the country tomorrow for a week and I don’t know if I’ll be reachable.)

#11

confirming buffer-scale-bug on ubuntu32bit.nvidia card.

#12

Well, sure, but did you try with a build made since I fixed it this morning?

The only outstanding bug seems to be the lack of vertex color in this sample, on pro-rsoft’s machine for some reason.

David

#13

ah not yet. i’ll try as soon as i have time for it. having 3 birthday’s to celebrate in the next 48hours so dont rely on me too much.

#14

The task manager issue mention in HERE is still there.

#15

I find that exceptions are being raised and caught properly. I am annoyed by the extra-verbose traceback printing, but it is at least catching my exceptions. Can you show me some sample code that demonstrates a failure?

David

#16

I am pretty sure there is an error in that verbose stack printing thing. It goes into infinite loop if there is an error in the except part of the try: except statement. I think it got to do with stack trace being printed over and over. Can we just have the old behavior back?

#17

No, sorry, you can’t have the old behavior back. :wink: But I do want to fix the new behavior. Can you show me exactly what you mean?

David

#18

i tried to repro it on a simple case and cant.

#19

It’s of course an error inside a task :

import direct.directbase.DirectStart

def myTask(t):
    print "this is it :"
    im_not_defined
    print "this is NOT printed"

taskMgr.add(myTask, '')
run()
#20

Still not seeing it. With the above code exactly as entered, I get an assertion error (correctly) because the task has no name. But when I correct that bug, I get the following exception:

this is it :
Traceback (most recent call last):
  File "taskerror.py", line 5, in myTask
    im_not_defined
NameError: global name 'im_not_defined' is not defined
:task(error): Exception occurred in PythonTask t
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "taskerror.py", line 9, in ?
    run()
  File "/home/drose/player/direct/src/showbase/ShowBase.py", line 2351, in run
    self.taskMgr.run()
  File "/home/drose/player/direct/src/task/TaskNew.py", line 471, in run
    self.step()
  File "/home/drose/player/direct/src/task/TaskNew.py", line 429, in step
    self.mgr.poll()
  File "taskerror.py", line 5, in myTask
    im_not_defined
NameError: global name 'im_not_defined' is not defined
>>>

Now, I’ll grant you that it’s annoying that it printed the traceback twice, and I’m happy to fix that nuisance. But I’m not seeing the described problem, of the exception not getting reported at all.

David