On 24/04/07, Derek O'Connell <doconnel at gmail.com> 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.