Morphic graphics, Displaying fonts & canvases

>
> > I draw scene in orthographic projection, and
> > drawing same figure with different Z values will not make any visual
> > differences.
>
> Of course you can ignore or just throw away z-values but if different
> they do still affect the rendering, assuming you enable depth
> buffering. In fact you can get some funky overlapping effects by
> manipulating the depth buffer.
>

> > In future, a nice looking perspective projection can be introduced
> > such that at Z = 0 your object's X,Y will be equal to screen X,Y. But
> > with Z > 0 or Z<0 will be zoomed in/out relatively to the center of
> > screen.
>
> IMHO it is probably wise to plan for this from the start. For example,
> when you get to this stage will rotation be desired/allowed? If so,
> will rotation be restricted to one axis, ie, the z-axis? Makes sense
> otherwise rotation in the either of the other two axis means widgets
> dissappear when viewed edge-on unless artificial "thickness" created
> (as Croquet effectively does with it's "2D" windows) or billboarding
> used. Another consideration would be managing the extents of the set
> of objects (limited or infinite-ish space?) and efficiently managing
> many objects. Other issues would be mipmapping and/or LOD, plus maybe
> a not so obvious question of suspending objects at a distance? Many
> issues which you probably already address. Hope I don't overload you
> ;-)

>
> Are you concerned at the moment with the target spec of end-user
> machines? My interest in 3D environments reached it's peak maybe four
> years ago and then waned as manufacturers dragged their collective
> feet and failed to incorporate 3D hw as standard. The situation is not
> much better today but we can thank MS at least for upping the ante
> with Vista (I can't believe I'm saying that and, no, I personally have
> no intention of "upgrading" to Vista). But with plans to add 3D hw to
> mobile phones and the low cost of cards for desktops the future looks
> good. Downside is many people now choosing notebooks over desktops and
> unfortunately many still don't have 3D hw... personally I blame the
> users for not demanding it :-)
>

> On 24/04/07, Derek O'Connell <[hidden email]> wrote:
>> > Since i'm currently drawing a 2d scenes i don't neeed to clip by
>> depth(Z) value.
>> > But of course for drawing any 3D object i will need it.
>>
>> Excuse me being pedantic but you are still drawing 3D, just flattened
>> by the orthographic projection....
>
> of course. But by default i set canvas to this type of projection
> because most of morphs think that they draw to 2D canvas.
>>
>> > I draw scene in orthographic projection, and
>> > drawing same figure with different Z values will not make any visual
>> > differences.
>>
>> Of course you can ignore or just throw away z-values but if different
>> they do still affect the rendering, assuming you enable depth
>> buffering. In fact you can get some funky overlapping effects by
>> manipulating the depth buffer.
>>
> i'm aware of that. Enabling depth-test will be in the next stage.
>
>> > In future, a nice looking perspective projection can be introduced
>> > such that at Z = 0 your object's X,Y will be equal to screen X,Y. But
>> > with Z > 0 or Z<0 will be zoomed in/out relatively to the center of
>> > screen.
>>
>> IMHO it is probably wise to plan for this from the start. For example,
>> when you get to this stage will rotation be desired/allowed? If so,
>> will rotation be restricted to one axis, ie, the z-axis? Makes sense
>> otherwise rotation in the either of the other two axis means widgets
>> dissappear when viewed edge-on unless artificial "thickness" created
>> (as Croquet effectively does with it's "2D" windows) or billboarding
>> used. Another consideration would be managing the extents of the set
>> of objects (limited or infinite-ish space?) and efficiently managing
>> many objects. Other issues would be mipmapping and/or LOD, plus maybe
>> a not so obvious question of suspending objects at a distance? Many
>> issues which you probably already address. Hope I don't overload you
>> ;-)
>
> Such activities is beyond the Canvas abilities. For nice and effective
> 3D positioning and to restrict some operations (like limit rotating
> e.t.c) there must be some kind of 3D layout manager - a class which
> will establish these rules and makes sure that you follow them. It can
> be a World instance or some kind of Morph3DLayout which draws its
> submorphs in special fashion.
> Its very hard to control all aspects at Canvas level and in fact it
> can limit the features of its potential users. So the less restrictive
> Canvas will be - the better for all of us.
>
>>
>> By the way, my interests are entirely selfish :-) I hope one day to be
>> freed from the constraints of a dumb 2D desktop and be able to
>> organise myself in a 3D (probably 2.5D) space populated with
>> intelligent objects!
>>
>
> Same as you!
> Nothing can be better than 2D when you need a plain text reader/editor
> or windows e.t.c. And then if you need 3D, most desktop systems
> require to allocate a rectangular area to draw on it. My efforts
> directed to remove such ridiculos restriction and allow 2D and 3D
> objects coexist in harmony and be managed by same manager without
> extra distinctions.
>
>> Back to Berts example of a text editor: I accept the depth buffer is
>> not the best way to do clipping. However I wonder if there is an
>> alternative approach where clip-regions are implemented/achieved
>> simply by using rendering-to-texture or FBOs if available? There may
>> be additional benefits? I'm not up to date on OpenGL but regardless of
>> approach I think some degree of gfx memory management will be needed,
>> which leads to...
>
> Yes, rendering to texture must be allowed. This is very useful when
> morph wants to cache of some of its output. (In fact, to support
> currently implemented shadows/draggable morph contents  its the best
> way to do)
> But still from reasons i showed before, i can't allow to let anyone
> copy canvas. I'll better introduce a good caching protocol, so cached
> surfaces (NOT FORMS!!) will refer to main canvas and will have limited
> protocol, much more restrictive than Form is. For generic Canvas
> implementation we can't assume that cached surface is stored as area
> of pixels (it can be stored as set of commands by example), so
> including behavior which follows such presumption will be absurd.
>
> premiliary the caching will look something like this:
> | cacheId |
> cache := aCanvas createCachedSurface: extent.
> aCanvas drawToSurface: cache during: [ ... ].
> aCanvas drawCachedSurface: cache at: aPoint. " like drawImage"
>
> its ok to store a 'cache' var as long as you need it. since all
> drawings to it is controlled by canvas there is no risk of breaking
> canvas internal state.
>
>>
>> Are you concerned at the moment with the target spec of end-user
>> machines? My interest in 3D environments reached it's peak maybe four
>> years ago and then waned as manufacturers dragged their collective
>> feet and failed to incorporate 3D hw as standard. The situation is not
>> much better today but we can thank MS at least for upping the ante
>> with Vista (I can't believe I'm saying that and, no, I personally have
>> no intention of "upgrading" to Vista). But with plans to add 3D hw to
>> mobile phones and the low cost of cards for desktops the future looks
>> good. Downside is many people now choosing notebooks over desktops and
>> unfortunately many still don't have 3D hw... personally I blame the
>> users for not demanding it :-)
>>
> The target spec is the machine with OpenGL library which can be
> dynamically linked with squeak and used by FFI interface.
> about OpenGL version - this may differ. One assumption that i have
> now, that OpenGL implementation allows creating textures of non power
> of 2 dimensionality.
> Most current implementations of OpenGL (2.0 by default) support this
> feature.
> The second is rendering to textures.
> I think that this will be enough for my GLCanvas. Any extra OpenGL
> functionality like pixel/vertex shader programs can be used by morphs
> via OpenGL FFI optionally. But GLCanvas functionality will not depend
> from them.
> Or maybe provide some extra protocols which allow safely use such
> capabilities without risk of damaging internal state.
>

> One might think that this is an already-solved problem.  I don't know.
>
> You might look for comparison at Morgan McGuire's 2D API for Curl, which
> supports a lot of the same goals. He stated these as extensible,
> object-oriented, immediate mode 2D graphics AND text. It facilitates retained
> and 3D API's above and OpenGL below.
>     http://www.cs.brown.edu/~morgan/papers/CurlGraphicsThesis.doc
> Prof. McGuire later worked with John Hughes' group at Brown, so he may have
> learned something since then that would cause him to reconsider...
>