From: Bruce S. <Bru...@nc...> - 2009-05-10 15:25:31
|
Here is an improved version of a program that effectively rotates the scene rather than the camera. It makes sure that local lights rotate with the scene; only distant lights are "fixed". It also incorporates a feature that I forgot to document: "scene.material = materials.wood" makes the default material be wood (overridden by specific material specifications). from visual import * # This routine watches scene.forward and changes the directions of # the lights to stay fixed with respect to scene.forward. # The effect is to let the user rotate the scene while keeping # the lights fixed, as though one were rotating an object in the # hand to examine it, with fixed lighting, rather than rotating # the camera. # To compare, comment out the while loop, in which case you'll see # that when you rotate around to the back of the scene, it is dark. # This requires Visual 5. A similar routine in Visual 3 would be # somewhat more complicated because the lights were not objects # and so could not be put in a frame. Instead, one would have to # adjust the directions of the lights individually. # Bruce Sherwood, May 2009 scene.material = materials.wood # default material for all objects box(pos=(-2,0,0), color=color.red) box(pos=(2,0,0), color=color.green, material=materials.marble) cylinder(pos=(0,-0.5,0), radius=1, axis=(0,1,0), color=color.orange) s = sphere(pos=(-2,0.8,0), radius=0.3, color=color.cyan, material=materials.emissive) local_light(pos=s.pos, color=s.color) lframe = frame() for obj in scene.lights: if obj.__class__ is distant_light: obj.frame = lframe # put distant lights in a frame old = vector(scene.forward) # keep a copy of the old forward while 1: rate(50) if scene.forward != old: new = scene.forward axis = cross(old,new) angle = new.diff_angle(old) lframe.rotate(axis=axis, angle=angle) old = vector(new) |
From: Guy K. K. <g....@ma...> - 2009-05-10 20:16:48
|
On Mon, 11 May 2009 03:25:28 Bruce Sherwood wrote: > Here is an improved version of a program that effectively rotates the > scene rather than the camera. It makes sure that local lights rotate > with the scene; only distant lights are "fixed". Thanks for that. It does work nicely. However it puts one in the position to need that extra loop (in a thread) to handle these things, so it doesn't have that "ease" of simply using Visual for simple rendering. But it's a good start if one needs that feature. > if obj.__class__ is distant_light: Shouldn't that be rather if isinstance(obj, distant_light): to make it more Pythonic? On that same topic of "Pythonicness" of the Visual API. I've noticed, that the classes don't really follow the common PEP-8 guide lines. They rather use the notation of attributes than classes (lower case and joined with underscores, rather than CamelCase). That confuses often when conditioned to Python naming schemes to infer types of labels in code. Guy -- Guy K. Kloss Institute of Information and Mathematical Sciences Te Kura Pūtaiao o Mōhiohio me Pāngarau Room 2.63, Quad Block A Building Massey University, Auckland, Albany Private Bag 102 904, North Shore Mail Centre voice: +64 9 414-0800 ext. 9585 fax: +64 9 441-8181 eMail: G....@ma... http://iims.massey.ac.nz |
From: Bruce S. <Bru...@nc...> - 2009-05-10 21:19:14
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Guy K. Kloss wrote: <blockquote cite="mid:200...@ma..." type="cite"> <pre wrap="">On Mon, 11 May 2009 03:25:28 Bruce Sherwood wrote: </pre> <blockquote type="cite"> <pre wrap=""> if obj.__class__ is distant_light: </pre> </blockquote> <pre wrap=""><!----> Shouldn't that be rather if isinstance(obj, distant_light): to make it more Pythonic? </pre> </blockquote> Good point. I've made that change and posted the program in the contributed section of vpython.org. And I'll change the documentation for Visual accordingly.<br> <blockquote cite="mid:200...@ma..." type="cite"> <pre wrap=""> On that same topic of "Pythonicness" of the Visual API. I've noticed, that the classes don't really follow the common PEP-8 guide lines. They rather use the notation of attributes than classes (lower case and joined with underscores, rather than CamelCase). That confuses often when conditioned to Python naming schemes to infer types of labels in code. Guy </pre> </blockquote> It's likely that when David Scherer created Visual in 2000 these conventions were not well established. For internal consistency we can't really change now.<br> <br> Bruce Sherwood<br> </body> </html> |
From: Guy K. K. <g....@ma...> - 2009-05-10 21:54:02
|
On Mon, 11 May 2009 09:19:10 Bruce Sherwood wrote: > It's likely that when David Scherer created Visual in 2000 these > conventions were not well established. For internal consistency we can't > really change now. You've got a point there, but ... even Python is reinventing itself with the 3.0 version to get rid of old annoyances. So there could be a "parallel API" for an intermediate time, to keep things working, and later the old API could be marked as deprecated to "wash them out". If it works with Python (also to some lesser extent in older version changes), why shouldn't it work with Visual? Guy -- Guy K. Kloss Institute of Information and Mathematical Sciences Te Kura Pūtaiao o Mōhiohio me Pāngarau Room 2.63, Quad Block A Building Massey University, Auckland, Albany Private Bag 102 904, North Shore Mail Centre voice: +64 9 414-0800 ext. 9585 fax: +64 9 441-8181 eMail: G....@ma... http://iims.massey.ac.nz |
From: Bruce S. <Bru...@nc...> - 2009-05-11 00:46:10
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html;charset=UTF-8" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Frankly, such a revision has extremely low priority among the things that really do need to be done.<br> <br> Bruce Sherwood<br> <br> Guy K. Kloss wrote: <blockquote cite="mid:200...@ma..." type="cite"> <pre wrap="">On Mon, 11 May 2009 09:19:10 Bruce Sherwood wrote: </pre> <blockquote type="cite"> <pre wrap=""> It's likely that when David Scherer created Visual in 2000 these conventions were not well established. For internal consistency we can't really change now. </pre> </blockquote> <pre wrap=""><!----> You've got a point there, but ... even Python is reinventing itself with the 3.0 version to get rid of old annoyances. So there could be a "parallel API" for an intermediate time, to keep things working, and later the old API could be marked as deprecated to "wash them out". If it works with Python (also to some lesser extent in older version changes), why shouldn't it work with Visual? Guy </pre> </blockquote> </body> </html> |