...can't believe we're finally really so close...
...that is, until I start looking closely at some things that were on my plate:
- I don't like [camera] in it's current form, because it doesn't do what it should! ATM, it's just a kind of substitute for changing GemMan::m_lookat[] variables, which just use the gluLookAt() function...sure, this is an ok way to have a camera that "looks at" a particular point in a scene, but this doesn't seem to be the correct way to do a true "free-floating" camera, which would allow flythroughs 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?
- 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? I know, I'm mostly to blame here, because many of these objects were included by me, but until I (or someone else) has time to add a YUV path, shouldn't there be a better way of telling the user why the object is working correctly?
- I'm really starting to be against naming this "0.888": we've worked on this for too long and added too much to have some arbitrarily minimal jump from 0.87: now that we've got feature parity (excepting the above mentioned), surely we're at v1.0?
...back to work...
jamie
Zitiere James Tittle II tigital@mac.com:
...can't believe we're finally really so close...
...that is, until I start looking closely at some things that were on my plate:
- I don't like [camera] in it's current form, because it doesn't do
what it should! ATM, it's just a kind of substitute for changing GemMan::m_lookat[] variables, which just use the gluLookAt() function...sure, this is an ok way to have a camera that "looks at" a particular point in a scene, but this doesn't seem to be the correct way to do a true "free-floating" camera, which would allow flythroughs
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.)
- 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.
- 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 ?
mfg.aser IOhannes
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
James Tittle II wrote:
On Apr 7, 2004, at 5:19 AM, zmoelnig@iem.at wrote:
...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...
right, i was thinking of moving both the camera-point and the target-point. (it's just a bit of vector arithmetics;-))
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.
and while testing i have noticed that the [pix_alpha] did some very strange things with grayscale-images: converting RGB to RGBA inplace, which of course was urging for segfaults...
mfg.asdr IOhannes
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
James Tittle II wrote:
On Apr 7, 2004, at 5:19 AM, zmoelnig@iem.at wrote:
- 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...
and because of all the good vibes i have also fixed the [pix_rgba]/[pix_yuv]/[pix_grey] colourspace-conversions on macOS. so know everybody who wants to can convert between yuv and rgba and whatever (don't tell chris about it as he won't like it;-))
but what's more: with [pix_rgba] working and your checkin's of pete's plugins i suddenly noticed that some of them didn't like the alpha-channel. (gosh it was annoying: the objects now worked in yuv but when i switched to rgba everything went black - t00k me a while until i discovered that there was a leftover [alpha] that made all the textures invisible...) anyhow i (think i) have fixed this now too.
mfg.as.dr IOhannes
On Apr 7, 2004, at 12:40 PM, IOhannes m zmoelnig wrote:
and because of all the good vibes i have also fixed the [pix_rgba]/[pix_yuv]/[pix_grey] colourspace-conversions on macOS. so know everybody who wants to can convert between yuv and rgba and whatever (don't tell chris about it as he won't like it;-))
I've been working out ways to get these conversions faster and have found someone who has a library of custom color-space code for PPC and is willing to give them to me if he gets clearance (it was from failed set top box device apparently). Most of the libs, including QuickTime, have some fairly slow routines that are surprisingly common. There should really be a nice, fast cross-platform lib that does these type of utility functions, but I guess not.
cgc
Hey Chris,
Would this be a problem with Gem's free licence?
Perhaps the author would be willing to GPL it? (if they have the right to do so)
B.
chris clepper wrote:
On Apr 7, 2004, at 12:40 PM, IOhannes m zmoelnig wrote:
and because of all the good vibes i have also fixed the [pix_rgba]/[pix_yuv]/[pix_grey] colourspace-conversions on macOS. so know everybody who wants to can convert between yuv and rgba and whatever (don't tell chris about it as he won't like it;-))
I've been working out ways to get these conversions faster and have found someone who has a library of custom color-space code for PPC and is willing to give them to me if he gets clearance (it was from failed set top box device apparently). Most of the libs, including QuickTime, have some fairly slow routines that are surprisingly common. There should really be a nice, fast cross-platform lib that does these type of utility functions, but I guess not.
cgc
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
Quoting "B. Bogart" ben@ekran.org:
Hey Chris,
Would this be a problem with Gem's free licence?
Perhaps the author would be willing to GPL it? (if they have the right to do so)
It will be GPL code for sure. The author even suggested it himself.
cgc
B.
- 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 ?
I actually don't really care much about the version number as long as there is some sort of official release that we can point people to and say 'use this'.
That being said, I think we could keep the <1.0 numbers if we plan to do much more frequent releases. If we decide that we can really only maintain a yearly or so release schedule then major release numbering starting with 1.0 makes more sense to me. I don't think very many people care about the versioning these days anyway - in fact maybe only one person has asked me if 'GEM will ever get out of beta'.
cgc
On Wed, 7 Apr 2004, chris clepper wrote:
- 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 ?
I actually don't really care much about the version number as long as there is some sort of official release that we can point people to and say 'use this'.
That being said, I think we could keep the <1.0 numbers if we plan to do much more frequent releases. If we decide that we can really only maintain a yearly or so release schedule then major release numbering starting with 1.0 makes more sense to me. I don't think very many people care about the versioning these days anyway - in fact maybe only one person has asked me if 'GEM will ever get out of beta'.
I think version numbers are just version numbers, most of the people won't care. Some of them might, and those are probably happier when we have serious version numbering instead of the "joke" release 0.888
To give a new proposal, I am for 0.90. This sounds at least a bit stable and reflects the big step that gem has made after 0.87.
Guenter
On Apr 8, 2004, at 4:46 AM, guenter geiger wrote:
To give a new proposal, I am for 0.90. This sounds at least a bit stable and reflects the big step that gem has made after 0.87.
...I'm for 0.90 as much as 1.0: I know they're arbitrary, especially without a release schedule...now after all these changes, I'll need a few days to go thru and make sure things still work ;-)
l8r, jamie
I agree, 0.90 sounds great to me. 090 also looks good. ;)
B.
guenter geiger wrote:
On Wed, 7 Apr 2004, chris clepper wrote:
- 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 ?
I actually don't really care much about the version number as long as there is some sort of official release that we can point people to and say 'use this'.
That being said, I think we could keep the <1.0 numbers if we plan to do much more frequent releases. If we decide that we can really only maintain a yearly or so release schedule then major release numbering starting with 1.0 makes more sense to me. I don't think very many people care about the versioning these days anyway - in fact maybe only one person has asked me if 'GEM will ever get out of beta'.
I think version numbers are just version numbers, most of the people won't care. Some of them might, and those are probably happier when we have serious version numbering instead of the "joke" release 0.888
To give a new proposal, I am for 0.90. This sounds at least a bit stable and reflects the big step that gem has made after 0.87.
Guenter
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
On Thu, 8 Apr 2004, B. Bogart wrote:
I agree, 0.90 sounds great to me. 090 also looks good. ;)
See also 3.14159, 2.71828, 1.61803, 666, and 242.
________________________________________________________________ Mathieu Bouchard http://artengine.ca/matju
-
B. Bogart -
cgc＠humboldtblvd.com -
chris clepper
-
guenter geiger -
IOhannes m zmoelnig -
James Tittle II -
Mathieu Bouchard -
zmoelnig＠iem.at