Base Graphics System - Clearing and Camera Control

8 views
Skip to first unread message

Hunter McCurry

unread,
Apr 14, 2011, 12:47:44 AM4/14/11
to field-de...@googlegroups.com
Hello again Marc (and everyone else),

I've been working my way through the BaseGraphicsSystem and BaseGraphicsSystem_Texturing pages in the online documentation and I've got two questions that I haven't yet found answers to. I apologize if these are somewhat specific, but I'm guessing that there could be somebody out there wondering about this too.

1. In setting up meshes and shaders to attach to a canvas, I noticed that there isn't a really easy way to "clear" what I've drawn. On the main field window for example it is easy to write _self.lines.clear() and erase everything that has been drawn, and I recognize that by setting up these custom pipelines things probably won't be so simple. Would I have to clear the mesh somehow or remove it from the GPU? One of the reasons I started wondering about this is that in running the tutorial file called page_BaseGraphicsSystem_Texturing.field, each of the boxes is its own separate example (each one calls canvas=getFullscreenCanvas() and sets up its own shaders and meshes). So after I've run one of the example boxes, I can't seem to run another one. Is this because they are actually creating separate canvases to draw to? The only way I could figure out how to run the second, third and fourth examples in that tutorial was to quit quit and re-launch field between each. Can I assume there's a better method for doing this?

2. One thing I noticed while controlling camera in the main renderer with the keyboard is that sometimes the shift key seems to get "stuck". That is, if I am holding shift and left arrow (in order to orbit around) but let go of the shift button before the arrow key, the camera will continue to orbit even though I've stopped pressing both keys. I am often able to undo this by holding shift again and pressing left and right, being careful to lift up the shift key last. However, sometimes I am still unable to remove the stuck shift key. I understand that this can be a useful feature, say if I wanted to quickly prototype what it will look like when the camera is continually panning or moving, but invariably I end up locking in the shift key by accident. Is there a shortcut to getting all camera motion to stop? I know that running the following code will return the camera to it's initial position, but it won't necessarily stop the camera from orbiting around:

camera = canvas.camera
camera.position = Vector3(0,0,10)
camera.lookAt = Vector3(0,0,0)
camera.up = Vector3(0,1,0)

Thanks,
Hunter


--
P. Hunter McCurry
Masters Student in Music, Science and Technology
CCRMA, Stanford University
www.huntermccurry.com
413-320-9646

Marc Downie

unread,
Apr 14, 2011, 2:48:12 PM4/14/11
to field-de...@googlegroups.com, Hunter McCurry
On Wed, Apr 13, 2011 at 11:47 PM, Hunter McCurry <p.hunter...@gmail.com> wrote:
Hello again Marc (and everyone else),

I've been working my way through the BaseGraphicsSystem and BaseGraphicsSystem_Texturing pages in the online documentation and I've got two questions that I haven't yet found answers to. I apologize if these are somewhat specific, but I'm guessing that there could be somebody out there wondering about this too.

1. In setting up meshes and shaders to attach to a canvas, I noticed that there isn't a really easy way to "clear" what I've drawn. On the main field window for example it is easy to write _self.lines.clear() and erase everything that has been drawn, and I recognize that by setting up these custom pipelines things probably won't be so simple. Would I have to clear the mesh somehow or remove it from the GPU? One of the reasons I started wondering about this is that in running the tutorial file called page_BaseGraphicsSystem_Texturing.field, each of the boxes is its own separate example (each one calls canvas=getFullscreenCanvas() and sets up its own shaders and meshes). So after I've run one of the example boxes, I can't seem to run another one. Is this because they are actually creating separate canvases to draw to? The only way I could figure out how to run the second, third and fourth examples in that tutorial was to quit quit and re-launch field between each. Can I assume there's a better method for doing this?

Two things. Firstly getFullscreenCanvas() isn't creating a new canvas if there already is one (that's what makeFullscreenCanvas does). What's happening, I believe, is the other examples tend to draw right on top of each other. So you don't see any additional geometry being made (since, because of depth buffering, the new geometry doesn't even get drawn).

Secondly, as for "clearing" out geometry, what you are looking for, possibly, is the detach operator '|'.

shader << mesh # connects mesh to shader
shader | mesh # breaks that connection

I've updated the docs to highlight this a little bit. But the truth is, detaching things is actually quite uncommon — far better to reload the shader or put new geometry into a mesh (meshes clear themselves at the start of the outermost "with" clause). Why is it better? OpenGL likes you to set up all of your containers (meshes and shaders) once and then modify their contents (geometry and uniforms). 

I've seen code that's making a new mesh or even a new shader every animation frame — that's a one way ticket to a freeze of your whole OS I'm afraid.

Finally, if you really want a clean slate:

shader.getChildren().clear()

Will do it.
 

2. One thing I noticed while controlling camera in the main renderer with the keyboard is that sometimes the shift key seems to get "stuck". That is, if I am holding shift and left arrow (in order to orbit around) but let go of the shift button before the arrow key, the camera will continue to orbit even though I've stopped pressing both keys. I am often able to undo this by holding shift again and pressing left and right, being careful to lift up the shift key last. However, sometimes I am still unable to remove the stuck shift key. I understand that this can be a useful feature, say if I wanted to quickly prototype what it will look like when the camera is continually panning or moving, but invariably I end up locking in the shift key by accident. Is there a shortcut to getting all camera motion to stop?

Enter on the numeric keypad stops all movement. I've updated the docs. 

It's not a bug it's a feature (although, given your confusion I'm now looking for an alternative implementation). The shift key is deliberately sticky — if you release it before you release the cursor key you'll continue to orbit with your hands away from the keyboard. To stop, you just need to hold down shift and press/release the corresponding arrow key. If the shift key is down when the cursor key is released then it counts as finishing that orbit / move, if it isn't it doesn't.

The upshot is that you can set up rotations, including more complex compositions of multiple orbits, and then go back to typing code while they play out. The downside is that this is completely baffling to people not expecting it.

Alternative implementation ideas welcome!

Marc.

Hunter McCurry

unread,
Apr 14, 2011, 9:24:33 PM4/14/11
to Marc Downie, field-de...@googlegroups.com
Marc,

As usual, thanks for the speedy and detailed response.
 
Two things. Firstly getFullscreenCanvas() isn't creating a new canvas if there already is one (that's what makeFullscreenCanvas does). What's happening, I believe, is the other examples tend to draw right on top of each other. So you don't see any additional geometry being made (since, because of depth buffering, the new geometry doesn't even get drawn).

Secondly, as for "clearing" out geometry, what you are looking for, possibly, is the detach operator '|'.

shader << mesh # connects mesh to shader
shader | mesh # breaks that connection

I've updated the docs to highlight this a little bit. But the truth is, detaching things is actually quite uncommon — far better to reload the shader or put new geometry into a mesh (meshes clear themselves at the start of the outermost "with" clause). Why is it better? OpenGL likes you to set up all of your containers (meshes and shaders) once and then modify their contents (geometry and uniforms). 

I've seen code that's making a new mesh or even a new shader every animation frame — that's a one way ticket to a freeze of your whole OS I'm afraid.

Finally, if you really want a clean slate:

shader.getChildren().clear()

Will do it.
 

Thanks very much, this is exactly what I was looking for. It's also certainly good to know even more about the best ways to use shaders and meshes. I wasn't planning on detaching or clearing meshes every animation frame, but for things like switching between different examples in the tutorial file, this seems useful.


Enter on the numeric keypad stops all movement. I've updated the docs. 

It's not a bug it's a feature (although, given your confusion I'm now looking for an alternative implementation). The shift key is deliberately sticky — if you release it before you release the cursor key you'll continue to orbit with your hands away from the keyboard. To stop, you just need to hold down shift and press/release the corresponding arrow key. If the shift key is down when the cursor key is released then it counts as finishing that orbit / move, if it isn't it doesn't.

The upshot is that you can set up rotations, including more complex compositions of multiple orbits, and then go back to typing code while they play out. The downside is that this is completely baffling to people not expecting it.

Alternative implementation ideas welcome!


Ok great, this makes a lot of sense. I have been using my laptop so actually I haven't even had access to the number pad (and the number pad enter button). I can definitely see how the continuous orbit is a helpful feature, and to be honest I could probably get use to the way the shift key sets and un-sets the orbit. All I know is that it was confusing before I realized what exact thing I had done to set the orbit to continue (for most users in most applications, the order of lifting up buttons isn't important). The only suggestion I can think of at the moment is to have a separate button (like control?) toggle between continued motion and stopped motion. That is, if I'm holding shift and the right arrow I could press the control key once to indicate that I want that motion to continue when I lift up. Repeating the movement and pressing control would un-toggle the motion. This may not be the best solution, but at least it would allow you to move around without accidentally setting a motion to continue, while still allowing you to combine continued motions on different rotation axes when you want to.
Reply all
Reply to author
Forward
0 new messages