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

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
>

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

[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

[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

[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...>]

[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 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...>]

> 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

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

--On Sunday, July 22, 2001 14:45 -0400 Ari Heitner 
<ahe...@an...> wrote:

> and hexahedrons ...i didn't even know we had a hexahedron
> primitive

This object is undocumented and should be yanked. It was an early test 
version of what eventually became "convex".

Bruce Sherwood