Re: [pygame] New transformations for future Pygame releases
Richard Goedeken wrote: It appears that AGG does not have a function to do what Ian was asking for though - transforming a rectangle to an arbitrary quadrilateral. Actually he was really asking for a perspective projection, which you can't do properly with a linear interpolation. I'd be surprised to find this in any 2D graphics library, as it really belongs to the world of 3D. -- Greg
Re: [pygame] New transformations for future Pygame releases
On Mon, Mar 10, 2008 at 2:13 PM, Greg Ewing [EMAIL PROTECTED] wrote: Actually he was really asking for a perspective projection, which you can't do properly with a linear interpolation. I'd be surprised to find this in any 2D graphics library, as it really belongs to the world of 3D. Yep, that was the application I was wishing to use it for, but it could be used in other fields. Anyway, a stretch that only works in two directions makes no sense. -- Greg Ian
Re: [pygame] New transformations for future Pygame releases
On Sun, Mar 9, 2008 at 10:58 AM, Richard Goedeken [EMAIL PROTECTED] wrote: impressive. It appears that AGG does not have a function to do what Ian was asking for though - transforming a rectangle to an arbitrary quadrilateral. What it can do, though, is transform a rectange to an arbitrary parallelogram. look here: http://antigrain.com/demo/image_perspective.jpg the perspective mapping is optional, it can do bilinear mapping to an arbitrary quad. in fact, you probably just want to browse all these: http://antigrain.com/demo/index.html trust me, agg has it all. moreover, since it's really just a c++ template based graphics pipeline system, it's really pretty easy to extend. However it's not really a library of various operations either - if pygame were to use it, it's not an issue of making binding to feature X, it's an issue of putting together the appropriate pieces to do the desired operation.
Re: [pygame] New transformations for future Pygame releases
On Mar 9, 2008, at 10:58 AM, Richard Goedeken wrote: Brian Fisher wrote: If were going to have something like that (a warping function) in PyGame, I would definitely want it to use anti-grain-geometry (http://antigrain.com ) rather than use a newly coded up function. AGG has been around for a very long time, is highly tested, and once you code up the basic integration issues a huge world of completely awesome 2d software rendering falls out fairly easily (gaussian blur, vector shape rendering, textured lines, etc. etc.) I was previously unaware of this project; thanks for the link. It looks quite impressive. It appears that AGG does not have a function to do what Ian was asking for though - transforming a rectangle to an arbitrary quadrilateral. What it can do, though, is transform a rectange to an arbitrary parallelogram. If I understand this screenshot correctly, I think it does do that: http://antigrain.com/screenshots/perspective1.gif (Labelled: 2D Bilinear transformations in a quadrangle) It also seems to be able to do some non-linear distorts: http://antigrain.com/screenshots/perspective5.jpg http://antigrain.com/screenshots/distortions.jpg very cool. -Casey
Re: [pygame] New transformations for future Pygame releases
On Mar 9, 2008, at 10:58 AM, Richard Goedeken wrote: Brian Fisher wrote: If were going to have something like that (a warping function) in PyGame, I would definitely want it to use anti-grain-geometry (http://antigrain.com ) rather than use a newly coded up function. AGG has been around for a very long time, is highly tested, and once you code up the basic integration issues a huge world of completely awesome 2d software rendering falls out fairly easily (gaussian blur, vector shape rendering, textured lines, etc. etc.) I was previously unaware of this project; thanks for the link. It looks quite impressive. It appears that AGG does not have a function to do what Ian was asking for though - transforming a rectangle to an arbitrary quadrilateral. What it can do, though, is transform a rectange to an arbitrary parallelogram. Seems like some folks (Fredrik Lundh among them) have made some agg wrappers for python: http://effbot.org/zone/aggdraw-index.htm http://tachyon.in/davinci/ The latter one is part of a larger package. Fredrik's includes an api to do affine transforms. -Casey
Re: [pygame] New transformations for future Pygame releases
On Sun, Mar 9, 2008 at 11:28 AM, Richard Goedeken [EMAIL PROTECTED] wrote: Yep, you're right; I was looking in the wrong place. AGG does look quite impressive. It's big enough that it probably deserves its own pygame module if it were to be integrated. One possible concern that should be considered is speed. Since pygame is designed for games, these operations need to be fast enough to be practical for pygame-based games. Usually there is a trade-off between speed and quality, and it looks like AGG is targeting maximum image quality. I have a fair bit of experience using AGG for real-time 2D games, and because of it's configureable-templated-pipeine architecture, it's really trivial to pick between the higher-quality but slower solution and the much faster solution for whatever piece of an operation you want to configure. Maxim (the author) definitely put a lot of time into making pieces that do very high-quality rendering, but he has also done a lot of performance/optimization work as well, so in general there is very little left to optimize vs. agg code in terms of how you write the code. It's more about what operation you choose to do.
Re: [pygame] New transformations for future Pygame releases
On Sun, Mar 9, 2008 at 11:24 AM, Casey Duncan [EMAIL PROTECTED] wrote: Seems like some folks (Fredrik Lundh among them) have made some agg wrappers for python: http://effbot.org/zone/aggdraw-index.htm http://tachyon.in/davinci/ The latter one is part of a larger package. Fredrik's includes an api to do affine transforms. There are 2 basic problems with all existing bindings to agg code when it comes to using them with pygame. The first is they don't have tight integration with pygame surfaces (wouldn't it be great to just simply draw one surface rotated scaled and colored onto another? how about being able to use a pygame surface as the texture for a line? how about using a pygame surface as the texture for a filled shape?) The second is that there is no canonical set of agg features to bind to - in my opinion it's better to think of agg as the first place to go to get code to implement whatever rendering feature you want (it lets you start solving your rendering problem at a very high level to start)
Re: [pygame] New transformations for future Pygame releases
On Mar 9, 2008, at 12:17 PM, Brian Fisher wrote: On Sun, Mar 9, 2008 at 11:24 AM, Casey Duncan [EMAIL PROTECTED] wrote: Seems like some folks (Fredrik Lundh among them) have made some agg wrappers for python: http://effbot.org/zone/aggdraw-index.htm http://tachyon.in/davinci/ The latter one is part of a larger package. Fredrik's includes an api to do affine transforms. There are 2 basic problems with all existing bindings to agg code when it comes to using them with pygame. The first is they don't have tight integration with pygame surfaces (wouldn't it be great to just simply draw one surface rotated scaled and colored onto another? how about being able to use a pygame surface as the texture for a line? how about using a pygame surface as the texture for a filled shape?) Certainly, I mostly pointed them out in case they would be useful to the original poster or useful as jumping off points for a tighter integration with pygame. I think such features tightly integrated with pygame surfaces would be phenomenal. OTOH, it might make more sense to just do such operations on the GPU (which afaict agg does not leverage), granted that may be less portable. The second is that there is no canonical set of agg features to bind to - in my opinion it's better to think of agg as the first place to go to get code to implement whatever rendering feature you want (it lets you start solving your rendering problem at a very high level to start) So rather than integrate with agg, per se, just reimplement the desired algorithms in pygame? Obviously not having another dependancy is highly desirable, guess it just depends on suitable volunteer motivation. -Casey
Re: [pygame] New transformations for future Pygame releases
On Sun, Mar 9, 2008 at 1:26 PM, Casey Duncan [EMAIL PROTECTED] wrote: Certainly, I mostly pointed them out in case they would be useful to the original poster or useful as jumping off points for a tighter integration with pygame. I think such features tightly integrated with pygame surfaces would be phenomenal. OTOH, it might make more sense to just do such operations on the GPU (which afaict agg does not leverage), granted that may be less portable. well If there was a bunch of rendering api's that pygame provided that rendered to software surfaces, you could make a hardware supported implementation of them for hardware surfaces I suppose - but the fact of the matter is if you would want such api's to work with software surfaces at all you would need some software implementation, and that is where agg provides value. So rather than integrate with agg, per se, just reimplement the desired algorithms in pygame? Obviously not having another dependancy is highly desirable, guess it just depends on suitable volunteer motivation. I think I must not be making things very clear - there is no such thing as an agg binary to link to. It does not exist in library form. It's basically source code for a butt load of sweet rendering algorithms. If it was used to implement some pygame drawing stuff, it would not be an additional dependency, in that relevant sources would be added to pygame svn, and nobody would have to reimplement desired algorithms where Maxim already implemented them.
