|
|
|
|
#1
08-28-2003, 09:59 AM
|
|||
|
|||
|
Viewpoint transforms
In the middle of our keyboard-handling definition is the following:
elif key == '65366': # Page Down viz.translate (viz.HEAD_POS, 0, -0.1, 0) elif key == '65365': # Page Up viz.translate (viz.HEAD_POS, 0, 0.1, 0) (There are indentations before those viz.translate() functions, but they aren't showing up due to the formatting here.) Anyway, this works fine when our code doesn't initialize any tracking systems, but when our trackers are enabled, pressing the key has the effect of seeming to translate the user's position before immediately snapping them back to where the tracker is reporting they are. Funny, because I thought I was able to transform the viewpoint like this earlier. Do you have a suspicion what it might be? (I can paste more of the code, if you need it.) Also, we have a script that runs fine on two machines, but not on another-- I'll see if I can determine what is making things crash by commenting out portions of the code until it works again. 
|
|
#2
08-28-2003, 10:18 AM
|
|||
|
|||
|
You are correct that you were able to do that in Vizard R1. In an oversight, that functionality was not carried over to R2 but it will be corrected by release 2.11 (2.10 is the current version) which you can expect in less than two weeks. Thanks for pointing this out to us.
In the meantime, you can try the following since you seem to be only trying to change the height of the user: Code:
myHeight = 0.0
def mykey(key):
global myHeight
#.....
elif key == '65366': # Page Down
myHeight -= .1
viz.eyeheight(myHeight)
elif key == '65365': # Page Up
myHeight += .1
viz.eyeheight(myHeight)
|
|
#3
08-28-2003, 10:49 AM
|
|||
|
|||
|
We actually need to be able to translate more than the eyeheight. I think for now, instead of translating the user, I'll translate all of the geometry instead
 Thanks for your quick reply.
|
|
#4
08-29-2003, 09:04 AM
|
|||
|
|||
|
Re: a scene crashing on one computer but not our others,
I commented out all of the code except for a few viz() initialization functions and the part where it loads a chunk of geometry. Two of our machines can run the scene just fine in either v2.08 or v1.08. The 3rd machine is only able to run it in v1.08. On the troubled computer in v2.08, I dotted a few 'print' statements throughout the script, and they all show up; so it's not that the script is getting halfway down the code and crashing. I'm not sure what it is about the geometry that makes the computer crash. For sake of fiddling with things, if I move the texture maps to the wrong spot (so that when it loads the .VRML file it can't find any of the graphics), the scene works-- well, sort of. If you leave the screen stationary, it will continue to render the (now untextured) geometry in the .VRML file. While in this state, pressing F2 (fullscreen) and F4 (frame rate) work, but pressing F3 (change geometry rendering) causes a crash, as does moving/rotating the viewpoint to an appreciable degree or resizing the rendering window by dragging the window edge. If you need me to do any more experimentation, let me know
|
|
#6
08-29-2003, 10:35 AM
|
|||
|
|||
|
Sure -- here you go.
.WRL isn't accepted as a valid file extension to upload for this board, so I tried to trick it into letting me uploading the file by changing the extension to ".jpg" -- that didn't work, so I had to compress it. Did you need the textures, too? I didn't include them because their collective file size is over 1MB, the upload limit. I suppose I can upload them via multiple-posts to get around that. I am all about fooling the bulletin board today 
|
|
#8
08-29-2003, 10:44 AM
|
|||
|
|||
|
Oops -- thought I already did upload it. Will try again.
|
|
#9
08-29-2003, 11:00 AM
|
|||
|
|||
|
Hi,
I tried the model on two different computers and it loaded fine and I was able to move around the scene, change to wireframe mode, and show the framerate. This is the code I used to load the file: Code:
import viz
viz.go()
viz.add('Room118d.WRL')
You might want to try using the latest version of vizard, 2.10, or you could send me the texture files to see if there is a problem with the texture loader.
|
|
#10
08-29-2003, 11:14 AM
|
|||
|
|||
|
Yep, those are the only lines I'm running in my script.
Incidentally, now it seems to be letting me change the viewpoint without trouble. F3 still makes it crash, as does window-resizing. Re: window-resizing, I've noticed that I can resize it vertically without trouble. Only horizontal resizes make it crash-- the exact behavior is that if i resize the right edge ever-so-slowly, it will let me make the window bigger by about 10 pixels before dying. Is v2.10 available for download yet? If so, it can't hurt to try it.
|
|
#12
09-02-2003, 09:53 AM
|
|||
|
|||
|
v2.10 seems to act the same way.
As I said, the problem doesn't replicate to two of our other machines, so this is probably an elusive problem indeed.
|
|
#14
09-02-2003, 02:09 PM
|
|||
|
|||
|
The computer that doesn't work is using a Matrox Millenium G400 DualHead (incidentally, the same computer for which texture RGB triplets show up anomalous in screenshots).
The other two are using an nVidia Quadro2 and an Gainward-manufactured nVidia GEForce4-440. All three computers are on WinXP.
|
|
#15
09-02-2003, 06:32 PM
|
|||
|
|||
|
Hi,
We tested this out with our Matrox Millenium G400 DualHead and we also got the crash, but when we switched to 24-bit mode everything worked fine. I know that you need the RGB values to be exact, so this might not be an acceptable solution for you. Let me know if this fixes your crashing problems.
|
|
#16
09-05-2003, 10:23 AM
|
|||
|
|||
|
Um, on our end, it won't crash in 24-bit color mode, but it also won't display anything (ie the display window is entirely black; it won't show the geometry, nor will it fill the view window to be the 'clearcolor'.)
We can live with the Matrox card acting weird; we're more concerned with getting the projects we had going in v1.x usable in 2.x. The latest hurdles are: 1. In v1.0x, we had a scene which had to load 256 uniques textures that were shades of gray ranging from RGB (0,0,0) to (256, 256, 256). But the texture limit now seems to be capped at 200, so this scene doesn't work properly. Can we circumvent this limit? (I seem to remember someone else bringing this issue up, but couldn't find it on the board-- apologies if I've recycled an old issue). 2. We have another scene set to be viewed in 'stereo' mode whereby the FOV seems to differ between v1.098 and v2.10. I can flip back and forth between the versions, and even though they're running the same script, the FOV appears smaller in the newer version. (We do have a line to explicitly set the FOV in the code, so this came as a surprise; we initialize it to 50deg with the aspect ratio of 1.333.)
|
|
#17
09-05-2003, 10:43 AM
|
|||
|
|||
|
Hi,
I just increased the texture limit, sorry about that. Also, there was a bug that caused the FOV to change when viewing the scene in stereo, this has been fixed in the latest release. Do you need these changes immediately or can you wait till 2.11?
|
|
#18
09-05-2003, 10:57 AM
|
|||
|
|||
|
Given how quickly you tend to release your updates, we can wait
|
|
#19
09-15-2003, 09:45 AM
|
|||
|
|||
|
Within the next few days would be great... if you could let me know here when the new build is available, it would be appreciated.
Also, one thing that I would find handy is if the current version of Vizard available for download were listed somewhere-- currently to see whether there is a new version ready to go, I have to kind of begin the download process and see what the filename of the Vizard self-extractor is
|
|
#21
09-15-2003, 12:40 PM
|
|||
|
|||
|
Oh, that's right. I even remember having seen that, too. Nevermind
|
 |
|
|
Hybrid Mode
