Miscellaneous problems with 1.9 (dev)

1. Missing cursor in DirectEntry
There used to be a cursor in the DirectEntry widget, it looked like this “|”, now it’s gone.
Sample code:

from panda3d.core import *
from direct.gui.DirectGui import *
from direct.showbase import ShowBase

def _pos2d(x,y):
    return Point3(x,0,-y)
def _rec2d(width, height):
    return (-width, 0, 0, height)
def _resetPivot(frame):
    frame.setPos(-size[0], 0, -size[3])        
base = ShowBase.ShowBase()
font = DGG.getDefaultFont()
entry=DirectEntry( frameSize=_rec2d(250,30),
                   frameColor=(1,1,1, 0.3),
                   text = "This is a test",
                   initialText="This is a test",
                   numLines = 1,


2. p3d_ModelViewMatrix - third column or something(?)
This one’s a bit strange - I have a shader that strips the rotation from the model view matrix so that a model (plane) is always facing the camera. The code for the shader is from Geeks3D and it worked on 1.8 with 1.9 it only works on one axis
Sample code:
[in attachment softparticle.zip]

3. Bullet rope rebels.
I’ve used a box dangling on a rope to simulate cloth and hair movement for a character, it worked for 1.8 but on 1.9 the box is removed or shoots into space - to be honest I don’t really know what’s happening it just won’t work - could be I did something wrong in my code (I’m no good with bullet), all the bullet-samples work - just sayin’ it worked on 1.8 it works not on 1.9. Using a BulletDebugNode I get this

Sample code:
github.com/wezu/cloth_sim the cloth_gpu.py file is the one that bugs out.
softparticle.zip (560 KB)

Thanks for reporting issues with 1.9! I really appreciate it when people do this kind of testing.

  1. That’s, er, odd. I’ll have to look into it.

  2. I changed p3d_ModelViewMatrix because it was bugged in 1.8; it was reporting in the wrong coordinate system compared to gl_ModelViewMatrix, and I really wanted to keep compatibility. Note that you get the same distorted result when you substitute gl_ModelViewMatrix and gl_Projection.

Tweaking the calculation slightly yields a better looking result:

    // First column.
    modelView[0][0] = 1.0;
    modelView[0][1] = 0.0;
    modelView[0][2] = 0.0;
    // Second column.
    modelView[1][0] = 0.0;
    modelView[1][1] = 1.0;
    modelView[1][2] = 0.0;
    // Third column.
    modelView[2][0] = 0.0;
    modelView[2][1] = 0.0;
    modelView[2][2] = 1.0;

(I’m not sure if it matters, but either of those last two 1.0’s might need a - in front.)
There is something to be said for reverting the matrices to Panda3D’s coordinate system rather than OpenGL’s, but that would have to be done with a configuration variable toggle.

  1. I’m not sure. We probably use a different build of Bullet. Maybe it’s that we’re using one with error checks that were not there in the other version?

I’m not sure if I understand what happened to the p3d_ModelViewMatrix (not important), doing try and error I ended up with:

modelView[2][0] = 0.0; 
modelView[2][1] = 1.0; 
modelView[2][2] = 0.0; 

Now I’m wondering if I should use two shaders for two versions of p3d, but since I don’t know how to check the panda version and there’s too much fun stuff in 1.9 I’ll just use what works on 1.9.

There’s one more thing that I bumped into, but I’m not sure about it… Didn’t 1.8 ship with wxPython?
I’d try to run Demomaster on 1.9 (theres a cg vtf water shader that I wanted to test) and it complained about missing wx.

No, we don’t ship with wxPython. You can just download it from the wxPython web site and install it into Panda’s copy of Python, provided the Python version and architecture match.

Ok, right, must be a bug in my memory then.

But I’ve got another one - sRGB textures.

the new manual page says I can use something like this:

normalMap = loader.loadTexture("texture-normal.png", colorSpace=CS_linear)

But python complains the he doesn’t know what CS_linear is (NameError: global name ‘CS_linear’ is not defined) nor know nothing about an argument named colorSpace (TypeError: loadTexture() got an unexpected keyword argument ‘colorSpace’)

The top of said manual page says:

I haven’t nailed down the best interface for this yet, and until I do, I didn’t want to check in anything I might regret. So the high-level interface hasn’t been checked in yet, but the low-level support is there.

(What I want to make sure is that I create an interface that fully automates the process and makes it difficult for people to accidentally get one side of the equation wrong.)

For now, you can mark your color textures as sRGB after loading:

diffusetex = loader.loadTexture("texture-albedo.png")

(Or F_srgb_alpha for textures that also have a (linear) alpha channel.)

Although the details are still subject to change.

It was a culling issue - draw masks weren’t propagated properly for nodes that were initially hidden and had no culling performed on them. If you had passed focus=1 it would have worked.

Checked in a fix. Thanks for reporting!
github.com/panda3d/panda3d/comm … e098b6b97f

I bumped into some more problems.

On Windows 8.1 with a Intel HD (I think it was 3000) when I set ‘framebuffer-srgb true’ it crashed python. Google say intel hd can’t do srgb, so it would be nice if panda could detect that a gpu can’t do srgb and turn it off or exit without crashing.

Again on W8 but running a AMD R5 gpu when closing a window with the ‘x’ it crashes every time (the script was the demo from my editor).

It wasn’t my computer and I only had the 32bit build ninth made for me, so I have no more details on these bugs.

PandAI will in some scenarios bug out on AIworld.update(). I can’t yet tell when this happens and I didn’t write down the exact error msg. My bad.

I’ll write more on all of this if I can get anything useful. Just hinting that there can by something wrong.

Intel HD 3000 cards most definitely support sRGB framebuffers, as any remotely reasonable card in existence does. I strongly suspect a driver bug.

Can you try and isolate the window-close bug to a minimal test case? Does pview exhibit the same behaviour?

Right, the Intel HD do claim to support ogl 4.+, so sRGB should be on the list, it may be a driver bug, but some people don’t even know that they can install new drivers and use the pre-installed drivers forever.

Just saying it would be nice if p3d could detect a problem like this and throw an exception or something, not ‘explode’. I understand that it may be too late to do anything once the error occurres, but I really don’t know how these things work, so I’m asking just in case it’s something easy to do (it has been the case in the past).

I’ve got my demo cut into pieces so I should be able to tell what part crashes on exit… if only I can get my hands on that laptop again… this may take a week.

sRGB framebuffers are part of core OpenGL since 3.0, but have been around as an extension for far longer.

The problem is that, or so I presume, Panda3D isn’t crashing, but the driver is. We can’t recover from a driver crash. The only thing we can do is try and find out if we can somehow subtly change when we make each call to try and coax the driver into obedience. But one needs a failing computer to experiment on for that.

I can’t reproduce the bug I had with the crash on exit, I feel really silly now :blush:

Here we go again.

I have a problem with integer shader inputs.
On my ATI, windows XP machine, if I try to pass an int to a glsl shader I get spamed with this message:

:display:gsg:glgsg(error): at 2945 of e:\panda3d-master\panda\src\glstuff\glGraphicsStateGuardian_src.cxx : invalid operation
:display:gsg:glgsg(error): An OpenGL error (invalid operation) has occurred.  Set gl-check-errors #t in your PRC file to display more information.

If I do set gl-check-errors #t I get this:

:display:gsg:glgsg(error): at 1089 of e:\panda3d-master\panda\src\glstuff\glShaderContext_src.cxx : invalid operation
:display(error): Deactivating wglGraphicsStateGuardian.

…and at that point the program stops.

Could you re-test with this build?
buildbot.panda3d.org/downloads/8 … 790a2bacd/

Sure, I’ll do that tomorrow.

I’ve used the build labeled ‘1.9.0-8344fc6’ and I’m afraid it didn’t change much, just the number of the line:

:display:gsg:glgsg(error): at 1097 of c:\buildslave\test_sdk_win_i386\build\pand
a\src\glstuff\glShaderContext_src.cxx : invalid operation

OK, the type matching of parameters has now been vastly improved. It should either give an error message or convert to the right type automatically if possible.
buildbot.panda3d.org/downloads/b … d0380ce17/

I think that did it. No errors now. Good job.

Great! :slight_smile:

FYI I just checked in support for the “gl-coordinate-system” variable, which is set to “yup-right” by default, but can be changed to “default” (usually equivalent to “zup-right”) in order to make the matrices behave more consistently. It may make certain fairly esoteric fixed-function pipeline operations (like sphere mapping) work improperly, though, but this should be fine if you are developing a shader-based application.