Mailing List Archive

srenner@lycosmail.com wrote:
[SNIP]
> If you've read this far, you might be interested in doing an open source
> collaborative project. Here are some ideas:
>
> *Various projects based on my attention-renderer, already released in
> the PyOpenGL demo directory. (There's a new release coming soon). This
> already implements some new ideas, like infinitely detailed objects.
> (You know, fractals.) 
>
> *How about a ray-tracer or scanline renderer in pure Python? It would
> be dead slow but interesting to write, especially the shaders. I've
> rejected this before because my realtime renderer seemed more
> interesting, but if others want to work on this I say let's do it. (Did
> I mention radiosity?)

Ray tracer in Python is cool but purposeless. Why not write the renderer in C
and have an embedded Python interpreter that allows for:

a) Procedural objects - e.g object/ray intersection code calls a python function
to do the work. that allows for REALLY nifty objects, and you can add more
without recompiling the renderer

b) Procedural textures -- you get the idea

c) New input formats. If you expose the internal c objects to the embedded
python, you can have the python load a new file type and set up the internal
data structures

d) high-level animation scripting. mmmmm...animation...mmmmm.

BTW...apparently TrueSpace now has an embedded Python interpreter. Don't know
how far they took it tho.

About radiosity: The very thought of doing something that compute-intensive in
pure python makes my processor wilt in fear. Again, a multi-language route
would seem to be a better way to go.

> *If you happen to have a retinal display with eye movement tracking JUST
> LYING AROUND please mail me IMMEDIATELY.

You funny.

--
o Mordy Ovits
o Cryptographic Engineer
o LockStar Inc.
---------------------------------------------------------------------------
#!/usr/local/bin/python
from sys import*;from string import*;a=argv;[s,p,q]=filter(lambda x:x[:1]!=
'-',a);d='-d'in a;e,n=atol(p,16),atol(q,16);l=(len(q)+1)/2;o,inb=l-d,l-1+d
while s:s=stdin.read(inb);s and map(stdout.write,map(lambda i,b=pow(reduce(
lambda x,y:(x<<8L)+y,map(ord,s)),e,n):chr(b>>8*i&255),range(o-1,-1,-1)))

On Mon, 10 May 1999 20:10:43 GMT, srenner@lycosmail.com
<srenner@lycosmail.com> wrote:

> Does anyone have hardware acceleration working with Linux yet? I have
> been waiting for over a year -- it is always reputed to be just
> around the corner. If anyone wants to do complete 3d toy world/game
> prototyping in Python, the tools are already in place. I should know,
> since that's what I've been spending all my time on.

Having used PyOpenGL for some time for prototyping 3D applications, I
eventually felt more comfortable with writing my own module(s) in C, and
control them from python.

Especially this is a better solution for game programming, as writing a
proper game engine often implies (reasonably) low-level access to mouse and
keyboard handling, as well as conditionally setting up glX or wgl rendering
contexts and whatnot. I find PyOpenGL to be too rigid for high-framerate
interactive 3D graphics.

If you do the OpenGL stuff in C, you can easily enable and set up hardware
acceleration for your application, and your wait is over. :)

--
runeb

srenner@lycosmail.com writes:

> Does anyone have hardware acceleration working with Linux yet? I have
> been waiting for over a year -- it is always reputed to be just
> around the corner. If anyone wants to do complete 3d toy world/game
> prototyping in Python, the tools are already in place. I should know,
> since that's what I've been spending all my time on.

If you are have a 3dfx based graphics card, then 3d hardware
acceleleration+linux+mesa+python works fine. I've had this working for
some time now (toy usage only though).

There were no tricks to getting this to work, just build mesa with
3dfx support, build python, build pyOpenGL, and start coding python.

The major drawback - with the card that I have 3d can only be fully
accellerated with full screen output. Output to a window requires a
copy of the frame, which slows things down alot (but it still much
faster than software only mesa).


--------------------------------------------------------------
Tim Docker timd@macquarie.com.au

> If you are have a 3dfx based graphics card, then 3d hardware
> acceleleration+linux+mesa+python works fine. I've had this working for
> some time now (toy usage only though).
>
> There were no tricks to getting this to work, just build mesa with
> 3dfx support, build python, build pyOpenGL, and start coding python.
>
> The major drawback - with the card that I have 3d can only be fully
> accellerated with full screen output. Output to a window requires a
> copy of the frame, which slows things down alot (but it still much
> faster than software only mesa).
>
> --------------------------------------------------------------
> Tim Docker timd@macquarie.com.au
>

OK, that is somewhat encouraging. How does this full screen stuff
work? Do you have to kill the X server first? And how can you debug
without a shell window?

sr


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---

On Tue, 11 May 1999 01:05:19 GMT, srenner@lycosmail.com <srenner@lycosmail.com> wrote:
>
>
>> If you are have a 3dfx based graphics card, then 3d hardware
>> acceleleration+linux+mesa+python works fine. I've had this working for
>> some time now (toy usage only though).
>>
>> The major drawback - with the card that I have 3d can only be fully
>> accellerated with full screen output. Output to a window requires a
>> copy of the frame, which slows things down alot (but it still much
>> faster than software only mesa).

I've found it to be slower than software Mesa except when using
textures. The Voodoo does texturing blazingly fast. I can easily get
75 FPS (the refresh rate limit) for texture mapped scenes that
have 4 or 5 polygons. When you crank the geometry higher, things slow
down but that's because all ot he geometry work is being done slowly in
software by Mesa.

>
>OK, that is somewhat encouraging. How does this full screen stuff
>work? Do you have to kill the X server first? And how can you debug
>without a shell window?

No, the X server hangs around. The Voodoo card is actually a 3D
passthrough, which mean you plug the output of the 2D video card
into the input of the 3D card, then the output of the 3D card to the
monitor. Basically it just lets all the normal just "pass through"
but when the Voodoo fullscreen mode is activated, it drops te
2D stuff and you only see the 3D fullscreen. WHen you quit the
2D screen comes back as it was originally.

As for debugging: I write and debug in software mode, then
run with the Voodoo card when I want to see it for real.
This is straightforward since you can just load a different
version of MesaGL (the Voodoo version) at runtime using
the LD_LIBRARY_PATH or LD_PRELOAD environment variables.

As an alternative, some serious progress isbeing made on an
X server GLX extension. This works in software mode (it
dynamically loads MesaGL into the X server at runtime)
but now that Matrox has releasd the specs for the G200 some
support for that card is going into the GLX server. This works
quite well, because it renders to an X window. The problems
are
1) It's not highly optimized yet
2) The x server and mesaGL are single process; if you're rendering
and it takes 1 second to render the frame, youlose interactivity
for 1 second each time a frame renders.

Most people are waiting around for PRecision Insight to release
their patches to the linux kernel and XFree x server to enable
direct rendering. This seems to be the most promising infrastructure
for the future.

Dave
--
--------------------------------------------------------------------------------
Email: dek@cgl.ucsf.edu David Konerding WWW: http://picasso.ucsf.edu/~dek
--------------------------------------------------------------------------------
Snail: Graduate Group in Biophysics
Medical Sciences 926, Box 0446
University of California
San Francisco, CA 94143

Xi Graphics is working on commercial hardware accelerated OpenGL for
Linux. I don't have any idea when real releases will be available.
Check out their Web pages: http://www.xig.com/

A company called MetroX is (was?) also working on one. I've head that
this project is basically dead, but I can't confirm that -- might be
FUD. Anyone have better information on MetroX?

Jeremy

On Tue, 11 May 1999 14:15:31 -0400 (EDT), Jeremy Hylton <jeremy@cnri.reston.va.us> wrote:
>Xi Graphics is working on commercial hardware accelerated OpenGL for
>Linux. I don't have any idea when real releases will be available.
>Check out their Web pages: http://www.xig.com/
>
>A company called MetroX is (was?) also working on one. I've head that
>this project is basically dead, but I can't confirm that -- might be
>FUD. Anyone have better information on MetroX?

Both Xig and MetroX have released beta servers supporting hardware accelerated
OpenGL. MetroX has been promising their accelerated server for at least three
and a half years now (that's when I ordered their software OpenGL server),
the beta looks interesting but supports only one card.


--
--------------------------------------------------------------------------------
Email: dek@cgl.ucsf.edu David Konerding WWW: http://picasso.ucsf.edu/~dek
--------------------------------------------------------------------------------
Snail: Graduate Group in Biophysics
Medical Sciences 926, Box 0446
University of California
San Francisco, CA 94143

Jeremy Hylton <jeremy@cnri.reston.va.us> writes:

> A company called MetroX is (was?) also working on one. I've head that
> this project is basically dead, but I can't confirm that -- might be
> FUD. Anyone have better information on MetroX?

Check http://www.metrolink.com/productindex.html. They have had an
"early access release" for Glint cards since January. Other chips were
supposed to be supported soon, but nothing has happened for a while.
--
-------------------------------------------------------------------------------
Konrad Hinsen | E-Mail: hinsen@cnrs-orleans.fr
Centre de Biophysique Moleculaire (CNRS) | Tel.: +33-2.38.25.55.69
Rue Charles Sadron | Fax: +33-2.38.63.15.17
45071 Orleans Cedex 2 | Deutsch/Esperanto/English/
France | Nederlands/Francais
-------------------------------------------------------------------------------