We closed this forum 18 June 2010. It has served us well since 2005 as the ALPHA forum did before it from 2002 to 2005. New discussions are ongoing at the new URL http://forum.processing.org. You'll need to sign up and get a new user account. We're sorry about that inconvenience, but we think it's better in the long run. The content on this forum will remain online.
‹ Previous Topic | Next Topic ›
Page Index Toggle Pages: 1
Custom Rendering Routines (Read 831 times)
ewjordan
Custom Rendering Routines
May 4th, 2007, 12:53am  
Lately I've been considering starting up work on some sort of graphics library that would do things like shadowing, bump/parallax mapping, reflections, etc.  These effects can be pretty cool, and aren't overly difficult to implement, but they are too special purpose for the core, which is why I figured a library was the best place to do them.

However, for most of this stuff there are structural changes that need to take place within the PGraphics3D and/or PTriangle files, since the per-pixel code needs to be altered, but there doesn't seem to be a way to get at this stuff without compiling an entire custom version of the core, and this doesn't really work for a library.

Am I wrong about this?  Is there some way from within a library to set up a modified version of P3D as the renderer?  Or does anyone have any suggestion as to how to structure a library like this?  I suppose any specialized rendering could be added in as a layer on top of P3D, but I suspect that could get a bit messy and there would be a decent amount of overhead, but please, correct me if you think this is actually the best way to do it.

Otherwise, I guess my suggestion would be to allow a subclass of PGraphics3D to be used as the renderer, or at least open up the discussion as to how this might be done.
Back to top
 
 
JohnG
Re: Custom Rendering Routines
Reply #1 - May 4th, 2007, 1:51am  
You need to create a class that extends PGraphics (or PGraphics3D) then you can use it from within processing with:

size(640,480,"mypackage.myPGraphics");

And then all yous vertex/texture/translate etc etc methods will be run from your class (or will fail over to PGraphics if you don't implement them)

However it should be noted, that doing bump mapping in software is SLOW. Really slow. Shadowing doubly so. Reflections too. (For what it's worth, I've done bump mapping in processing before: http://www.hardcorepawn.com/Bump/ (n.b. that's processing ALPHA code unfortunately))

If you really want to do fancy things, use PGraphicsOpenGL and you can just put OpenGL calls into your sketch (with a bit of preparation) to do those things.
Back to top
 
 
davbol
Re: Custom Rendering Routines
Reply #2 - May 4th, 2007, 4:51pm  
I went through the same sort of dilemna when adding additive blending to PTriangle.  I ended up recompiling core for that project, this snippet should explain why:

Quote:


// (really should be in a .java, but works ok here as POC)
class SuperDuperTriangle extends PTriangle {
 public SuperDuperTriangle(PGraphics3D g) {
   super(g);
 }
// the only thing different in this subclass is that the
// reset() method is talkative, merely proof of concept,
 public void reset() {
   super.reset();
   println("SuperDuperTriangle has been reset.");
 }
}

void setup() {
 size(200,200,P3D);
 ((PGraphics3D)g).triangle = new SuperDuperTriangle((PGraphics3D)g);
}

void draw() {
 triangle(10,10,190,100,100,190);
}



Edit:  don't want to suggest that I think hackery like this *should* work, only pointing out that it doesn't.  Smiley
Back to top
« Last Edit: May 4th, 2007, 8:52pm by davbol »  
WWW  
fry
Re: Custom Rendering Routines
Reply #3 - May 4th, 2007, 7:03pm  
to be clear on how those pieces all interact..

consider PTriangle and PLine to be more-or-less private classes of PGraphics3D (P3D). for PGraphics2D (P2D), there's a chance that it'll need access to PLine (that's tbd, and if so, PLine will become a little more general), but it will probably use something like PPolygon for the triangle/poly rendering. PPolygon is the old triangle/poly renderer used for both 2D *and* 3D back in the days of the alpha releases.

the methods are made private and/or final in some cases to that the jvm knows it can inline them during runtime for sake of speed.

the model for subclassing will be such that "PGraphics" will be the base thing that you inherit from, or if your renderer is specifically 2D or 3D, you'll inherit from PGraphics2D or PGraphics3D, which will handle some of the basic functions you need in either case (i.e. drawing curves for 2D or tesselation for 3D).

if you want to build your own 3D renderer, you can start with PGraphics3D, PLine, and PTriangle. put the set of three into another package (or no package) and hack away. the point is, don't expect the interfaces between PGraphics3D and PLine and PTriangle to stay intact--these are not exposed for general use.

and as mentioned by JohnG, the size(w, h, "Your.Package.YourRenderer"); is the proper method to invoke your new beast, that's why the size() command is set up the way it is.
Back to top
 
WWW  
Page Index Toggle Pages: 1
‹ Previous Topic | Next Topic ›