visualpython-users

RE: [Visualpython-users] Planned work for Fall '01

[David S. <dsc...@vy...>]

> can we get decent looking results by choosing one standard 
> mapping? i mean, of course not, but if you just want to 
> import square textures you found as web page backgrounds to 
> spiff up your VPython programs, is "use spherical mapping for 
> everything" acceptable to people? (I say that because it's a 
> mapping that will look broken no matter what you do, so you 
> might as well not waste time trying to edit your textures at all).

Heh.  That's a really good way of describing spherical mapping :)

I think if you want a default projective texturing mode it should be
planar.  It's the only one that's reasonably easy to understand, and you
can do tiling.  But I warn you, any approach will be more complicated
than it seems.  How *exactly* does it rotate, translate, and scale with
the object?

> > I can also see some visualization applications for textures - maybe 
> > someone wants to draw contours on a height field, or heat 
> levels in a 
> > sliding friction simulation.
> 
> Right. So for that, tcoords and textures should just be 
> arrays accessible like the other atributes of faces.

Or planar texturing would be fine.

>   - Per-vertex textures for procedural texturing. Is this 
> applicable to
>     spheres or hexahedrons or whatever, or only to faces and possibly
>     convex? Of course this per-vertx texturing lets you 
> import models too.

Spheres, definitely not.  Hexahedrons yes, they are array primitives
with separate control for each vertex.  OTOH I was thinking that
hexahedron might be wrapped into faces with some interface tweaking.

>   - You probably also want a nice-looking mapping for each 
> primitive, with
>     a "template" texture provided to paint on, so if you want to do a
>     special goodlooking texture for one or a few primtives 
> you can, by hand.

I think anyone who can produce a "good looking" texture also can produce
3D models.  Is there really a demand for this?  I'm still waiting for
someone who will *use* this to speak up.

> How does POVRay specify textures for primitives? 

Chiefly procedurally.  In a raytracer color is most conveniently a
function of position, so they give you some basic 3D noise functions and
build up a material library from there.  Think Bryce without a UI.

I'm sure it also has bitmapped textures.  Just by knowing it's a
raytracer I would guess that it uses the projective approach.

> There's something else we haven't discussed: we presumably 
> want a Texture object, which can both import 2d data fed in 
> in code, and load some standard image files. There's an 
> rgbimg module for reading .rgb files, and an imageop module 
> that can do a few pathetic image operations. 

There's a library PIL that loads a lot of image file formats, and can
easily convert to/from Numeric.  This is a really dumb thing to write
ourselves.

Dave

Re: [Visualpython-users] Planned work for Fall '01

[Ari H. <ahe...@an...>]

On Sun, Jul 22, 2001 at 03:16:14PM -0400, David Scherer wrote:
> [Ari said]
> > > > i haven't thought seriously about the kind of interfaces that
> > > > would be nice for texturing the existing primitives, and i 
> 
> [I said]
> > > I can see a few basic approaches
> 
> ... but after some reflection I'm uncomfortable because I don't have a
> good picture of how texturing will be used in practice.  The initial
> design of VPython benefitted enormously from concrete examples drawn
> from Bruce and Ruth's course.  Do we have any such concrete use cases
> here?

- procedurally texturing primitives, espcially convex and faces
- "toy" or "easy as possible" texture applications, with the goal of
  getting reasonably nice visual results with minimum effort. 
- importing mappings from modeling tools
- one-off or rare uses of texture for one or two primitives in a program.

> 
> I can definitely see people wanting to import models complete with
> textures.  That can best be done by adding texture coordinates to faces.
> Mapping is up to the modeling software (and file format).

this is a 10 minute hack to faceset.cpp (which i just read).

> 
> I can also see that people might like to be able to make a "wood" sphere
> instead of a "brown" sphere.  Frankly, it's hard to see how what we've
> discussed so far is going to make this acceptably easy.  We could use
> the functionality to create a library of standard materials, but there
> are some big problems.  We need a different wood texture for each
> standard primitive (or each mapping mode).  The user has to choose
> between them.  Someone has to do the art.

can we get decent looking results by choosing one standard mapping? i mean,
of course not, but if you just want to import square textures you found as
web page backgrounds to spiff up your VPython programs, is "use spherical
mapping for everything" acceptable to people? (I say that because it's a
mapping that will look broken no matter what you do, so you might as well
not waste time trying to edit your textures at all).
> 
> I can also see some visualization applications for textures - maybe
> someone wants to draw contours on a height field, or heat levels in a
> sliding friction simulation.

Right. So for that, tcoords and textures should just be arrays accessible
like the other atributes of faces.

...

So with that we've got
  - Spherical -- just a way to get some kind of material on everything, 
    quickly and easily
  - Per-vertex textures for procedural texturing. Is this applicable to
    spheres or hexahedrons or whatever, or only to faces and possibly
    convex? Of course this per-vertx texturing lets you import models too.
  - You probably also want a nice-looking mapping for each primitive, with
    a "template" texture provided to paint on, so if you want to do a
    special goodlooking texture for one or a few primtives you can, by hand.

I don't think it's the place of Visual to start providing texture libraries;
if people want to use a real modeler they can. The focus should be on stuff
that's useful for visualization, and I see primarily "throw a quick material
on it" and procedural applications there.

How does POVRay specify textures for primitives? 

...

There's something else we haven't discussed: we presumably want a Texture
object, which can both import 2d data fed in in code, and load some standard
image files. There's an rgbimg module for reading .rgb files, and an imageop
module that can do a few pathetic image operations. 


Ari

RE: [Visualpython-users] Planned work for Fall '01

[David S. <dsc...@vy...>]

[Ari said]

> > > i haven't thought seriously about the kind of interfaces that
> > > would be nice for texturing the existing primitives, and i 

[I said]

> > I can see a few basic approaches

... but after some reflection I'm uncomfortable because I don't have a
good picture of how texturing will be used in practice.  The initial
design of VPython benefitted enormously from concrete examples drawn
from Bruce and Ruth's course.  Do we have any such concrete use cases
here?

I can definitely see people wanting to import models complete with
textures.  That can best be done by adding texture coordinates to faces.
Mapping is up to the modeling software (and file format).

I can also see that people might like to be able to make a "wood" sphere
instead of a "brown" sphere.  Frankly, it's hard to see how what we've
discussed so far is going to make this acceptably easy.  We could use
the functionality to create a library of standard materials, but there
are some big problems.  We need a different wood texture for each
standard primitive (or each mapping mode).  The user has to choose
between them.  Someone has to do the art.

I can also see some visualization applications for textures - maybe
someone wants to draw contours on a height field, or heat levels in a
sliding friction simulation.

Is anyone willing to step forward and fantasize about what they could do
with some particular kind of texturing functionality?

Dave

Re: [Visualpython-users] Planned work for Fall '01

[Ari H. <ahe...@an...>]

On Sun, Jul 22, 2001 at 02:08:36PM -0400, David Scherer wrote:
> > i haven't thought seriously about the kind of interfaces that 
> > would be nice for texturing the existing primitives, and i 
> > want to get peoples' input. i always assumed that there isn't 
> > a good consistent interface, and that some primitives (faces, 
> > box) will want to take a list of texture coordinates, while 
> > things like sphere have only one reasonable texturing scheme 
> > (especially because sphere may change detail levels).
> 
> I can see a few basic approaches:
> 
>  (1) Think in terms of "skins": pick a texture coordinate mapping for
> each built-in object, and draw a "template" texture with lines showing
> where the faces (or whatever) fall in the texture.  People edit the
> texture to their satisfaction and then use it.
> 

ok. that's easy enough. probably the most useful thing for cones and arrows,
and boxes (and hexahedrons ...i didn't even know we had a hexahedron
primitive). heh, this reminds me of using Alice in the bad old days, you
used to have to manually unmap every face of your 3DS model, and lay it out
into the texture. The result was exactly the kind of 
"template" you're talking about ;)

>  (2) Think in terms of projection: you can take *any* object and apply a
> texture projectively using a mapping mode such as planar, cubic,
> cylindrical, etc.  This might be more useful for "scientific"
> applications where textures are being built procedurally.
>

right. this is probably the only way to specify textures meaningfully for
spheres.
 
>  (3) Texture coordinates.  These are only usable in cases where the
> vertices of the object are accessible to the programmer!  The only
> cvisual primitives that meet this test are faces, convex, and hexahedron
> (and curve, in one dimension).
> 

<nod>


Ari

i'm so deranged at this pint thati'm downloading Python 2.1 and the latest
VPYthon snapshots on a 28.8 dialup to play with the faces primitive.

i wonder if htey have drugs for this now.

[apologies for bad typing caused by sharing connection with download]

RE: [Visualpython-users] Planned work for Fall '01

[David S. <dsc...@vy...>]

> i haven't thought seriously about the kind of interfaces that 
> would be nice for texturing the existing primitives, and i 
> want to get peoples' input. i always assumed that there isn't 
> a good consistent interface, and that some primitives (faces, 
> box) will want to take a list of texture coordinates, while 
> things like sphere have only one reasonable texturing scheme 
> (especially because sphere may change detail levels).

I can see a few basic approaches:

 (1) Think in terms of "skins": pick a texture coordinate mapping for
each built-in object, and draw a "template" texture with lines showing
where the faces (or whatever) fall in the texture.  People edit the
texture to their satisfaction and then use it.

 (2) Think in terms of projection: you can take *any* object and apply a
texture projectively using a mapping mode such as planar, cubic,
cylindrical, etc.  This might be more useful for "scientific"
applications where textures are being built procedurally.

 (3) Texture coordinates.  These are only usable in cases where the
vertices of the object are accessible to the programmer!  The only
cvisual primitives that meet this test are faces, convex, and hexahedron
(and curve, in one dimension).

Dave

RE: [Visualpython-users] Planned work for Fall '01

[David S. <dsc...@vy...>]

> > Seems to be that texturing is harder than [transparency].

No.  Texturing is much easier than transparency in a general-purpose
renderer.
 
> > I realize I am missing something - depth cuing or something.  

Yes, you are missing something.  No, I'm not going to explain it again
:)

> Personally I'd happily settle for a not-so-good 
> transparency if that were easily achievable.

Well, there are lots of not-so-good options:

Additive alpha is easily achievable, and even has a physical
interpretation: an infinitesimally thick glowing surface.  That is, of
course, not what people expect when they ask for transparency :)

Maybe one could come up with a blending mode using the alpha buffer (not
sure about how much hardware support there is for that) that would work
out to "average alpha", which looks like real alpha in the case where
there is only one transparent object, or all transparent objects are the
same color.  In other cases it would be nonphysical but
order-independent and perhaps not visually unreasonable.

Standard (blend) transparency and two-pass (opaque, then transparent)
rendering without sorting is pretty weird, but I suppose for some
applications it might look better than nothing.

However, I'm not really in favor of adding functionality to Visual that
isn't "right"; it's really bad for usability.

Dave

Re: [Visualpython-users] Planned work for Fall '01

[Ari H. <ahe...@an...>]

On Sun, Jul 22, 2001 at 01:10:48PM -0400, Arthur Siegel wrote:
> Not sure its directly responsive - but high on my wish list is some simple
> access to 4 factor coloring - some access to an alpha transparency.  Full
> opaqueness often fully hides objects where I wish to at least hint at
> their existence.
> 
> It has been already explained to me why this is not a simple matter,
> though I didn't get it.  I know in opengl its simply a matter of using a
> color4 rather than a color3. Why can't that be an option, with the alpha
> factored defaulted to 1 if one uses only a 3 elements.

oh, that's not the problem. yeah yeah, we could turn on transparency, and
things would alpha :)

iirc (and we have talked about this before, as usual scherer please correct
me) the problem is that Visual doesn't know enough about the spacial
relationship between objects, at least as far as rendering. so it can't
guarantee anything like correct behaviour -- if you're rendering opaques,
you just tell GL to depthbuffer, and render in whatever order you happen to
render in, and everything magically works right. but alpha is a cumulative
effect that you calculate in the output buffer as you render, so order
matters.

fixing visual's core renderer to handle this correctly would not be a simple
thing. i haven't looked seriously at doing it, and i'm not planning to
(immediately anyhow). but it could be done -- hackishly, you could sort the
objects before render. there are fast ways of doing things that involve
maintaining much more info at all times.

> 
> Seems to be that texturing is harder than this.  Will the work necessary
> have any impact on the ability to implement transparency?

not really :) except possibly making me even more insane and unstable, which
could result in me doing all kinds of unpredictable things.

textures are an additional feature of the primitives. they work (in GL)
about the same way vertices do, so you just need a way of getting texture
data (per vertex) into the primitive, and you need to say to the renderer
"this vertex has this texture coordinate".

> 
> I realize I am missing something - depth cuing or something.  Personally I'd
> happily settle for a not-so-good transparency if that were easily
> achievable.

well. utterly unpredictable transparency is quite possible ;) you'll just
never know whether you'll see the back object thru the transparent front
object, or if the back object will just obscure the front object.

i guess it might produce results that weren't too visually jarring if you
made all the objects transparent, and all your users lost their contacts
beforehand :)



ari

Re: [Visualpython-users] Planned work for Fall '01

[Arthur S. <aj...@ix...>]

Not sure its directly responsive - but high on my wish list is some simple
access to 4 factor coloring   - some access to an alpha transparency.  Full
opaqueness often fully
hides objects where I wish to at least hint at their existence.

It has been already explained to me why this is not a simple matter, though
I didn't get it.  I know in opengl its simply a matter of using a color4
rather than a color3. Why
can't that be an option, with the alpha factored defaulted to 1 if one uses
only a
3 elements.

Seems to be that texturing is harder than this.  Will the work necessary
have any impact on the ability to implement transparency?

I realize I am missing something - depth cuing or something.  Personally I'd
happily settle for a not-so-good transparency if that were easily
achievable.

ART

----- Original Message -----
From: "Ari Heitner" <ahe...@an...>
To: <vis...@li...>
Sent: Sunday, July 22, 2001 12:37 PM
Subject: [Visualpython-users] Planned work for Fall '01


>
> hi everyone,
>
> i'm a cmu student and i've been involved with vpython in minor ways for
some
> time now. i've been meaning to implement first textures, then proper
> hierarchical models, in vpython for about a year now. i haven't really
done
> much in that direction, but now that dscherer has written the Faces
> primitive, and i actually have the time (coursewise) to devote to it, i'm
> hoping to get this done this coming semester.
>
> i haven't thought seriously about the kind of interfaces that would be
nice
> for texturing the existing primitives, and i want to get peoples' input. i
> always assumed that there isn't a good consistent interface, and that some
> primitives (faces, box) will want to take a list of texture coordinates,
> while things like sphere have only one reasonable texturing scheme
> (especially because sphere may change detail levels).
>
> after textures i'd like to do hierarchical models, which can be made up of
> faces objects in frames quite nicely. the only question is what model
format
> to use for importing. i'm open to suggestions here. i've written 3DS
> exporters in the past; it's doable but not something i want to spend time
> on. is there a good standard format the 3ds can talk to (doesn't need to
be
> complicated, just needs to support hierarchy and textures)? is vrml it
> (ugh!)?
>
> i'm mainly posting this because i suspect a lot of people would like this,
> and i'd like to coordinate efforts so we don't end up duplicating work.
> while i expect to get this stuff done fairly quickly when i actually start
> on it, i won't be starting for about another month (once i get back to
> pittsburgh).
>
>
> ari
>
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> http://lists.sourceforge.net/lists/listinfo/visualpython-users
>

[Visualpython-users] Planned work for Fall '01

[Ari H. <ahe...@an...>]

hi everyone,

i'm a cmu student and i've been involved with vpython in minor ways for some
time now. i've been meaning to implement first textures, then proper
hierarchical models, in vpython for about a year now. i haven't really done
much in that direction, but now that dscherer has written the Faces
primitive, and i actually have the time (coursewise) to devote to it, i'm
hoping to get this done this coming semester.

i haven't thought seriously about the kind of interfaces that would be nice
for texturing the existing primitives, and i want to get peoples' input. i
always assumed that there isn't a good consistent interface, and that some
primitives (faces, box) will want to take a list of texture coordinates,
while things like sphere have only one reasonable texturing scheme
(especially because sphere may change detail levels).

after textures i'd like to do hierarchical models, which can be made up of
faces objects in frames quite nicely. the only question is what model format
to use for importing. i'm open to suggestions here. i've written 3DS
exporters in the past; it's doable but not something i want to spend time
on. is there a good standard format the 3ds can talk to (doesn't need to be
complicated, just needs to support hierarchy and textures)? is vrml it
(ugh!)?

i'm mainly posting this because i suspect a lot of people would like this,
and i'd like to coordinate efforts so we don't end up duplicating work.
while i expect to get this stuff done fairly quickly when i actually start
on it, i won't be starting for about another month (once i get back to
pittsburgh).


ari

[Visualpython-users] New version of VRML Export

[Michael Z. K. <mz...@an...>]

A new version of VRML Export is available.  The face primative can now be
exported to VRML.

Find the new version at http://www.andrew.cmu.edu/~mzk/vrmlexport/

Apparantley, the faces.__class__ attribute has yet to be defined so (until
VPython is updated) after you define a faces object also define its
__class__:
	
	object = faces(...)
	object.__class__ = "faces"

This is neccesary so VRML export correctly export the face.

-Michael

[Visualpython-users] New VPython for Windows

[Bruce S. <ba...@an...>]

There is a new VPython for Windows at 
http://cil.andrew.cmu.edu/projects/visual.

This introduces the new "faces" object created by Dave Scherer. The new 
object is a low-level programming mechanism especially useful for importing 
3D models created with other 3D tools.

Included are sketchy documentation on "faces" and two illustrative demo 
programs contributed by Scherer. As stated in the documentation, the new 
object is somewhat experimental. It is possible that the syntax will change.

If you already have VPython installed, you only need to download and 
install the zip files for DLL, visual, Doc, and Demos.

David Andersen imported Scherer's changes and built the DLL.

Bruce Sherwood

RE: [Visualpython-users] Importing/Mouse Events

[David S. <dsc...@vy...>]

I have just added a new, highly experimental primitive to cvisual called
"faces", that is far more flexible (but also harder to use) than convex
for this sort of purpose.  You might want to grab it off the
visualpython-devel archives and play with it.

Dave

> -----Original Message-----
> From: vis...@li... 
> [mailto:vis...@li...] On 
> Behalf Of Ryan Martens
> Sent: Thursday, July 19, 2001 10:54 AM
> To: vis...@li...
> Subject: RE: [Visualpython-users] Importing/Mouse Events
> 
> 
> How possible would it be to import non-primitive VRML objects 
> using the convex object?  I realize that you would be limited 
> to convex objects, but it would be a good start on 
> visualizing the object.
> 
> Ryan
> 
> >So there is a Python VRML97 parser at 
> >http://members.home.com/mcfletch/programming/mcf_vrml.htm
> >
> >which looks promising.  If I have time this weekend I was thinking 
> >about writing a simple VRML importer (i.e. - 
> primative->primatve ) to 
> >VPython although if you want to do this for graduate work be 
> my guest 
> >it would prob. work better.
> >
> >-michael
> 
> 
> _______________________________________________
> Visualpython-users mailing list 
> Vis...@li...
> http://lists.sourceforge.net/lists/listinfo/visualpython-users
> 

RE: [Visualpython-users] Persistance

[David S. <dsc...@vy...>]

There is support in visual/__init__.py for pickling vectors:

import copy_reg
copy_reg.pickle(cvisual.VectorType, lambda v: (vector, tuple(v)),
vector)

It seems likely that someone could do something similar to support
pickling of graphics objects without having to add support to cvisual
itself.

Dave

> -----Original Message-----
> From: vis...@li... 
> [mailto:vis...@li...] On 
> Behalf Of Ryan Martens
> Sent: Thursday, July 19, 2001 10:47 AM
> To: vis...@li...
> Subject: [Visualpython-users] Persistance
> 
> 
> Is there any way in VPython to store graphics objects with 
> persistance?  If not, has anyone written a routine, where the 
> objects in the current scene can be loaded or saved from 
> stored data?  I will be generating a default model from other 
> data input by the user.  The user will then be able to make 
> some modifications to this model, and I would like to be able 
> to save any changes. Thanks again, Ryan
> 
> 
> _______________________________________________
> Visualpython-users mailing list 
> Vis...@li...
> http://lists.sourceforge.net/lists/listinfo/visualpython-users
> 

RE: [Visualpython-users] Importing/Mouse Events

[Ryan M. <RMA...@md...>]

How possible would it be to import non-primitive VRML objects using the =
convex object?  I realize that you would be limited to convex objects, but =
it would be a good start on visualizing the object.

Ryan

>So there is a Python VRML97 parser at
>http://members.home.com/mcfletch/programming/mcf_vrml.htm
>
>which looks promising.  If I have time this weekend I was thinking about
>writing a simple VRML importer (i.e. - primative->primatve ) to VPython
>although if you want to do this
>for graduate work be my guest it would prob. work better.
>
>-michael

[Visualpython-users] Persistance

[Ryan M. <RMA...@md...>]

Is there any way in VPython to store graphics objects with persistance?  =
If not, has anyone written a routine, where the objects in the current =
scene can be loaded or saved from stored data?  I will be generating a =
default model from other data input by the user.  The user will then be =
able to make some modifications to this model, and I would like to be able =
to save any changes.
Thanks again,
Ryan

Re: [Visualpython-users] Importing/Mouse Events

[Michael Z. K. <mz...@an...>]

So there is a Python VRML97 parser at
http://members.home.com/mcfletch/programming/mcf_vrml.htm

which looks promising.  If I have time this weekend I was thinking about
writing a simple VRML importer (i.e. - primative->primatve ) to VPython
although if you want to do this
for graduate work be my guest it would prob. work better.

-michael

On Wed, 18 Jul 2001, Ari Heitner wrote:

> On Wed, Jul 18, 2001 at 12:31:30PM -0400, Ryan Martens wrote:
> > I'm new to VPython, and must add that I'm quite impressed.  I'm currently
> > developing a program for defining 3D systems for simulations, and need
> > software for viewing and working with the 3D models (primarily viewing
> > though).  I was wondering how the internal geometry is stored in VPython. 
> > Is there a way that this data can be manipulated, such as when importing
> > data from other file formats?  In my program, systems will intiially be
> > defined as bodies consisting of simple objects, but when CAD drawings
> > become available, it would be ideal to be able to import more complex
> > objects to replace these simple objects.
> 
> right now the only Visual objects are geometric primitives; there isn't any
> way to import models from a CAD program. This is a deficiency and one I'd
> love to fix. There's a small chance I'll do it this coming semester (for
> credit needed to graduate, so I'll hvae some chance of getting it done).
> 
> > Furthermore, is there a way to capture events such as mouse clicks
> > (primarily the right mouse button), and get the mouse position.  I would
> > need to override the default response of rotation.
> 
> look at the stonehenge demo program for a way of overriding the default
> navigation system.
> 
> 
> 
> cheers,
> ari
> 
> _______________________________________________
> Visualpython-users mailing list
> Vis...@li...
> http://lists.sourceforge.net/lists/listinfo/visualpython-users
> 

RE: [Visualpython-users] Importing/Mouse Events

[McDermid, R. <Rob...@em...>]

> that's what you guys use that weird little clover-leaf button 
> for, right?
> because it's obviously more intuitive :) (gotta be, since 
> Apple came up with
> it)
> 
> sorry, i couldn't help but laugh at this one.
> 
Don't laugh too hard.  Up until windows 95 came along, the windows gui only
used a single button even though every single PC mouse (including the
Microsoft
mouse) has at least two buttons.  Yeah, individual apps could use the right
mouse
button, but windows itself didn't.  To my mind OS/2 is still the only OS
that
makes really intelligent use of the right mouse button (and I include Unix
in
that assessment).

Re: [Visualpython-users] Importing/Mouse Events

[Ari H. <ahe...@an...>]

On Wed, Jul 18, 2001 at 03:49:47PM -0400, Bruce Sherwood wrote:
> --On Wednesday, July 18, 2001 2:05 PM -0400 David Scherer 
> <dsc...@vy...> wrote:
> 
> > continuous zoom.  Both mouse buttons is also an option.
> 
> Not on a one-button Mac mouse.....

that's what you guys use that weird little clover-leaf button for, right?
because it's obviously more intuitive :) (gotta be, since Apple came up with
it)

sorry, i couldn't help but laugh at this one.



ari

RE: [Visualpython-users] Importing/Mouse Events

[Bruce S. <ba...@an...>]

--On Wednesday, July 18, 2001 2:05 PM -0400 David Scherer 
<dsc...@vy...> wrote:

> Many mice now have scroll wheels, which could be used either for zooming
> in discrete chunks or holding down the scroll wheel and dragging for
> continuous zoom.  Both mouse buttons is also an option.

Not on a one-button Mac mouse.....

> I did the latter in an unreleased version of Visual that I used for some
> other things.  I also did some work on the other input stuff.  If I have
> some time maybe I can get that stuff checked in.

Great!

Bruce Sherwood

RE: [Visualpython-users] Importing/Mouse Events

[David S. <dsc...@vy...>]

> Also, it seems desirable to change the default navigation 
> options so as not 
> to use left down for zoom but something else (say CTRL left down). I 
> observe that most people are disconcerted to have to drag 
> with the mouse 
> button up -- no other applications work that way. (To 
> everyone: do you have 
> a better suggestion than CTRL left down for zoom?)

Many mice now have scroll wheels, which could be used either for zooming
in discrete chunks or holding down the scroll wheel and dragging for
continuous zoom.  Both mouse buttons is also an option.

I did the latter in an unreleased version of Visual that I used for some
other things.  I also did some work on the other input stuff.  If I have
some time maybe I can get that stuff checked in.

Dave

Re: [Visualpython-users] Importing/Mouse Events

[Bruce S. <ba...@an...>]

See the VPython documentation, both at the web site and accompanying the 
application.

Unfortunately at present mouse interactions are not nearly complete. All 
you can get is current mouse position, and clicks for the left button. This 
obviously should be generalized to include the right button, and being able 
to interrogate the current state (up/down) for both buttons.

Also, it seems desirable to change the default navigation options so as not 
to use left down for zoom but something else (say CTRL left down). I 
observe that most people are disconcerted to have to drag with the mouse 
button up -- no other applications work that way. (To everyone: do you have 
a better suggestion than CTRL left down for zoom?)

I'm not sure about keypresses.....

One thing I've done in some of my programs is make a button to click on, 
using a sphere or box with a label.

Bruce Sherwood

--On Wednesday, July 18, 2001 1:22 PM -0400 Ryan Martens 
<RMA...@md...> wrote:

> Thanks for your response.  Is there a way of distinguishing between the
> various buttons (i.e. knowing whether or not it was the left or right
> mouse button that was clicked)?  Furthermore, can you get keyboard input,
> so that a menu could appear when a certain key was pressed.

Re: [Visualpython-users] Importing/Mouse Events

[Ryan M. <RMA...@md...>]

>> Furthermore, is there a way to capture events such as mouse clicks
>> (primarily the right mouse button), and get the mouse position.  I =
would
>> need to override the default response of rotation.
>
>look at the stonehenge demo program for a way of overriding the default
>navigation system.

Thanks for your response.  Is there a way of distinguishing between the =
various buttons (i.e. knowing whether or not it was the left or right =
mouse button that was clicked)?  Furthermore, can you get keyboard input, =
so that a menu could appear when a certain key was pressed.

Re: [Visualpython-users] Importing/Mouse Events

[Ari H. <ahe...@an...>]

On Wed, Jul 18, 2001 at 12:31:30PM -0400, Ryan Martens wrote:
> I'm new to VPython, and must add that I'm quite impressed.  I'm currently
> developing a program for defining 3D systems for simulations, and need
> software for viewing and working with the 3D models (primarily viewing
> though).  I was wondering how the internal geometry is stored in VPython. 
> Is there a way that this data can be manipulated, such as when importing
> data from other file formats?  In my program, systems will intiially be
> defined as bodies consisting of simple objects, but when CAD drawings
> become available, it would be ideal to be able to import more complex
> objects to replace these simple objects.

right now the only Visual objects are geometric primitives; there isn't any
way to import models from a CAD program. This is a deficiency and one I'd
love to fix. There's a small chance I'll do it this coming semester (for
credit needed to graduate, so I'll hvae some chance of getting it done).

> Furthermore, is there a way to capture events such as mouse clicks
> (primarily the right mouse button), and get the mouse position.  I would
> need to override the default response of rotation.

look at the stonehenge demo program for a way of overriding the default
navigation system.



cheers,
ari

[Visualpython-users] Importing/Mouse Events

[Ryan M. <RMA...@md...>]

I'm new to VPython, and must add that I'm quite impressed.  I'm currently =
developing a program for defining 3D systems for simulations, and need =
software for viewing and working with the 3D models (primarily viewing =
though).  I was wondering how the internal geometry is stored in VPython.  =
Is there a way that this data can be manipulated, such as when importing =
data from other file formats?  In my program, systems will intiially be =
defined as bodies consisting of simple objects, but when CAD drawings =
become available, it would be ideal to be able to import more complex =
objects to replace these simple objects.
Furthermore, is there a way to capture events such as mouse clicks =
(primarily the right mouse button), and get the mouse position.  I would =
need to override the default response of rotation.
Thanks a lot in advance.

[Visualpython-users] New version of vrmlexport

[Michael Z. K. <mz...@an...>]

I have released a new version of vrmlexport which now uses extrusions to
render curves.  

You can grab the new version at http://www.andrew.cmu.edu/~mzk/vrmlexport/

-Michael