patch for game-like navigation through gl space
Hello eveyone,
I've been doing a bunch of projects lately that require intuitive movement through gl space, and I thought I would post a clean and condensed version of the navigation system that I've been using. Any suggested improvements or comments would be great.
Drop this into your jitter patch and connect it to your jit.gl.render. Here are the navigation instructions: I've also attached a sample patch with ReadMe file.
MOVEMENT:
Use the mouse/trackpad to control your lookat point.
Use the keyboard to move the camera
In this version of the patch, moving forward/backward/left/right = moving parallel to the x-z plane. You can look up or down while moving forward/backward/left/right, but this will not affect your movement on the y axis. Moving up/down = moving along the y axis. You can look around as you move up/down, but this will not affect your movement along the x and z axes. I find this to be the more convenient way to navigate and view gl space.
'w' moves camera forward
's' moves camera backward
'a' moves camera left
'd' moves camera right
COMBINE THE ABOVE KEYS FOR DIAGONAL MOVEMEMENT
'r' moves camera up
'e' moves camera down
OTHER CONTROLS:
'k' toggles movement on/off
'console' opens the console, where you can change movement speed and view current camera coordinates
'z' zooms the camera view in
I made a few small improvements. Here it is - also attached an updated zip file
Zach
And here is the second version of the patch. This is a more typical flight simulator. No seperate keyboard control for the y axis. Just point and go. I've also attached another zipped example folder for this version
nice patch.
my one suggestion would be to make the forward/backward/up/down/left/right key controls move the camera based on it's current orientation, rather than based on world orientation.
so if the the camera has been rotated by the mouse to look straight up, pressing 'w' will make the camera move up, or forward relative to the direction it's looking, rather than forward based on the absolute world orientation.
-rob
Zachary, these are very nice! The abstraction approach makes it very
easy to just drop it into an old patch that you might want to explore,
without having to fiddle about too much.
One thing I would recommend is to add a bit of smoothing to the mouse
movements, since it does appear slighly jerky? And another suggestion
would be to let the key-controlled movements accelerate a bit over time.
Brilliant work, Z.
Andreas.
Andreas and Rob, thanks for the input and suggestions. It will be a few days before I am able to make changes as my laptop firewire port died and is currently being replaced (along with the whole damn logic board).
Andreas -
I like your idea to smooth out the mouse movements. I've just been adjusting the mouse/trackpad pointer speed to get a slower, smoother feel. The only problem with adding a smoothing process is that the user may already have a very slow pointer speed. So either I let people adjust it in their system preferences, or I tell people to set there pointer speeds at a medium to fast speed and do the smoothing myself. What do you think? Is there another way?
Accelerating over time is a nice idea too, I might try that. Thanks.
Rob -
"pressing 'w' will make the camera... move forward relative to the direction it's looking, rather than forward based on the absolute world orientation."
There are two versions of this patch. The second one does this. When you press 'w' you go "forward", which means wherever you are looking. When you press 's' you go "backward, which means away from wherever you are looking.
The first one also does this in reference to the x-z plane. It's more like walking on the ground, as opposed to flying around. In the first version, if I look "forward and a little up" when I press 'w' I go forward along the "ground" - that is the x-z plane, while looking up - as if I were looking at the sky while walking along the ground. Up and down are not controlled by your "eyes". When I press 'r' or 'e' I go straight up or down. along the z axis. You can still combine vertical and horizontal movements in this version with key combinations. The approach in this first version of the patch was to allow you to look at something while moving around it.
Here's a question: In the second version, when you strafe right or left, your lookat point affects your movement along the z axis. So in other words, if I go left while looking a little up, I will move left and a little up. I'm not sure this is best, maybe strafing should always be parallel to the x-z plane. What do you think?
Zachary Seldess skrev:
> Here's a question: In the second version, when you strafe right or left, your lookat point affects your movement along the z axis. So in other words, if I go left while looking a little up, I will move left and a little up. I'm not sure this is best, maybe strafing should always be parallel to the x-z plane. What do you think?
I like the second and newest way - moving the mouse while strafing
affects the direction - makes the most sense when navigation, I feel.
Andreas.
Jose,
What?
Zachary
First of all, please start a new thread by creating a new email,
rather than replying to one and changing the subject line. Otherwise,
stuff gets filed in the wrong place, is hard to find and you don't
get the help you are looking for.
Second, I'll need some system information before I'm able to look at
this. If you're on OSX, I'd like a Crashlog as well.
Thanks
Jeremy
Am 14.08.2007 um 00:04 schrieb jose manuel berenguer:
> I maxmsp-jitter always crashes some 60 secons after activating the
> bang to select the slxml.xml file to upload...
>
> jmb
I changed the flying navigator (v2) so that when you strafe left or right your lookat coordinate controls translation on the x and z axes but not on the y (vertical). If you strafe AND go foward/backward though, your lookat will affect translation on the y axis. This is the most intuitive setup, in my opinion. And it allows for you to orbit around an object while looking down or up at it. I've attached both walking and flying navigators.
I also added a smoothing process (via javascript) to both versions of the patch. If you want it even smoother, just change the argument for the easing.js objects inside p mousestate.
I've attached both versions in a zip file along with example patches and readme files.
One more update - fixed a slight glitch in the navigation. Attached.
Question:
I'd like to add a target - something to make navigating more accurate. I've experimented with simply placing a transparent sphere or circle at a perpetually equal distance form the "front" of the camera, and it works, but it's not preferable.
Is there any way to overlay a HUD in a jitter window, that does not need to be translated and rotated based on camera position in gl space. It will just always be mounted "on the surface" of the window"? This is typical in 3D games, and I've done it with the Torque Game Engine, but haven't been able to figure out how to do it in jitter.
Have you tried the @transform_reset 2 attribute? It will create
normalized coordinates from [-1, 1] across both x and y of the screen
for hud-like behavior.
wes
On 8/17/07, Zachary Seldess wrote:
> One more update - fixed a slight glitch in the navigation. Attached.
>
>
> Question:
> I'd like to add a target - something to make navigating more accurate. I've experimented with simply placing a transparent sphere or circle at a perpetually equal distance form the "front" of the camera, and it works, but it's not preferable.
>
> Is there any way to overlay a HUD in a jitter window, that does not need to be translated and rotated based on camera position in gl space. It will just always be mounted "on the surface" of the window"? This is typical in 3D games, and I've done it with the Torque Game Engine, but haven't been able to figure out how to do it in jitter.
>
>
> --
> http://www.zacharyseldess.com
>
>
>
>
>
Thanks Wes. That was exactly what I was looking for.
Is there a way, aside from using the layer attribute, to ensure that an object will always stay at the bottom of the rendering stack, so that it will be perpetually transparent?
zach
To be more specific, if I don't want to use jit.gl.sketch or write a shader - i want to stay with the jit.gl.gridshape object - is there any way other than the layer attribute to ensure that the object will always remain transparent (given the alpha value is set as such).
In the case of the above patch it is important because it is likely that a person will drop the abstraction into a previously made patch causing the gridshape in my abstraction to be added last to the render context and thus loose it's transparency while rendering "in front" of the objects in the parent patch. Using the layer attribute is still risky, there's a good chance that the parent patch has objects at different layers as well, and if there is an object at the same layer as the object in my abstraction, the latter will again be added to the render context after the former, causing it to loose transparency, I think.
I've fooled around with the blend_mode attribute a bit and read the docs but I don't really understand what's happening there. Is there a blend_mode configuration that I can set my object to to cause permanent transparency? Or some other way?
Thanks for the help!
Here's another update. Now both abstractions have HUD-like bullseyes and they display camera coordinates in the jitter window. They're both turned off by default.
When you instantiate the abstraction give it a 1st argument of your render context name, and a second argument of the highest unused layer. After attaching it to you jit.gl.render object, you can press 'k' to move look and move around.
press 'z' to zoom you view in
press 'c' to toggle coordinate display on/off
press 'b' to toggle bullseye display on/off
If anyone has anymore suggested improvements, let me know.
It's all attached with sample patches.
Quote: Zachary Seldess wrote on Thu, 23 August 2007 22:59
----------------------------------------------------
> Here's another update. Now both abstractions have HUD-like bullseyes and they display camera coordinates in the jitter window. They're both turned off by default.
>
> When you instantiate the abstraction give it a 1st argument of your render context name, and a second argument of the highest unused layer. After attaching it to you jit.gl.render object, you can press 'k' to move look and move around.
>
> press 'z' to zoom you view in
> press 'c' to toggle coordinate display on/off
> press 'b' to toggle bullseye display on/off
>
> If anyone has anymore suggested improvements, let me know.
>
> It's all attached with sample patches.
----------------------------------------------------
Hi,
This is a very nice patch. It is very good to see this kind of package and really save user a lot of time.
thanks
CK
Here's another update. Now you can manually reset camera and lookat coords in the the right two inlets (list: x y z for both). So you don't have to take the time to fly somewhere far away...
New example patches are included.
Zachary
Aaaahh, found one little glitch. Fixed it. Sorry for the redundancy.
thank you Zachary, real helpful patching
On 9/13/07, Zachary Seldess wrote:
>
> Aaaahh, found one little glitch. Fixed it. Sorry for the redundancy.
> --
> http://www.zacharyseldess.com
>
>
>
>
>
Thanks Yair, glad you find it useful. If you have any suggested improvements, please post them.
great stuff, would be cool to have one patch where you can key switch between modes.
That's a good idea - I've been meaning to do something like it. It will happen eventually... Thanks for the suggestion.