Hello,
I'm having a problem involving Balloon3D; I'm a relative newcomer to using squeak, and I'm not sure if its the system, or my assumptions!
Background: I want to do some experiments with 3D interactions, and so I started exploring the Balloon3D and Wonderland implementations to try and understand the protocol needed to build and render 3D objects. I set up what seemed like a simple test to render a cone, using the classes B3DSceneMorph and B3DBox as models. The result was that squeak crashed with a segmentation fault!
Using the debugger, I narrowed the problem down to the message primAddObject invoked on self in B3DPrimitiveRasterizer>>addPrimitiveObject:ofSize: I wanted to understand what the parameters to this method _should_ look like (so I could compare with what was being passed through from my code). B3DSceneMorph seems to work okay, so I edited addPrimitiveObject:ofSize: and added `self halt' at the start of the method, after the temporary variables are defined. I then ran `B3DSceneMorph new openInWorld' from the transcript, with the hope of getting a debugger that would let me explore the objects were being used in rendering the B3DBox used in the demo.
Now the problem: I get not one, but two debugger windows opening, neither of which will respond to user input. In fact, the entire squeak application seems to lock up.
Any comments on the problem invoking the debugger would be appreciated. I've been using the 3.2gamma image, change set 4881. I've had the same problem with 3.1beta and 3.2gamma4 images, all running under linux.
Also, if someone who is familiar with Balloon3D has a moment to look at the two attached classes, I would appreciate any comments on what I'm doing (or rather failing to do) in these. Any pointers to other examples and/or documentation on Balloon3D would be helpful.
thanks, David
Hi David,
On Tue, Jul 02, 2002 at 03:04:27PM +0100, David Duke wrote:
Now the problem: I get not one, but two debugger windows opening, neither of which will respond to user input. In fact, the entire squeak application seems to lock up.
That's probably because it's trying to open a new debugger each time the B3DSceneMorph is redrawn, and the system grinds to a halt from the effort. Instead of opening the B3DSceneMorph in the world, create an instance in a workspace, but don't open it ('b3d _ B3DSceneMorph new'). You can then tell it to draw itself once with 'b3d debugDraw', which will allow you to halt and step through the code.
Joshua
Joshua 'Schwa' Gargus wrote:
On Tue, Jul 02, 2002 at 03:04:27PM +0100, David Duke wrote:
Now the problem: I get not one, but two debugger windows opening, neither of which will respond to user input. In fact, the entire squeak application seems to lock up.
That's probably because it's trying to open a new debugger each time the B3DSceneMorph is redrawn, and the system grinds to a halt from the effort. Instead of opening the B3DSceneMorph in the world, create an instance in a workspace, but don't open it ('b3d _ B3DSceneMorph new'). You can then tell it to draw itself once with 'b3d debugDraw', which will allow you to halt and step through the code.
Hi Joshua,
Many thanks for your help -- it hadn't occurred to me that the redraws would be triggered repeatedly even with the debugger active.
I noticed that the geometry I included for the cone (specifically, the vertex indices in the Faces array) was incorrect; I may have forgotten to save the image at some point while changing the vertex numbering. In case anyone is looking at it, an updated version is attached.
I'm still having the segmentation fault; although I can now at least look more closely at what is going on, I would still be grateful for any suggestions.
David.
David Duke wrote:
I'm still having the segmentation fault; although I can now at least look more closely at what is going on, I would still be grateful for any suggestions.
I filed in your B3DCone class and changed one line in B3DSceneMorph>>createDefaultScene | sceneObj camera | sceneObj _ B3DSceneObject named: 'Sample Cube'. sceneObj geometry: (B3DCone radius: 1.0 height: 2.0). camera _ B3DCamera new. camera position: 0@0@-1.5. self extent: 100@100. scene _ B3DScene new. scene defaultCamera: camera. scene objects add: sceneObj.
This gave me a very strange looking 3d object, but no segment fault.
This was on a macintosh in squeak 3.2
Karl
Karl Ramberg wrote:
I filed in your B3DCone class and changed one line in B3DSceneMorph>>createDefaultScene
Thanks for looking at it. If you took the first version of B3DCone that I posted, it would explain the strange shape.
I'm now in the following situation:
- If I start squeak, then immediately run B3DSceneMorph, with B3DCone as the geometry in place of B3DBox (see below), I get a segmentation violation;
- If I start squeak, run B3DSceneMorph with B3DBox as the geometry, THEN edit B3DSceneMorph, changing the geometry to be B3DCone, the cone is rendered fine.
The change, to B3DSceneMorph>>createDefaultScene, is to replace the line
sceneObj geometry: (B3DBox from: (-0.7@-0.7@-0.7) to: (0.7@0.7@0.7).
to
sceneObj geometry: (B3DCone radius: 1.0 height: 1.0).
It seems as if something that is initialized by B3DBox is not being initialized by B3DCone. However I've gone through the two classes several times (and there are, after all, only 3 instance methods and 2 class methods in each), and can't locate any significant difference. In my earlier version of B3DCone I did not specify texCoords for vertices -- it isn't clear whether they are required by the renderer. I did updated the B3DCone>>renderOn: method to include calling texCoords for each vertex, however it has not dealt with the problem.
David
David Duke wrote:
Many thanks for your help -- it hadn't occurred to me that the redraws would be triggered repeatedly even with the debugger active.
I noticed that the geometry I included for the cone (specifically, the vertex indices in the Faces array) was incorrect; I may have forgotten to save the image at some point while changing the vertex numbering. In case anyone is looking at it, an updated version is attached.
I loaded your changes class and it lookes like a cone this time:-)
I'm still having the segmentation fault; although I can now at least look more closely at what is going on, I would still be grateful for any suggestions.
Do you have the Squeak 3D plugin ? Is it listed when you print:
Smalltalk listBuiltinModules
or
Smalltalk listLoadedModules
I have tested Squeak without the 3D plugin and Squeak will then fall back on the smalltalk version of the plugin and that is not very snappy.
Karl
Karl Ramberg wrote:
I'm still having the segmentation fault; although I can now at least look more closely at what is going on, I would still be grateful for any suggestions.
Do you have the Squeak 3D plugin ? Is it listed when you print:
Smalltalk listBuiltinModules
or
Smalltalk listLoadedModules
It appears under builtin modules: 'Squeak3D 5 June 2002 (i)'
I was concerned in case I had made a mistake installing the system, so I've gone back to Ian Piumarta's site and downloaded the 3.2-2 VM and the 3.2gamma-4881 image. The problem remains: using B3DCone will crash the application UNLESS B3DBox has been rendered previously.
I do however now have a file Squeak3D.log being created. It contains the message "ERROR: Failed to look up stDisplay". Now, this message is produced in function glInitialize(), defined in the source file platforms/unix/plugins/sqUnixOpenGL.c, if it can't look up "stDisplay" in the interpreterProxy, via ioLoadFunctionWith(..). Looking at the condition under which this message is produced, it seems that the consequent failure to set the value of stDisplay is the cause of the segmentation fault.
However, this doesn't address the real question: why does running B3DSampleMorph with my B3DCone as geometry work only after running B3DBox as geometry? Could anyone expand on how/where glInitialize is being invoked, and why stDisplay might be ?
I have tested Squeak without the 3D plugin and Squeak will then fall back on the smalltalk version of the plugin and that is not very snappy.
As a result of the above, I'm assuming that I'm running the actual plug-in.
-- David
On Wed, Jul 03, 2002 at 04:49:24PM +0100, David Duke wrote:
Karl Ramberg wrote:
I'm still having the segmentation fault; although I can now at least look more closely at what is going on, I would still be grateful for any suggestions.
Do you have the Squeak 3D plugin ? Is it listed when you print:
Smalltalk listBuiltinModules
or
Smalltalk listLoadedModules
It appears under builtin modules: 'Squeak3D 5 June 2002 (i)'
I was concerned in case I had made a mistake installing the system, so I've gone back to Ian Piumarta's site and downloaded the 3.2-2 VM and the 3.2gamma-4881 image. The problem remains: using B3DCone will crash the application UNLESS B3DBox has been rendered previously.
I do however now have a file Squeak3D.log being created. It contains the message "ERROR: Failed to look up stDisplay". Now, this message is produced in function glInitialize(), defined in the source file platforms/unix/plugins/sqUnixOpenGL.c, if it can't look up "stDisplay" in the interpreterProxy, via ioLoadFunctionWith(..). Looking at the condition under which this message is produced, it seems that the consequent failure to set the value of stDisplay is the cause of the segmentation fault.
However, this doesn't address the real question: why does running B3DSampleMorph with my B3DCone as geometry work only after running B3DBox as geometry? Could anyone expand on how/where glInitialize is being invoked, and why stDisplay might be ?
glInitialize is invoked when the B3DAcceleratorPlugin is loaded. stDisplay is used by this plugin to setup a gl context for accelerated rendering. Unfortunately, it doesn't work in Ian's latest VM, because stDisplay isn't exported.
This should not cause a segmentation fault, though. It should just cause the loading of the plugin to abort, and to use the Squeak3D renderer instead. Try deleting the Squeak3D.log file, going to the 'Squeak in 3d project', and turning on hardware acceleration in the Wonderland camera window. This should cause the message to appear in the .log file, but no crash.
Incidentially, if you know how to build VMs, look for my recent message entitled '[BUG][FIX][VM] Unix B3D Acceleration'. This will allow you to use hardware acceleration.
However, none of this is your problem. I tried moving the accelerator plugin where it would not be found, so that only Squeak3D would be used. The crash still occured.
Looking at your code, the only difference is that B3DBox sends texture coordinates to the renderer (although I don't understand exactly what this means, since it sends the position of the vertex as the tex coord). In any event, I changed your code to do the same and it still crashed.
On a hunch, I filed out B3DBox, and renamed it B3DCube.st, and find/replaced B3DBox with B3DCube. I thought that this might cause it to crash; the problem would then be with newly filed-in code that hadn't initialized in some way. Nope: it worked fine.
Sorry, I have to run. And I'm fresh out of ideas.
Joshua
I have tested Squeak without the 3D plugin and Squeak will then fall back on the smalltalk version of the plugin and that is not very snappy.
As a result of the above, I'm assuming that I'm running the actual plug-in.
-- David
squeak-dev@lists.squeakfoundation.org