[GEM-dev] rc3 thoughts

B. Bogart ben at ekran.org
Wed Apr 7 16:16:59 CEST 2004


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 at iem.at wrote:
> 
>> Zitiere James Tittle II <tigital at 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 at iem.at
> http://iem.at/cgi-bin/mailman/listinfo/gem-dev
> 
> 




More information about the GEM-dev mailing list