On Thursday 04 August 2005 18:43, Axel Philipsenburg wrote:

Hello folks!

I've just now joined this mailing list, looking for some info from people who know the internals of the Gimp's plug-in system.

The reason is, that I have a project in mind that I'd like to try to write as an Gimp plug-in, but I am not sure if it can be done.

So before diving headlong into the source I though I'd rather ask if it's even doable. If so, then I'll start digging through docs and code. :)

What I'd like to do is to write a plug-in that would make the Gimp a nice tool for 3D artists by showing a 3D object in a seperate window with the currently selected Gimp image as UV mapped texture.

The 3D object would be loaded from a Wavefront OBJ file with all UV mapping coordinates and been displayed by using OpenGL.

The only thing that gives me worries about this, is if the Gimp plug-in system would allow a seperate window to be constantly displayed and updated whenever a tool operation is finished so that the artist can practically see each brush stroke (or other tool usage) instantly on the 3D object once the tool has been used.

If that is the case, then the only real work for the plug-in in would be to make a flattened copy of the currently edited image and send it as texture to the OpenGL part of the plug-in.

Any comments on the idea or if this possible with using the Gimp's plug-in system?

Hi!

Offically it is not possible.

That is: there is no way for the GIMP to call back your plug-in whenever an action is performed.

However nothing but the extreme deselegance of it can stop your plug-in of pooling the GIMP for image data every few seconds.

So, I'd say it is feasible. It won't be perfect, but would be functional enough.

Are you writing the 3D part? Maybe it is even possible to use blender for it. I do not know exactly how Python works with Blender - but it may be possible to write a script that is _both_ a blender script and a GIMP plug-in and get this working with less than 200 lines of code.

JS ->

Thanks a lot in advance.

Bye Bye

Axel

Hi,

Axel Philipsenburg writes:

What I'd like to do is to write a plug-in that would make the Gimp a nice tool for 3D artists by showing a 3D object in a seperate window with the currently selected Gimp image as UV mapped texture.

But such a plug-in does already exist. Years ago already I saw a plug-in that allows you to paint on Quake characters will 3D preview in realtime. Did you check the registry?

Sven

On a note to my previous idea of linking such a script to Blender3D: If it is not possible for a script to be both a GIMP plugina a blender script, anyway, a Bldenr Python Script can comunicate with a GIMP plugin script via sockets or TCP with very little effort. The major nuisance I see in this aproach is taht AFAIK blender takes full screen for it, so I do not know you could keep a GIMP window open over Blender for painting.

On Friday 05 August 2005 17:19, Joao S. O. Bueno Calligaris wrote:

On a note to my previous idea of linking such a script to Blender3D: If it is not possible for a script to be both a GIMP plugina a blender script, anyway, a Bldenr Python Script can comunicate with a GIMP plugin script via sockets or TCP with very little effort. The major nuisance I see in this aproach is taht AFAIK blender takes full screen for it, so I do not know you could keep a GIMP window open over Blender for painting.

Blender has a command line option for starting in a resizable window. I don't remember what it is, but judging by the "-h" display it seems to be "-w", but I don't know for sure because at the moment, I did not activate the Nvidia proprietary driver. (so my machine won't constantly hang up - ).

Regards,

Shlomi Fish

--------------------------------------------------------------------- Shlomi Fish shlomif@iglu.org.il Homepage: http://www.shlomifish.org/

Tcl is LISP on drugs. Using strings instead of S-expressions for closures is Evil with one of those gigantic E's you can find at the beginning of paragraphs.

On 8/5/05, Axel Philipsenburg wrote:

Michael mentioned that Gimp Plug-Ins might not be able to allow further manipulation to the image while running because they hog the dialog focus.

I guess I should have mentioned I wasn't 100% sure with this. However, I will note, on my 2.4 GHz Intel Celeron, it has been nearly impossible for me to multitask when running a plugin (they're too CPU intensive) -- and OpenGL wouldn't be feisable for me either because I don't have a high-end graphics card. That said, most people who would use this kind of plugin, I'd assume, wouldn't use this kind of low-end system anyways (if I want to wrap an image around an object, I'll use POV-Ray and raytrace it anyways; so there is no such thing as a real-time preview to me regardless of rendering method, and I know how to use POV-Ray).

If that's truely the case, then the plug-in approach on this tool seems doomed anyway. There is not much sense if you need to call the plug-in from a menu everytime you changed the texture somewhat.

I don't see why I can't float the plug-in's menu and keep clicking the button though.

I still wonder how you're gonna export the data to OpenGL, and what happens if something goes wrong. How will you handle OpenGL's settings, etc... so maybe moving this elsewhere is an idea. What about as a seperate utility? [e.g. Use a filename with e.g. a png or xcf file and load, then open a window with a preview, setting OpenGL settings and the image's filename in it -- when I want an update, I'll save my image in GIMP, and click a button in the app which will update the preview.]

Good luck with your project, should you continue to persue it.

* michael chang :

On 8/5/05, Axel Philipsenburg wrote:

Michael mentioned that Gimp Plug-Ins might not be able to allow further manipulation to the image while running because they hog the dialog focus.

I guess I should have mentioned I wasn't 100% sure with this.

FWIW, I was able to run a gaussian blur plugin _and_ draw onto image at the same time. Changes also propagate into plugin preview (if only I draw into different cache block than what is shown in preview, this could be a bug?).

However, I will note, on my 2.4 GHz Intel Celeron, it has been nearly impossible for me to multitask when running a plugin (they're too CPU intensive) -- and OpenGL wouldn't be feisable for me either because I don't have a high-end graphics card.

IMHO this kind of usage would be made feasible even by a Mesa on 200MHz machine as this doesn't really need a lot of interactivity (=FPS). And if you need interacivity (for example preview of animated model), it's likely you already have adequate 3D card. And if you're UV-mapping model that under 5 years old card can't render at over 10FPS even without other environment, you have bigger problems.

If that's truely the case, then the plug-in approach on this tool seems doomed anyway. There is not much sense if you need to call the plug-in from a menu everytime you changed the texture somewhat.

I don't see why I can't float the plug-in's menu and keep clicking the button though.

plugin-callback for changed data shouldn't be an impossible or over-the edge feature.

It could also be a 'filter': - open image
- ->New view
- ->Display filters
- and here would be a 'UV mapping' filter.

This venue could prove interesting as it could also be used as high-speed trilinear filtering system (ie. display several polygons mapped with image data, and just scale them to be shown in needed size onscreen), harware would then drive rescaling and filtering. This would only need 'all-forward' UV mapping on a surface that fills viewport. (That was, btw, talking out of my a** as I know nothing about how gimp currently handles display filtering. It seems to get lots of moire when displaying 11Mpix image with 18% magnification, gimp 2.2.8)