On Mon, 18 Sep 2000, Kevin Turner wrote:

> On Mon, Sep 18, 2000 at 04:24:35PM -0500, Stephen J Baker wrote:
> >   1) Write a plugin for PrettyPoly that captures the
> >      3D coordinate of the cursor - figures out which
> >      texel in the texture map it's pointing at and
> >      stuffs that into a little chunk of shared memory.
> > 
> >   2) Write a plugin for GIMP that grabs that texel
> >      coordinate and (somehow) stuffs it into GIMP
> >      so that GIMP thinks it's the current mouse position
> >      within the painting area.
> > 
> >   3) Have that same GIMP plugin grab the current image and
> >      dump it into a (large) shared memory area.
> > 
> >   4) Have a PrettyPoly plugin read that shared memory and
> >      stuff it into the currently selected texture map.
> There's no reason why you can't do #3, I guess, but you can't quite get
> #2.  For that, it sounds like you would want to transmit signals
> event-for-event to the gimp canvas, but with transformed coordinates...

Yes - exactly.

> Unfortunately, you can't communicate that tightly with the core
> application from a plug-in.  You're limited to the language of the PDB.


How do devices like digitizing tablets interface to GIMP?  Perhaps
there is a way for me to pretend to be something like that.

> Maybe that's close enough -- I don't know.  See the "DB Browser" under
> the Xtns menu for the list of functions available to you.  You'd have to
> transform events in PrettyPoly to things like
> gimp-paintbrush-defaults(1,2,{0,0},{5,10})...  It'd be interesting to
> see if you could get away with that.  I suspect there would be a *lot* of
> latency in the interface, but I guess the only way to find out if it
> would be acceptable is to test it...
Yes - the PrettyPoly end of things is *reasonably* fast - if you have
a good 3D graphics card like a GeForce or something it'll cycle at
better than 30Hz for most scenes.  We might get fancy and only download
the part of the texture map that actually changed which would speed
things up significantly - but certainly the latency would be noticably
worse than with straight GIMP.

> You can get the selection mask, but you'll have to draw the marching
> ants yourself...

I expected as much.

> Seeing layer compositing won't be practical, because the only operation
> GIMP provides to merge the layers removes them all in the process.  (I'm
> tempted to call that a BUG).  So you have to tell GIMP to copy all
> visible layers, send the command to merge those, send that image to
> PrettyPolly, and then delete the merged layer and do the whole shebang
> again the next time a brush-stroke happens...
Urgh!  Still, I'd settle for just seeing the current layer if that's
what it took to get this right.

> I think this is the point where you decide that's redicilous and start
> making patches to the GIMP core ;)


> And of course, "you will be able to do this with GIMP 2.0", but at the
> rate we're going trying to finish 1.2, it could easily be another decade
> before that happens.

Well, thanks for your help - I'm not quite sure where that leaves
me.  Since PrettyPoly is *far* from ready for general release, and
3D painting would just be a cute hack this isn't a pressing problem

However, it would be nice if the hooks to do this kind of thing were
in GIMP 2.0....it would be a nice legacy for my grandchildren!

Science being insufficient - neither ancient protein species deficient.

Steve Baker                      (817)619-2657 (Vox/Vox-Mail)
L3Com/Link Simulation & Training (817)619-2466 (Fax)
Work: [EMAIL PROTECTED]           http://www.link.com
Home: [EMAIL PROTECTED]       http://web2.airmail.net/sjbaker1

Reply via email to