r.hauwert at gmail.com
Thu Dec 6 14:50:04 PST 2007
I'm not sure if I'm 100% understanding what you are saying, or if I might be
mis interpreting you. It seems like you are using an automated translator to
translate ? This might also explain you taking Tim's comment out of context.
Ok, about your ideas for the interaction and key events; I found your
earlier mail, and had a good look at it. In your mail you state "why making
somthing so hybird and abstract"; which I take for "Why make something so
hybrid and abstract". Ok, here's the why. The Flash universe is huge in
diverse if you look at it from a standpoint of peoples ways of going about
coding and implementing something. Flash is good at catering a wide variety
of people wanting to work with it in their coding and implementation,
because for the most part it doesn't 100% govern what a solution is. It
gives the freedom of implementing something the way you need it to be; this
is not only code wise, but also time and budget wise a huge factor. We've
tried to follow the Flash analogy to some extent; some of the philosophy is
not to implement 1 of the tweening engines, rather then keeping it open to
We have tried to keep the core parts of the engine free from any direct
implementation up to so far and as you might have noticed; the engine has
became quite succesfull. That being said, let's move on to the idea you
tried to convey in your sourcecode.
DisplayObject3DEvent - We have no intention of directly binding key presses
to specific objects; and we shouldn't. PV3D and the Flash API are sufficient
- sorry, no go; this would limit the engine rather then help it.
DisplayObject3DEventDispatcher - In the current setup, DisplayObject3D IS an
eventdispatcher, I wouldn't see any advantage at this point, to seperate
that logic. This class looks primarily aimed at dispatching mouse events..we
already do that.
UserInterface - You might want to explain the use of that class to me, since
I'm not sure if I'm getting it. It seems to be an intermediate class to map
events to specific object functions. This would be a class which you'd built
when you build an implementation with the engine, not a class which should
reside in the engine.
DisplayObject3D Control - You've abstracted the movement code for the
objects ? Please explain motivation. As for the movement functions; some of
these seem very handy, maybe we can use them inside DisplayObject3D. I'll
let you know if we use them.
Hope this answers your question,
On Dec 6, 2007 9:01 PM, alex winx <winxalex at yahoo.com> wrote:
> I've point couple of times to bad idea of InteractiveSceneManager. I can
> graditute to stuborn forcing of it. Why making somthing so hybird and
> abstract. Lack of making more instances more settings for controling one or
> many 3D objects. Lack of wiring keyevents and focus key inputs to some 3D
> object. I've try to tell this and even i've made InteractiveScene2 just to
> point to the idea. But no. And God behavior continue so noone even return
> comment or different arguments and confront me. On other way as Tim said
> "people are dumb". On top of that natural way of AS3 events is missed so
> people get confused and must look in InteractiveSceneManager source to
> learn how to use it and make spagheti code with outside function handlers as
> in tutorials. Don't even mention performace issue despite of good idea of
> Mouse3D and UV tex interface.
> Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it
> Papervision3D mailing list
> Papervision3D at osflash.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Papervision3D