I just tried HEAD branch, and I noticed that getSoundPath is no longer exist, as well as sound-path config var. It seems it’s now integrated into model-path, is it true ?
Yes, in fact, it’s been integrated with model-path for years and therefore a separate sound-path variable has been redundant this whole time. I recently removed the redundancy.
Good news, thanks.
I just got another issue :
IDE_cleanupMessenger.accept('killAllCameras',self,killCam,[self]) File "linuxroot/usr/share/panda3d/direct/src/showbase/Messenger.py", line 99, in accept File "linuxroot/usr/share/panda3d/direct/src/showbase/Messenger.py", line 52, in _getMessengerId AttributeError : 'libpanda.Camera' object has no attribute '_messengerId'
So, a camera now unable to accept event.
Huh? Is an IDE_cleanupmessenger object a Camera object? Certainly a Camera cannot accept an event; I don’t see how it ever could have, since it doesn’t inherit from DirectObject.
Did this really work previously?
Yes, it used to work up to v1.5.3.
No, it’s not a camera, but a messenger. I just noticed that AnimControl also has the same trouble.
I set it up this way :
IDE_cleanupMessenger=Messenger() # I want to remove all RTT upon update, so I need an easy way to tell # all cameras to remove theirselves and their output def killCam(self): camNP=NodePath(self) if not self in defaultP3DCameraNodes and \ camNP.getParent()!=IDE_CC_descParent and \ self.getName()!='closeup vpcam' and self.getNumDisplayRegions(): Goutput=self.getDisplayRegion(0).getWindow() Goutput.clearRenderTextures() Goutput.removeAllDisplayRegions() Goutput.getGsg().getEngine().removeWindow(Goutput) camNP.removeNode() def newsetLens(self,lens): IDE_cleanupMessenger.accept('killAllCameras',self,killCam,[self]) self.__origsetLens(lens) newsetLens.__doc__=Camera.setLens.__doc__ # transfers docstring Camera.DtoolClassDict['__origsetLens']=Camera.setLens Dtool_funcToMethod(newsetLens,Camera,'setLens') del newsetLens
You really like to push the envelope, don’t you?
The docstring for Messenger.accept() begins with the line:
Which is to say, the second parameter has always been defined to receive a DirectObject only; it has never been intended to be used with any other kind of object. As it happens, it appears that in the 1.5 branch and earlier, it worked even though you gave it an object that does not inherit from DirectObject. But this was just by luck, not by design; and now your luck has turned and it no longer happens to work that way.
Although I can see that it might be a useful feature to allow any object to receive messages, this wasn’t in the design of the Messenger system. Surely you could solve the same problem a different way, using the Messenger system the way it was intended?
Oh, why didn’t I check that ?
I’ll get another way around.
I just hit another issue, it’s RTT now.
Running this code brought the framerate from 100 down to 1 fps :
# render to texture initialization base.win.addRenderTexture(Texture(),mode=GraphicsOutput.RTMCopyTexture) # render the next frame base.graphicsEngine.renderFrame() # get the card covering the whole screen card=base.win.getTextureCard() card.reparentTo(render2d) card.setTransparency(1) # stop render-to-texture base.win.clearRenderTextures()
The funny thing is the motion trails and glow filter samples are working well. But cartoon shader sample is not.
And prepareScene() is still giving me more chugs than using temporary OmniBoundingVolume.
Rats. I’ll have to investigate both of these. Are you running on Windows or Linux?
Also, I noticed when using RTT to a card, somehow the coordinates are not right or so, it looks like the fullscreen card is somehow shifted or so. Run either the simple or advanced cartoon shader, both give these issues on the 1.6 branch. Did you guys change anything related to that?
Not to my knowledge, at least not intentionally. That sounds pretty odd.
It’s on Linux. I haven’t tried it on Windows. I’m running out of free space and haven’t backed up my stuff. Building on Linux requires less space, so I did it on Linux.
getTextureCard()'s texture is the problem. Its draw call took 980+ ms.
When I only used its makeCopy() texture, nothing changed. But if I create a brand new texture out of it, it’s Ok :
cardTex=IDE_sceneCapture.getTexture() ox,oy=cardTex.getXSize(),cardTex.getYSize() p2x,p2y=math.log(ox,2),math.log(oy,2) notP2X,notP2Y=math.modf(p2x)!=.0, math.modf(p2y)!=.0 # print 'ox,oy:',ox,oy, x,y=2**int(notP2X+p2x), 2**int(notP2Y+p2y) # print 'x,y:',x,y oimg=PNMImage() cardTex.store(oimg) newImg=PNMImage(x,y) newImg.copySubImage(oimg,0,y-oy,0,0) newTex=Texture() newTex.load(newImg) IDE_sceneCapture.setTexture(newTex)
I found an annoying issue of TaskManager.run.
Somehow, when an exception occurs, the raise command here yields nothing :
if self.extendedExceptions: self.stop() print_exc_plus() else: if (ExceptionVarDump.wantVariableDump and ExceptionVarDump.dumpOnExceptionInit): ExceptionVarDump._varDump__print(e) raise # doesn't work
So, I have to print the traceback to give a clue :
if (ExceptionVarDump.wantVariableDump and ExceptionVarDump.dumpOnExceptionInit): ExceptionVarDump._varDump__print(e) import traceback traceback.print_exc() raise # doesn't work
Actually, I found the new exception printing rather annoying. Sometimes it can be helpful, but it just dumps too much info to the console. Is is possible to turn it off?