View this page "2D Drawing Primitives module"

[fccoelho]

Hi Everyone,

I have created a page linking to a 2D drawing primitives module for
pyglet I've put together. I you are interested...

Click on http://groups.google.com/group/pyglet-users/web/2d-drawing-primitives-module
- or copy & paste it into your browser's address bar if that doesn't
work.

[dio...@gmail.com]

Problems on my MacBook Pro with ATI X1600:
-If I make a line with stroke 10, and an arc with stroke 1, the arc
gets drawn very oddly, with different strokes.
-Arcs are drawn with 180-degree flip every other frame

My test code is at http://rafb.net/p/dRRA7922.html - at least for the
next 24 hours.

[dio...@gmail.com]

I figured out one issue: in Arc.render(), insert "glLineWidth(1.0"
just after "start -= 180". That will stop the line thickness
weirdness.

I tried duplicating your code into a non-object-oriented function of
my own, and the problem disappears. I'm still trying to figure this
one out.

[Jeff Hester]

This is great! Thanks for sharing. I'm running into a issue
(probably a bug in my brain). I'm trying to display an image (based
on the excellent image_display.py that's included with pyglet.) From
my code I'm just importing from primitives.py and trying to draw
objects on top of the image. I'm using default objects from the
"main" area of primitives.py. When I blit my background image with
the objects to the screen it is always tinted the same color as the
last primitive I drew and makes the whole window that color. I know
there is something simple I'm missing. Can someone please steer me on
the right path? Thank you greatly.

[Rod Hyde]

What you need to remember is that pyglet uses OpenGL which is effectively a state machine. This means it will "remember" certain things, otherwise you'd have to specify them all every time you made an OpenGL call. In other words, you tell it things like the current colour, texture, drawing mode, etc, and it remembers them.

In this case, your problem will almost certainly be solved by resetting the colour to white prior to blitting.

--- Rod

[Rod Hyde]

Incidentally, there's a rather large diagram that shows the OpenGL 1.1 state machine here:

http://www.opengl.org/documentation/specs/version1.1/state.pdf

It is quite useful as it shows where commands have an effect in the OpenGL pipeline.

--- Rod

[Txema Vicente]

May be you need a glColor4f(1,1,1,1) after the last primitive you drew.

> --
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.5.516 / Virus Database: 269.20.4/1275 - Release Date:
> 12/02/2008 15:20
>
>

[Jeff Hester]

Thank you all. I apologize for wasting everyone's time. (Know that
this will help someone else I'm sure.)

I had went off and determined that I had left off changing my color
back with glColor4f(1,1,1,1).

When I came back to "cancel" my request I see where it was already
addressed. Very good.

Pyglet is very impressive and I will be a lifelong user. I've been
with Python for years.

I hope to be able to contribute to the list for others. God bless.

-- Jeff

[Patrick Devine]

I've been pretty disappointed with the 2d drawing primitives that are
out there right now so I set about writing my own. I wanted to
somewhat replicate pygame's functionality and have cleaner code which
was as well documented as pyglet. So far I've implemented rect(),
circle(), ellipse(), line() and lines(). I still need to get around
to polygon() and arc(), but I would imagine I can finish those up this
weekend if anyone is interested.

Also, I'm not (yet) optimizing with display lists but I would imagine
the code could be modified to do that as well.

Let me know if anyone is interested.

--Patrick.

[simpsus_science]

I like Flavios work very much, but I too think it could be improved a
bit.
I would definetely be interested in what you are suggesting

[Drew Smathers]

I think a 2D drawing primitives shim library might make sense for a very simple 2D application - a Logo-like game or something.  In such instances, "optimizing" with display lists would be almost silly, though.

In other applications, building more complex structures out of the functions provided by a 2D primitives shim library would almost never be a good idea.  For a structure build out of 10,000 lines, for example, you wind up an excess 10,000 function calls just for a little API gloss.  And (unless your interfaces are really weird, which would defeat the point), you end up with 10,000 glBegin/glEnd pairs instead of one - and I don't think display lists cut out such redundancies.

There is also very little difficulty in making such abstractions (with the exception of tessellated polygons, b-splines, etc.), so I personally would put it in a utils module per application, rather than imposing another dependency and worry about deployment and potential licensing conflicts.

Cheers,

--
\\\\\/\"/\\\\\\\\\\\
\\\\/ // //\/\\\\\\\
\\\/ \\// /\ \/\\\\
\\/ /\/ / /\/ /\ \\\
\/ / /\/ /\ /\\\ \\
/ /\\\ /\\\ \\\\\/\
\/\\\\\/\\\\\/\\\\\\
d.p.s

[Alec Thomas]

On 16/02/2008, Drew Smathers <drew.s...@gmail.com> wrote:
> I think a 2D drawing primitives shim library might make sense for a very
> simple 2D application - a Logo-like game or something. In such instances,
> "optimizing" with display lists would be almost silly, though.
>
> In other applications, building more complex structures out of the functions
> provided by a 2D primitives shim library would almost never be a good idea.
> For a structure build out of 10,000 lines, for example, you wind up an
> excess 10,000 function calls just for a little API gloss. And (unless your
> interfaces are really weird, which would defeat the point), you end up with
> 10,000 glBegin/glEnd pairs instead of one - and I don't think display lists
> cut out such redundancies.
>
> There is also very little difficulty in making such abstractions (with the
> exception of tessellated polygons, b-splines, etc.), so I personally would
> put it in a utils module per application, rather than imposing another
> dependency and worry about deployment and potential licensing conflicts.

I disagree entirely.

There are plenty of times, particularly when prototyping, when you
want to be able to quickly draw a circle, an ellipse, arcs, etc. A
library like this would be very useful.

If the code is small enough to go in a single .py it would be perfect,
you could simply drop it into your project and off you go.

So +1 from me.
--
Evolution: Taking care of those too stupid to take care of themselves.

[Tartley]

Yeah, one might be rendering polygons and stuff for a Geographic
Information System (maps), for example. You'd want it to be as fast it
can be, but it needn't be 60fps. Composition using primitives like
this might be a perfect compromise between execution speed and
development speed.

[Drew Smathers]

On Fri, Feb 15, 2008 at 6:51 PM, Alec Thomas <al...@swapoff.org> wrote:

> I disagree entirely.
>
> There are plenty of times, particularly when prototyping, when you
> want to be able to quickly draw a circle, an ellipse, arcs, etc. A
> library like this would be very useful.
>

I'm scratching my head wondering how you "entirely disagree" with me.
I like prototyping too. I also like hacking up things quickly -
that's why I dig Python. I also think libraries with good interfaces
can be very useful.

In retrospect, though, I disagree with myself - or the version of
myself on Feb. 16th. Namely:

>> In other applications, building more complex structures out of the functions
>> provided by a 2D primitives shim library would almost never be a good idea.

It actually might be a good idea if the library is structured in such
a way to make grouping your drawing operations efficient - and without
invoking large amount of *magic* leading to unforeseen corner cases.
I've thought of 2 ways to do this - I'm sure there are more.