From: Joel K. <jj...@ya...> - 2004-09-08 20:27:54
|
First: a member of the Python Edu-Sig group sent me a bug fix for my image-to-object script. The way I originally wrote it, bitmaps with less than 24 bits per pixel may not work. If you insert this line . . . Picture = Picture.convert("RGB") . . . after the "Image.open" command, your bitmap data will be in the right format to be handled properly by both PIL and VPython. Second: Jonathan's summary of the texture-mapping prospects was educational, even though much of it was beyond my level of expertise. One point that did come through clearly was the need for powerful hardware to handle (let alone animate) any significant number of detailed texture-matched objects. I think that this would be a good justification for a VPython-oriented cluster experiment. Does anybody have the time and the interest to join me in putting together some kind of grant proposal for a Beowulf project? I'm open to any relevant suggestions. . . . Joel __________________________________ Do you Yahoo!? Read only the mail you want - Yahoo! Mail SpamGuard. http://promotions.yahoo.com/new_mail |
From: Jonathan B. <jbr...@ea...> - 2004-09-08 20:54:46
|
On Wed, 2004-09-08 at 16:27, Joel Kahn wrote: > First: a member of the Python Edu-Sig group sent me a > bug fix for my image-to-object script. The way I > originally wrote it, bitmaps with less than 24 bits > per pixel may not work. If you insert this line . . . > > Picture = Picture.convert("RGB") > > . . . after the "Image.open" command, your bitmap data > will be in the right format to be handled properly by > both PIL and VPython. > > Second: Jonathan's summary of the texture-mapping > prospects was educational, even though much of it was > beyond my level of expertise. One point that did come > through clearly was the need for powerful hardware to > handle (let alone animate) any significant number of > detailed texture-matched objects. I think that this > would be a good justification for a VPython-oriented > cluster experiment. Does anybody have the time and the > interest to join me in putting together some kind of > grant proposal for a Beowulf project? I'm open to any > relevant suggestions. . . . > > Joel Cluster? No, I think that would be a bad idea for VPython. Any recent video card will be able to handle pretty much anything you can throw at it from VPython. A scene with several translucent and textured objects, some using a source image of 1024x2048 pixels, can be rendered in only a few ms on common PC hardware. You really can't notice that it takes any time at all, and the UI remains buttery-smooth. Speed is not the problem. Picking the right parts of a complex environment (or completely reformulating the appearance of what you are doing) to expose to client programs in Python is the hard part, and that is what I would appreciate some feedback on. -Jonathan |
From: Jon S. <js...@so...> - 2004-09-09 12:53:28
|
> > Speed is not the problem. Picking the right parts of a complex > environment (or completely reformulating the appearance of what you are > doing) to expose to client programs in Python is the hard part, and > that > is what I would appreciate some feedback on. > I'm excited to hear about these developments, but got lost in the trees of your description of the issues. On the off chance that you too are lost in the trees of coding, I want to make sure that the basic vpython aesthetic is not being overlooked. Pixels, for example, are several levels more molecular than I would likely want to work. I'd want to be able assign texture and transparency to an *object*'s surface. The positioning of the texture on the object might be controlled by rotating the texture around the center of the object. The texture would automagically slide around on the surface of the object. Since transparency is now an option (and this is very good news!) The surfaces of objects might also have thicknesses (with defaults of course). And the interiors might have a density/opacity parameter as well. The default condition I think should be thickness=.00001 (just enough to put a texture on) and opacity=1. And then vpython would do all of the per-pixel calculation (and shadowing and light scattering) under the hood, as is its "true nature". I hope this is helpful or suggestive. Regards, =-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Jon Schull, Ph.D. Associate Professor Information Technology Rochester Institute of Technology 102 Lomb Memorial Drive Rochester, New York 14623 sc...@di... 585-738-6696 |
From: Jonathan B. <jbr...@ea...> - 2004-09-09 14:20:08
|
On Thu, 2004-09-09 at 08:53, Jon Schull wrote: > > > > Speed is not the problem. Picking the right parts of a complex > > environment (or completely reformulating the appearance of what you are > > doing) to expose to client programs in Python is the hard part, and > > that > > is what I would appreciate some feedback on. > > > > I'm excited to hear about these developments, but got lost in the trees > of your description of the issues. > > On the off chance that you too are lost in the trees of coding, I want > to make sure that the basic vpython aesthetic is not being overlooked. > Pixels, for example, are several levels more molecular than I would > likely want to work. > > I'd want to be able assign texture and transparency to an *object*'s > surface. The positioning of the texture on the object might be > controlled by rotating the texture around the center of the object. > The texture would automagically slide around on the surface of the > object. That is the idea. There are two means of automatic texture-coordinate generation (the texture coordinates specify how to wrap the texture to the object). The first is a kind of planar projection, where you specify the position of the texture in world space, and it is linearly projected onto the surface of the body. The second is similar to that, except that the position of the texture is specified in screen space, meaning that it is projected from somewhere relative to your monitor. For those bodies where an obvious algorithm exists for mapping the texture, we can provide a default mapping. The box object simply maps the texture in its entirety to each plane. The sphere (and by extension, the ellipse) wraps the texture around itself as though the texture were laid out like http://earthobservatory.nasa.gov/Newsroom/BlueMarble/Images/land_ocean_ice_cloud_2048.jpg I haven't decided on default mappings for the other objects. The cylinder could support three separate textures (the side and each end). The cone can do something similar, and the ring has a reasonable one too. I can't think of a sane default for the arrow object, yet. > Since transparency is now an option (and this is very good news!) The > surfaces of objects might also have thicknesses (with defaults of > course). And the interiors might have a density/opacity parameter as > well. Well, that is the catch with transparency. You can only really set transparency for an individual zero-thickness planar triangle in OpenGL. So, on the outside, we expose a model where the entire body is controlled by a common opacity value, tentatively named 'alpha', but it should probably be named 'opacity'. > The default condition I think should be thickness=.00001 (just enough > to put a texture on) and opacity=1. > > And then vpython would do all of the per-pixel calculation (and > shadowing and light scattering) under the hood, as is its "true > nature". The only thing that you would have to do per-pixel is generate the texture itself, and only then if you are not loading the image from a file. Shadowing and light scattering are things that OpenGL does not support, directly. They can be emulated indirectly, but not to the extent that you would expect from say, a raytracing package. The code for the translucent boxes demo looks like this: from visual import * # Verify the dimensions of the bodies, with a known unit-length # object. yardstick = arrow() box( pos=(2, 0, 0), alpha=0.4) box( pos=(-2, 0, 0)) # file_texture objects inherit from 'texture', which most Visual objects # can use panel = file_texture( "crate.bmp") box( pos=(0, 2, 0), texture=panel) box( pos=(0, -2, 0), texture=panel, color=(1, 1, 1, 0.5)) sphere( pos=(0, -2, 0), radius=0.4) |
From: Jonathan B. <jbr...@ea...> - 2004-09-09 14:49:47
|
On Thu, 2004-09-09 at 10:20, Jonathan Brandmeyer wrote: > You can only really set > transparency for an individual zero-thickness planar triangle in > OpenGL. That is not strictly true. You can also specify it for a point, whose size is measured in pixels. Flames and fog clouds are done this way, in games, and the tech to do it is commonly called a 'particle engine', if you want to google for more info. Visual doesn't have a 'points' object yet, but a team in Australia is working on one. I don't know if they intend to imbue it with particle engine functionality, but I think it is meant to be more like the 'curve' object. -Jonathan |