visualpython-users

[Visualpython-users] JPEG Snapshots/Raytracing: out of control :)

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

I figured I better clear this up before it gets any more absurd.

1) Raytracing. If the only reason you want to raytrace is to have a picture
of what's on the screen, for goodness sake *TAKE A SCREENSHOT*.
Ctrl-Alt-whatever in windows, use the xwd(1x) utility in Unix[1]. I *still*
haven't heard why anyone wants to make raytracings in the first place -- it
seems like a lot of work if all you want is textures. And without textures,
it's not going to look any different than the GL renderings.

2) Non-interactive mode (i.e. what you'd use to make VPython a cgi script).
This presents a real problem. Typically a cgi script is run as user nobody.
VPython wouldn't be happy under those circumstances -- it needs control of
the console and X running -- in short, it needs the DISPLAY environment
variable validly set. The Visual library was *not* designed to be run in any
non-interactive mode. Like I said, it would be easy enough to hack Visual
not to render anything except when the controlling thread requests it to.
But it would still want to render to a GL context -- not good for a cgi
script. If you were willing to forgo any pretense of security (read: Ari
says this is a *bad* idea) you could have the cgi run as a user with some
level of priviledge, leave that user in control of the console with xhost
set appropriately, and have the script set DISPLAY correctly before
launching Python. Then the script could use xwd(1x) from the command line to
capture the contents of the Visual window to a file, and do whatever you
want with it. This is a hack. I take no responsibility for anyone who
actually *tries* this.




Cheers,

-- 
Ari Heitner
  DC: 703/5733512  PGH: 412/4229837
Non c'è più forza nella normalità: c'è solo monotonia.

[1]: (I note that while *I* have only compiled VPython for Linux, I personally
guarantee you it will work fine on Solaris or anything else reasonably sane
with the full environment)

RE: [Visualpython-users] Snapshots/Raytracing: Ari out of control :)

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

> I figured I better clear this up before it gets any more absurd.

I figured I better clear this up before it gets any more absurd :)

> 1) Raytracing. If the only reason you want to raytrace is to have
> a picture
> of what's on the screen, for goodness sake *TAKE A SCREENSHOT*.
> Ctrl-Alt-whatever in windows, use the xwd(1x) utility in Unix[1].
> I *still*
> haven't heard why anyone wants to make raytracings in the first
> place -- it
> seems like a lot of work if all you want is textures. And without
> textures,
> it's not going to look any different than the GL renderings.

Wrong.  Raytracers use analytic curved surfaces, so they will render much
better spheres, etc.  They can do specular highlights, reflection,
refraction, and all manner of other neat stuff with materials.  As I noted
in another e-mail, there's no reason that some extra attributes can't be
tacked on to Visual objects to control these features.

I think it's an excellent idea.  I just don't have time to do it myself.

> 2) Non-interactive mode (i.e. what you'd use to make VPython a
> cgi script).
> This presents a real problem. Typically a cgi script is run as
> user nobody.
> VPython wouldn't be happy under those circumstances -- it needs control of
> the console and X running -- in short, it needs the DISPLAY environment
> variable validly set.

Every GL implementation I've seen (I confess to not knowing anything about
Mesa) can create a GL context pointing at an offscreen surface and software
render to it.  I would be very surprised to learn that no one has ever
implemented a CGI script that way.

> The Visual library was *not* designed to be run in any
> non-interactive mode.

Since I designed it, I think I can confidently say that it *was* designed
with similar things in mind.  They just haven't been implemented.  If
someone is willing and competent to write some C++ code to do this, I will
be happy to explain exactly how it can be done.

> If you were willing to forgo any pretense of security (read: Ari
> says this is a *bad* idea)

Yes, this is a bad idea.  However, the existence of a bad solution doesn't
prove the nonexistence of a good solution.

Dave

Re: [Visualpython-users] Snapshots/Raytracing: Ari out of control :)

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

On Thu, Oct 19, 2000 at 01:07:59PM -0400, David Scherer wrote:
> 
> Wrong.  Raytracers use analytic curved surfaces, so they will render much
> better spheres, etc.  They can do specular highlights, reflection,

mph. picky picky :) i guess i'm just a bit jaded to raytracers.

> refraction, and all manner of other neat stuff with materials.  As I noted

true enough. i would hate to see a lot of effort go into good material
support for raytracers before Visual comes anywhere near exhausting the
flexibility of GL in that area. 

Of course people may feel comfortable implementing a povray exporter but not
hacking GL. There's actually something very useful to be done here: the main
difficulty in implementing textures and better material support in Visual
itself is the interface -- the GL is easy enough to write the question is
how to make the Python interface intuitive. If someone were to iterate
through and develop a nice interface on top of Visual for adding attributes
for raytracing, it would be a big help for implementing a similar interface
for materials in Visual. The timing even lines up: by the time a preliminary
raytracing interface was ready, I might actually have time to work on GL
material support.

> 
> Every GL implementation I've seen (I confess to not knowing anything about
> Mesa) can create a GL context pointing at an offscreen surface and software
> render to it.  I would be very surprised to learn that no one has ever
> implemented a CGI script that way.

good point. /me is clearly not thinking.

Mesa supports this of course.

unfortunately GtkGLArea is not likely to be very happy -- Gtk does want a
display. Was there a good reason we were using Gtk as opposed to straight
GLX?






ari