I'm looking at writing a new renderer for processing, and it looks like all that needs to happen to get it to be used in a sketch is to do:
size(200,200,"my.library.class");
and it magicly works (assuming that my.library.class extends PGraphics/3/GL/whatever).

Is this likely to work concistently, or is it pure chance that it works for an external library?

I'm making tenetive steps towards writing a pure GL library for myself, to see what sorts of speeds I can get out of it. It's not likely to be a complete translation of the current PGraphicsGL though, since that looks way over my head.

The reason I want to start from scratch is that PGraphicsGL is fairly hefty, and relies on parts of PGraphics3, so it's really hard to work out how on earth everythign actually works.

I am probably going to start by gutting a copy of PGraphicsGL, and sticking what bits of GL I know into it, and see how far I get

Is there anything in the source tree that has a list of the minimum set of methods needed to do everything?
I know that above and beyond all the user-side calls, there's beginFrame and endFrame, is there anything else behind the scenes that needs to exist, that's done on a per-frame basis?

I'm going to leave all the requestDisplay/allocate stuff along from PgraphicsGL, just wondering what things are necessary, like is handle_lighting required, or just for convenience of splitting the code up to modular pieces?

So far all I've got is a whole bunch of ideas, and a passing knowledge of how the current PGraphicsGL works, and what it does natively, and what it forks off to PGraphics3. Not actually written anything other than a test to get pure GL lighting.

From my investigations, the lighting is almost entirely useable, it just needs the PG3 parts culling, and versions writing that do no matrix munging.

The vertex stuff is similar, except GL has a native QUAD mode so quads don't need to be triangulated, and again the matrix stuff needs to go bye-bye. Also the vertex colour stuff needs a tweak, to get ambient/specular/shininess working properly for GL, not having PG3 work out the vertex colour beforehand.

camera/frustrun/perspective/translate/rotate/scales et al need converting to gl equivalents, but I think there's a fairly simple mapping. (e.g. gluLookAt/glVertexf/glRotatef) for most.

All the texture stuff is probably fine, but maybe in the translation the image corruption stuff might get sorted.

Quote:

generally it's easy to map the first 70 or 80%, but there's a nasty remaining bit that is quite a headache, which is why i'm not doing this by default in PGraphicsGL. obviously i'd much prefer that everything was native calls to GL, but to properly support 100% of the p5 api, it gets very messy. since you're not doing the base GL class for everyone, you have the luxury of leaving out some bits.

for instance, beginShape() with with a fill() and QUADS maps to the GL call. but what happens when you want a stroke() in there as well? you have to make the set of calls twice. which isn't a big deal but starts getting pretty messy for the list of all the gl calls to support.

later, getting lighting to match between P3D and OPENGL is a considerable headache (i think there are notes about this in the javadocs).

as for the minimum set of methods, it's essentially the set of public methods in the PGraphics object. the PMethods.java file is and empty source file but contains my notes on what the api looked like, though i think it's now out of date (and soon to disappear from svn). look at PApplet for everything that gets a g.whatever() method added to the end (the auto-generated stuff). and if you have questions about whether one thing or another needs to be included, just ask.

I solved the stroke fill issuse using display lists, but of course there remain problems like the drawing of transparent shapes, so I don't see a pure OPENGL renderer as a replacement for PGraphicsGL.

According PGraphics, I really spent some time watching the different Renderers and I know that this is very complex. But I thought the seperation of the pure rendering process and the setting of modes, calculating of colors could give more possibilities in extending things. So for example one could extend PGraphics with methods to directly draw shapes using vectors, without effecting the other renderers. So far you would have to build a wrapper that gets a PGraphics instance, wraps all its methods and adds vector support, thats what I actually did for my vector lib. Of course this all does more affect the advanced use of processing core in an ide. That was just a thought, but it would definetly make sense to make more fields of PGraphics protected so that you can access them in classes that extend PGraphics.

According to this where do you see possibilities to extend processing? I would really like to join the workshop in Barcelona and take sometime to think about further developments before.

Quick update, I've now for real go lighting sorted.. previously my version got confused if you had both directional and spotlights in a scene together.

Also, because I've managed to remove the processing matrix fiddling, GLSL shaders can be used and will give the epxected results.. and these work in applets if your video card supports them.

So that means it's possible to have per-pixel lighting. And possibly shadowing, but that'll require a fair chunk of work I think. Anyway, here's some eye-candy:

http://www.hardcorepawn.com/NewGL/

I think it's a firefox issue rather than a Java one. I had that problem with the original non-sun-endorsed JOGLAppletLauncher, but not with the current one, hoewver I've moved to firefox 1.5 since then.

What version of firefox are you using?