Shapes and paths

Now I can interpret an arbitrary curve like a path. So I can apply arbitrary shapes to curves.

Paths can be used like a vector based reference for position only (left) or really like a directional field (right).

A little different enjoy

I will spend a small time involved in another free project: a small library in C++ for plotting scientific charts. The emphasis is about shortness, lightweight, portability and usability in web servers.

I hope I will be back to P2P project soon.

Going forward

All major known bugs of my vector based library are out.


I already can use a set of pixels like a "border" of an arbitrary vector based curve.


Now I intend to make some functionalities joining shapes and paths.

Generalising?

For now I'm trying generalise some models and algorithms using math manifolds. When you can use generic code usually you get more readability and maintenance.

It's a very internal task concerning P2P core.

Hard work, but no screenshot.

Parametric is better

Now any vector represented curve can have a pattern based border.

But it's not all: the algorithm is robust enough to accept a parametric pattern. There is no restriction about combining short and/or long "dots" and "dashes". It can be so complicated as desired.

I'm planning a yet more powerful kind of parametrisation for curves drawing. Let's see if I can implement the model.

Someday I will see the raster and vector based tools working together in an unique nice software.

Less bugs, more vectors

The geometric library is getting better. Some bugs are already off.

A thick line is easier to do in a raster way. But if I can make a thick line in a vector based way, I can, for example, apply over it a parametric filling like showed in picture.

I would like to get stable code soon ... There are several tasks interrupted (not exhaustive):
- filling algorithms;
- complex curves representation;
- complex polygons operations.

Tomorrow is another day.

Advanced vector manipulation

Construction of vector structures based on arbitrary (maybe micro segmented) objects is a hard task. Trying to tackle such ambitious work stressed my vector library and I have found some minor (but bothering) bugs.

It's has been a challenge improve my algorithms from this point. Sometimes I need to solve not so easy equations ... floating point imprecision is an powerful enemy.

Maybe I will need some king of "controlled truncation" or backtracking. I'm testing some alternatives.

My bug list is very huge for my taste ... Maybe I will not have time to write here for a while.

Object-Oriented Programming for all of us

Let's put vectors, pixels, curves, low level algorithms and related concepts aside for a moment.

A lot of people has been asking me about a more general subject: "You have a software with a lot of low level code. How deep are you using OOP in your project?".

Well ... I have been using OOP in personal and work projects for more than 12 years. I can really give my testimonial about the power of this approach. But how deep can you go? Which effects will you face using OO concepts in deep for low level programming?

There is no doubt about one point: if you really know how to use it, OOP makes programmers life very comfortable. Anyway, nothing is perfect: sometimes what is correct in a OO sense can be not so useful, mainly about performance.

Let's talk about a very generic situation. It's only illustrative, but can be used like an example.

Suppose you have a class "A", which have two operations (methods) "m" and "n". Consider that "A.m" has a time cost of "t", and "A.n" has a time cost of "10000t" (the methods are not necessarily static; it's just for the sake of simplicity). Now, consider that for the correct closure of the state of a object from type "A", I need to call "n" inside the implementation of "m". In this scenario, suppose it's a obligation because an "A" object needs to be correct all time and doesn't know the external environment.

It's much easier make the "A" concept like a class and let each instance of "A" take care about itself. But what about if you use "A.m" in a very inner loop in your source? For each iteration you will pay the price of calling "A.n". Maybe it's too much expensive in time and can make your system useless. In that situation, can be mandatory to break the encapsulation and try to find an algorithm that call "n" source just once (or few times) and let the inner loop run only calling "m" source. This kind of solution can have other bad consequences, but it's another subject.

The final digest is: every big and/or complex software needs a lot of planning and modeling. The "real world" problems sometimes can not be solved using just one paradigm.

In P2P I use a lot of OOP ... but a OO purist would find flaws.

Just filling ...

Now I'm expanding the limits of my vector based library. I'm trying to "stress" it and construct new operations based on it.

I'm coding "filling" functionalities using vector operations. My vector based algorithm can fill 99% of the pixels for degenerated curves like that showed in the picture. Probably I could achieve 100% for any curve using antialiasing operations. However, filling is already a very expensive operation. I don't think antialias overhead is worthy in this case.

Filling algorithms are a very interesting subject in CG by itself. This problem can have many derivations depending on if you are rendering, drawing, making masks, etc.

A good software must have a rastering based filling too. It doesn't matter how powerful or hardware enforced your vector based library is, sometimes you just don't have a vector based representation of what you want to fill.

Since filling is my subject for now, I'm thinking about to code a raster filling now (putting the vectors aside for a while). People with some experience in CG can think: "Very easy, huh? You just need to have a recursive function like [SetPixel]. The implementation of that has inside 8 new calls of [SetPixel] for the pixel neighbourhood."

Do you really think it's a good choice? I will give my opinion about that in next post.

A powerful tool is for smart users

The subject about vectors and everything related is not over ...

Vetorial tools give a lot of power to create and edit curves and shapes. But all this power has a price. You must to know how to use it.

Look at the picture. It shows a curve (at right) and a set of related structural vectors. It's easy to see the bad conjugation: there are a lot of crossing and overlapping. Most of operations made using this vectors will produce weird, not useful or unexpected results.

Is it a reason to not invest in this kind of tool? I don't think so. The "good" user can achieve nice results, at least after some training.

The world is made of vectors

I'm still coding a library for vector manipulation.

I want to make only the seed and upgrade it step by step. Anyway, a good work needs planning and careful implementation of the basis functions and operations.

Some people like to say that vector problems can always be solved with a matrix operation. Of course it's not true and talking about vectors to solve pixels problems it's worse.

The picture shows some tests about the geometric library in development.

From now, the minimal coding needed will last a week or more.

Pixel, the lord of vectors

I couldn't find a general model for antialiasing. At least I started a low level service for antialiased drawing of curves. As the time goes, I will try to give it more features.

A lot of good effects can be made by using parametric functions or expressions over a group of pixels. But it's not enough for a really complete software. I'm preparing a vetorial library suitable to make powerful raster operations. In the picture I show a set of pixels applied to a vetorial path.

The more I code, the more appears to be coded ...

Beautiful drawing

I'm still dealing with antialiasing.

Aliased drawing is very easy. Simple antialiasing techniques are easy. Generic robust antialiasing methods are difficult.

I'm trying to get a generalization about polygons and curves. I need to draw really small floating point line segments, what can not be treated by "conventional" algorithms, cause the final result has not a professional appearance.

For now, I'm reading my articles about antialised 3D rendering. Maybe I can adapt some model for my needs.

The hard war against jagging

In test software I can use Windows GDI to draw for me. It's a good choice because the emphasis is about my data structures and models. If I get a exception, I can suppose its not caused by the drawing itself.

But now I started the class which task is to draw. It's time to worry about aliasing. At least in a "output mode" I need to avoid jagging.

I have a lot of algorithms working with integers when it's possible. Rounds and imprecisions turn the jagging stronger yet.

I will have a lot of planning and recoding concerning floating point numbers or anti aliasing methods.

Hard work coming ...

The power of shapes

I have spent a few time making code for drawing shapes (see screenshots section).

This functionality along with polygons/curves set operations will help the user to make really complex drawings.

This last programming was funny. Now let's go back to dealing with operations over complex polygons.

Set operations on simple polygons

Finally set operations on polygons are working well.

Now It's time to care about complex polygons (polygons made of several ones, including representing roles).

The end of works about lines and curves are so far ... Tomorrow is another day.

Polygons, Curves, Glyphs and more

For now, I'm very concentrated about set operations on polygons/curves.

I have the known articles about this theme. Some are not enough to degenerated cases, others have closure but are very hard to understand in deep or not so good for a "real" implementation.

I'm making my algorithm. By my math tests, it has closure if you know how to deal with the "bad" cases. Unfortunately, the implementation is getting infinite loop for some degenerated situations. How the coding has a lot of pointer indirections and the internal tasks are not so obvious, the debugging is a little bit hard. I suspect this behavior is coming from floating point imprecision. I should be very bad ... I hope I'm wrong.

Most of set operations in polygons can be "simulated" by correct use of layers. So, why this work? Cause I'm making my own code for font rendering also. I want to get a unique library for dealing with polygons, curves and font glyphs. A glyph can be very complex and usually you can understand it how a list of curves interacting by set operations. That's the reason.

Maybe I will not write here again until this part is done.

Advanced Interface X Portability

In Windows, the behavior of some widgets depends on one or another DLL version, which changes according to your OS version. Furthermore, some screen "objects" need a lot of programming to make advanced or specific tasks. This situation always invites you to make your screen classes.

It has been a long time since I started to worry about generalizing the screen tools I have to make my interfaces. A big system usually has hundreds of windows. It's not a good idea create one by one using raw pieces of code. When it makes sense, I want to create windows by reading configuration values dynamically. When it's impossible cause I need a custom behavior, there will be powerful screen classes to make the hard job.

But there is no perfection. I use windows specific resources to make my interface classes. In another OS, I can reuse several ideas and logics, but I'm sure there will be a lot of redevelopment. Mainly talking about softwares that need advanced interfaces to draw, drag, select, etc, can be hard to mimic a behavior in several graphical environments using the same source.

I didn’t want to use GTK+, Qt, or anything like that. You know how I like dependencies for this project. This libraries don't have everything I want ... If I had chosen one of them, I would need to extend it. I know I lose portability, but I prefer this way.

At least, the core will not have this kind of problem. In another environment (like X11 for example), the hard job will be only remake the interface layer.

Scope X Dependencies

A good question for a FAQ about P2P would be: what software do I need to run P2P? I hope the answer will be: "nothing else P2P". But what does it means?

I'm coding EVERYTHING about P2P. I'm putting there what I have learned/discovered in about 15 years of studies in CG. As every programming is mine, I hope I can change anything as desired and fix every bug found by me or any user. If I want to port the system to another platform, I'm not limited by low level libraries or something else. At most I need to migrate my own code to another language more suitable for the target environment. Any object oriented language will be enough to support my source.

Many times, creation of low level functions/tools (avoiding use of specific libraries for some hard work) for a software is the painful job, but it's the real fun. The scientific work and mathematical understanding of things usually are related to the low level development.

In fact, the total truth is: there are some pieces of code I haven't made and haven't stopped to understand. This part of the system is closed in one group of related functionalities: common CG file formats reading/writing. Some parts I got in CG books, another parts I found out in CG forums. I have all the source (I typed/adapted most of them), but it's not understood. According the preliminary tests I have made, the logic is not 100% in some cases. The main problem is that some file formats I intend to deal are not covered in all variations. Probably it's a problem I will need to face in the future, but now I have a lot of more important things to worry.

The big point is: I don't want to create dependencies. Anyway, there will always be a weak side concerning software reuse. More about it in next post.

A long road starts ...

Hi, everybody.

For you it's the beginning, for me it's another day of hard work.

It has been a long time since I started this. It was interrupted many times (for long times), I have faced many problems, I have thought about give up. I believe it's normal. Large projects get "ups" and "downs" across the time.

Anyway, I'm here, stronger than before. As more the things go fine in this journey, as more I increase the scope. My desire is make a really professional software, really useful for designer (I was designer for a while too).

Let's see what fate have prepared for me and my dream ...

Talking about vectorization

My tools for transforming raster images in vector based ones achieved a good point.

In fact, it was a funny challenge, since was not easy develop a math model to give results with a good balance between of smoothness and small loss of details.

The result's quality depends on several math properties of original raster image, like for example:
1) average curvature field;
2) topology distribution;
3) local and global entropy.

At first, let's see what kind of result we get by direct use of the vectorization tool over a common bad resolution bitmap:


(1) The original image


(2) The raster representation of same image after vectorization

Beginning from this very simple example, there already are several points to talk about:
1 - the original picture was very easy to vectorize;
2 - the result is not totally smooth;
3 - one intuitive way to see some math properties of source image;
4 - the vectorization was applied just once and without pre-processing.

I will discuss about all of that soon also including new examples.

A logo for Picture to People project

The image of this post is the first logo of P2P project (usually logos evolve as the time goes). I have just made it.

Despite its subjective meaning, I have made it this way for some reasons:

- it should be very simple;

- it should use very few colors;

- it should be understandable when in tiny size;

- it should not be so beautiful in a way I could not make a better logo after some years. ;)

If you don't like it, feel free to send me a good logo for this project made by you (don't forget to meet the requirements above). :)