Update on Morphic 3

Hi Folks,

I've updated the Morphic 3 stuff at www.jvuletich.org. I have been
working a lot recently, uploaded several very cool samples for you to see.

I also want to thank publicly to Stef Ducasse and ESUG, as they are
sponsoring Morphic 3 via the "support your project" program, described
in http://www.esug.org/Promotion/Project . Thanks ESUG!

Comments welcome.

Cheers,
Juan Vuletich

Excellent news Juan!

And really I think ESUG deserve a big thanks by the initiative of help
Smalltalk projects.

Cheers.
Germán.


2010/6/1 Juan Vuletich <[hidden email]>:


--

Very interesting, thanks. One thing I noticed was your comment on:

"The next example is interesting because it exhibits a common problem
with vector graphics. If you have adjacent polygons, the anti aliased
edges superimpose and create this white line artifact. You can see that
the Morphic 3 image is a lot less pixelated. But look below...

...

This last one is done with a new technique I developed for Morphic 3
that completely avoids the problem, without creating other artifacts and
without any need for user intervention."

Can you say something about what you're doing? I'm curious about what
you've done to address this issue (and whether it's applicable to
real-time rendering).

Cheers,
   - Andreas


On 6/1/2010 2:40 PM, Juan Vuletich wrote:

GREAT WORK JUAN! the quality is superb!  

it's amazing to see Morphic3 in action!  

When can we get our hands on it?

If you need any help/tester for the project i'm up to it!

Fernando
pd: just a minor remark on the web page: i think the pictures to the right and left should have a distinct label, explicitly distinguishing Morphic3 and the other rendering engine used.

On Jun 1, 2010, at 11:40 PM, Juan Vuletich wrote:

Very good work!!


GRANDE JUAN!!

Edgar

Andreas Raab wrote:
I can't say much right now. I hope you understand. What I can tell you
is that it is a post processing done on the rendering of a group of
polygons. So it fills naturally in my #exportAsPNG: method. It is not
too expensive, it makes my export operation about 20% slower. So, it
might be adapted to real-time drawing of the morphic desktop. The issue
is that if it is done on a morph by morph basis (so that drawing of
different morphs is independent as it is today), then it would avoid the
defect if it occurs between polygons belonging in the same morph, but
not on polygons belonging to different morphs.

In short, it seems possible, but not yet done.

Cheers,
Juan Vuletich

On 6/2/2010 5:02 AM, Juan Vuletich wrote:
> Andreas Raab wrote:
>> Can you say something about what you're doing? I'm curious about what
>> you've done to address this issue (and whether it's applicable to
>
> I can't say much right now. I hope you understand.

I'm not sure. Do you mean you haven't quite worked it out and it's just
not clear to you how best to describe it, or do you mean to protect your
IP and don't want to talk about it in public?

> What I can tell you
> is that it is a post processing done on the rendering of a group of
> polygons. So it fills naturally in my #exportAsPNG: method. It is not
> too expensive, it makes my export operation about 20% slower. So, it
> might be adapted to real-time drawing of the morphic desktop. The issue
> is that if it is done on a morph by morph basis (so that drawing of
> different morphs is independent as it is today), then it would avoid the
> defect if it occurs between polygons belonging in the same morph, but
> not on polygons belonging to different morphs.

Right. Obviously, one needs to compute the full adjacency graph and
overlap of the polygons to address the problem. Which is one half of the
problem. If the input is well-structured, like for example in Flash
(which has all the 'internal' adjacency information for its shapes) it
is quite possible (though still pretty expensive) to compute accurate
coverage without introducing these artifacts.

I remember looking at this briefly when I wrote the Balloon engine but
kind of gave up on it due to the other half, namely the issues of
horizontal and multiple sub-pixel edges. Theoretically it should be
possible to adjust a classic scan line algorithm to compute the proper
coverage but it became too messy too quickly ;-)

In any case, let me know when you got something written up; I'm just
really curious what you're doing.

Cheers,
   - Andreas

Andreas Raab wrote:
I'm no big fan of IP. I don't even think such a thing exists. What does
indeed exists is copyright of code (I'm ok with that) and math/software
patents (I'm against them). I feel rather close to
http://www.tinaja.com/glib/casagpat.pdf .

Anyway, this is the result of 3 years of unpaid work, and even if I want
it all to be eventually in the public domain / MIT license (as
appropriate), first I need:
1) Publish it with proper author attribution. It might be in a good
magazine, or it might be as a Ph.D. thesis. Both require the work to be
unpublished before.
2) Secure it in the public domain, so "bad guys" can't patent it.
3) Make some money, to be able to keep working on interesting stuff.
This could be done by selling consulting services to someone interested
in my work, provided they don't want to restrict what I can do with it.

When I have these worked out (and I welcome help and suggestions from
you guys!), I'll be able to make it all available without restrictions.

Sure.

Cheers,
Juan Vuletich

Nice quality.
My own concern is a speed. I want to make an engine to support a
decent frame rate (25 fps),
when rendering about 10 system browsers on desktop.
Maybe it would require to downgrade the quality & level of detail,
depending on context.
But i'd like to make a smooth transitions when user zooms-in or
zooms-out the whole desktop, or pans it.
This will mean, that engine should support some adaptive techniques,
to stop fighting with aliasing,
where its not necessary, and in other turn, produce a high-quality
renders for still images.

On 2 June 2010 00:40, Juan Vuletich <[hidden email]> wrote:


--
Best regards,
Igor Stasenko AKA sig.

Igor Stasenko wrote:
What I'm doing is not too much slower than FormCanvas, so it should be
fast enough, I guess.

Cheers,
Juan Vuletich