Re: [Visualpython-users] Images in VPython

[Jonathan B. <jbr...@ea...>]

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)