On Monday 02 August 2004 11:20 pm, you wrote:

Well, the quick-and-dirty way of doing it would be to select a triangle shape and use the GIMP's fill function. :)

This is exactly what I want. For this I

#include and #include

Is there a drawback of this method or something else I should know (I found no "core" plug-in including a header ending "_pdb.h", but I guess this is because none uses this)?

I'm afraid I don't see why there is a lack of locality here: each triangle to be filled indeed has locality. Of course, if the triangle is sufficiently small, only one tile needs to be involved.

Yes, each triangle has locality and of course, the whole effect also has locality (the drawable), but I meant locality with regards to tiles when using a tile iterator: I see no easy method to set up a tile iterator and iterate by some constant amount, because no matter how big I make that amount, there are always cases where triangles will cross a tile intersection. I did not look at the select and fill code, so I am not sure (especially wrt anti-aliasing) if a triangle started on tile A can be continued on tile B without visible jags. When I have the effect working, I will try such things, but it is not that important for now.

Markus.

On Tuesday 03 August 2004 06:35 pm, Markus Triska wrote:

This is exactly what I want. For this I

#include and #include

Can anybody beat this amount of stupidity? I just found out that these files are included via "libgimp/gimp.h".

Markus.

On Tuesday 03 August 2004 05:35 pm, Michael Schumacher wrote:

May I suggest that you start from the gimp plug-in template? It help you to get e.g. the build configurations and the i18n of your plug-in right.

Thank you for this suggestion. I have successfully used the plug-in template before and will add i18n and so on later. I currently work only on one single file (which can be conveniently compiled using gimptool), but as soon as I add Gtk UI code in a separate file, I will switch to using autotools.

Markus.

On Tuesday 03 August 2004 07:08 pm, William Skaggs wrote:

Actually I would go about this differently: Start by making a list of all of the triangles, recording their vertices.

I have this list available already, so this would be no problem.

Then go through the image, and for each pixel, figure out which triangle is visible there, and render its color. I think this would be a lot faster, and it lets you work with a tile iterator as well.

Even if I had an easy way to determine the right triangle, this would make anti-aliasing harder because no pixel would "know" if it is part of an edge or even nearby. My guess is that the advantage of using a tile iterator would not outweigh the additional computing time necessary for the approach you suggest, but I have not tried it yet, and this is why I asked for stats initially.

If you start searching from the center of the image, and work outward, then the first triangle you find that overlies the point will be the one that is visible, so the search can be done pretty efficiently. In fact,
there may even be a way of calculating which triangle is visible above a given pixel without having to do any searching.

The search would be additionally complicated by the fact that you can optionally give the pyramids random heights and modify the viewing distance, so the perspective projection has to be taken into account more explicitly. I therefore don't think that the method you suggest would be easier or faster.

I have meanwhile modified the plug-in to use GIMP's selection and fill method (with anti-aliasing enabled). The result now looks better and also rendered quite fast (there's currently a problem on the left side of the pyramids in the horizontal center of the image which I will of course fix):

http://stud4.tuwien.ac.at/~e0225855/extrude2.png

To fill a triangle, I use:

gimp_palette_set_foreground ... gimp_free_select ....
gimp_edit_fill ....

Is there a better way to do this? The "set_foreground"-part changes the colour menu in the user interface, can I avoid this somehow? Why does the call take a pointer - is it safe to modify the variable after the call? Another question: Do I have to call gimp_drawable_flush and gimp_drawable_update at the end of processing? What do these things do? I called them when I worked on the pixel data directly, but I have now commented these calls out as I only use internal GIMP functions and don't copy or modify the pixel regions/arrays directly.

And something else: The documentation for "gimp-drawable-mask-bounds" reads "...returns the whether there...".

Markus.

On Sunday 15 August 2004 12:56 am, you wrote:

This was an interesting plug-in, the latest one "more interesting" than the

first.

Thank you, the current version produces even "better" results (all sides are now drawn in correct order).

Do you intend to have a user Dialogue interface for the plug-in?

Yes, now that I have got the basics somewhat right, the following parameters could be set/changed in a dialog:

*) height of pyramids / random height? (boolean toggle) *) size of pyramids
*) viewing distance
*) direction of light vector

(later: pyramids/blocks; don't hide partially visible objects)

I still need to figure out useful default values for the settings (currently height = 80, size = 50, distance = 250, light vector = constantly changing to test the shading code, in the .c-file on the web it is (1,0,0), but need not be normalized).

If you are interested in coding up (parts of) the dialog, just fetch the .c-file from the web and insert the code wherever you see fit, I can merge your changes later with my own latest version.

The most appealing part of this task is probably the representation of the light vector - of course, 3 text-boxes each holding an integer would "suffice" (certainly for the initial version of the plug-in), but you may find an easy way to actually show and let users interactively edit the vector in pseudo-3D.

Best regards,
Markus.