I have not played with the camera object yet (sorry).
I think having tracking, pitching and rolling is what was really missing from the gemwin view messages. As for the lookat point I think it is important that the point could be changed, especially if you want to repoint the camera from one part of the scene to another, from which point it acts as though the second part of the scene is the centre.
As for flythroughs... I'm pretty sure flythroughs are always done with tracking pathes, where the position of the camera is locked along a path (usually spline) which corrsponds to the dolly track in 3D. Now you usually have two choices, either align the camera at a single point (or another object) or align the camera to the path itself so that the camera is always pointing along a tangent of the path. I recall doing a combination of these things always a bit tricky, having the camera follow the path for a number of frames, than fix on a point, then back to the path.
The only way to get full control of the camera would be XYZ position, XYZ rotation and XYZ position of the lookat point. But this does not include the nice orbital camera movement that is most comfortable.
I think just adding controls to manually change the lookat point position makes the most sense, then it can be animated seperatly to make the camera track. In spline terms you just have the lookat point follow your path just ahead of the camera (but this would not give you tangents, as the camera would look accross the sharp corners at the tracking point!)
Does this help?
B.
James Tittle II wrote:
On Apr 7, 2004, at 5:19 AM, zmoelnig@iem.at wrote:
Zitiere James Tittle II tigital@mac.com:and such (as of now, if you "fly-thru", you always remain anchored to
the original point)...looking back on this, I remember getting stuck with the gluLookAt() method, because it's so integral in the gemchain :-( ...anyone have other ideas?
i don't undestand the exact problem. glLookat can handle original points: you can realize a "fly-thru" with "view"-messages (although i admit that it is rather nasty that you have to do everything by hand, instead of simple "roll"ing etc.)
...ok, what I mean by fly-thru is moving freely about a scene...sure, this works ok as long as you are approaching the "lookat" object/point, but if you go "through"/pass by the point, all of a sudden you are flipped around so that you are looking at it again...that's what I don't like...
...the gluLookat() based camera can be imagined as a sphere surrounding a point, with the camera on the surface of the sphere always looking at the center...to go "forward", the sphere gets smaller, until you arrive at center point: then you automatically flip around and look back at the object...I guess what you are talking about is a way around this where the "lookat" point is constantly changing? That sounds like a lot of work, and I was hoping for a simpler, more generalized solution...
- pix_objects that don't have the ability to deal with a certain pixel
format just return "pix object cannot handle *", which isn't very informative: what if someone has many pix's, but only one isn't supporting the needed pixel format?
indeed i have always wanted the objects to know their own name. since you requested it, i have checked it into the CVS now: so the error now is more like "pix object [pix_alpha] cannot handle YUV". but of course, still the user has no clue about what could be done on their side to fix this.
...great! I'll check it out...but then, I noticed your quick n'dirty method of getting pix_kaleidascope to work in YUV, so I've gone thru and changed the other "pete's-plugins-ports"...not in cvs yet, but should be by the end of the day...
- I'm really starting to be against naming this "0.888": we've worked
the above mentioned), surely we're at v1.0?
well, as i have said before, i am afraid of "1.0" anyhow, if all (or most) of the developers prefer v1.0 then we should just make it. so chris, daniel, günter ?
yay!
jamie
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev