hi IOhannes! in 1st place, THANKS for implementing this feature ;) you realy make me happy. i installed your experimental win build and it works great, when i add the gem directory to file/paths. only when i do so, pd crashes when i load a .mov using pix_film or pix_movie. when i remove the Gem path from file/paths again, pix_film and pix_movie work fine again, - but no more uv coordinates...is it a bug? or am i doing something wrong? im using pd extended 0.40.3 on winXP
thanks for doing all this sebastian
IOhannes m zmoelnig wrote:
hi.
i have just added UV-texture support to [model].
now, UV-texcoords are automatically applied if present in the model (with a fallback to the old-standard "linear" texmaps); you can manually select UV-tex via [texture 2( (uäh)
please test whether this change has broken something with the other (linear/spheremap) texturing, esp. if you have additionally used [pix_coordinates]
fgmSDR IOhannes
sebastian pirch wrote:
hi IOhannes! in 1st place, THANKS for implementing this feature ;) you realy make me happy. i installed your experimental win build and it works great, when i add the gem directory to file/paths. only when i do so, pd crashes when i load a .mov using pix_film or pix_movie. when i remove the Gem path from file/paths again, pix_film and pix_movie work fine again, - but no more uv coordinates...is it a bug? or am i doing something wrong? im using pd extended 0.40.3 on winXP
thanks for doing all this sebastian
hallo sebastian,
I am not on Windows, so I cannot reproduce your problem. where did you put your Gem.dll? did you replace the one that comes with pd-extended? what does the pd console say on startup (version number)?
usually you don't have to change the path, but load the library in file/startup.
but all that should not crash pd. hmmm... mayce this is a bug?
marius.
IOhannes m zmoelnig wrote:
hi.
i have just added UV-texture support to [model].
now, UV-texcoords are automatically applied if present in the model (with a fallback to the old-standard "linear" texmaps); you can manually select UV-tex via [texture 2( (uäh)
please test whether this change has broken something with the other (linear/spheremap) texturing, esp. if you have additionally used [pix_coordinates]
fgmSDR IOhannes
sebastian pirch wrote:
hi IOhannes! in 1st place, THANKS for implementing this feature ;) you realy make me happy. i installed your experimental win build and it works great, when i add the gem directory to file/paths. only when i do so, pd crashes when i load a .mov using pix_film or pix_movie. when i remove the Gem path from file/paths again, pix_film and pix_movie work fine again, - but no more uv coordinates...is it a bug? or am i doing something wrong? im using pd extended 0.40.3 on winXP
thanks for doing all this sebastian
hallo sebastian,
I am not on Windows, so I cannot reproduce your problem. where did you put your Gem.dll? did you replace the one that comes with pd-extended? what does the pd console say on startup (version number)?
usually you don't have to change the path, but load the library in file/startup.
but all that should not crash pd. hmmm... maybe this is a bug?
marius.
IOhannes m zmoelnig wrote:
hi.
i have just added UV-texture support to [model].
now, UV-texcoords are automatically applied if present in the model (with a fallback to the old-standard "linear" texmaps); you can manually select UV-tex via [texture 2( (uäh)
please test whether this change has broken something with the other (linear/spheremap) texturing, esp. if you have additionally used [pix_coordinates]
fgmSDR IOhannes
hi again, btw, can someone post a working model + UV texture, I tested some models, but don't think they were working properly. there was clearly a difference between texture 0, 1 and 2, but the texture was not mapped in the expected way. marius.
sebastian pirch wrote:
hi IOhannes! in 1st place, THANKS for implementing this feature ;) you realy make me happy. i installed your experimental win build and it works great, when i add the gem directory to file/paths. only when i do so, pd crashes when i load a .mov using pix_film or pix_movie. when i remove the Gem path from file/paths again, pix_film and pix_movie work fine again, - but no more uv coordinates...is it a bug? or am i doing something wrong? im using pd extended 0.40.3 on winXP
thanks for doing all this sebastian
IOhannes m zmoelnig wrote:
hi.
i have just added UV-texture support to [model].
now, UV-texcoords are automatically applied if present in the model (with a fallback to the old-standard "linear" texmaps); you can manually select UV-tex via [texture 2( (uäh)
please test whether this change has broken something with the other (linear/spheremap) texturing, esp. if you have additionally used [pix_coordinates]
fgmSDR IOhannes
sebastian pirch wrote:
hi IOhannes! in 1st place, THANKS for implementing this feature ;) you realy make me happy. i installed your experimental win build and it works great, when i add the gem directory to file/paths. only when i do so, pd crashes when i load a .mov using pix_film or pix_movie. when i remove the Gem path from file/paths again, pix_film and pix_movie work fine again, - but no more uv coordinates...is it a bug? or am i doing something wrong?
it's surely a bug (but that's what we have experimental builds for, no?) which version of QuickTime do you have installed on your system?
fgmasdr IOhannes
IOhannes m zmoelnig wrote:
sebastian pirch wrote:
hi IOhannes! in 1st place, THANKS for implementing this feature ;) you realy make me happy. i installed your experimental win build and it works great, when i add the gem directory to file/paths. only when i do so, pd crashes when i load a .mov using pix_film or pix_movie. when i remove the Gem path from file/paths again, pix_film and pix_movie work fine again, - but no more uv coordinates...is it a bug? or am i doing something wrong?
it's surely a bug (but that's what we have experimental builds for, no?) which version of QuickTime do you have installed on your system?
ah, and since i just remembered a bug i fixed recently (probably only in the 0.91 branch): does it crash if you are disconnecting [pix_film] from the following [pix_texture]? (obviously you won't get the image textured on anything then)
fgamsdr IOhannes
marius schebella wrote:
hi again, btw, can someone post a working model + UV texture, I tested some models, but don't think they were working properly. there was clearly a difference between texture 0, 1 and 2, but the texture was not mapped in the expected way.
that's the model i used for testing whether it works...
fgmasrd IOhannes
IOhannes m zmoelnig wrote:
marius schebella wrote:
hi again, btw, can someone post a working model + UV texture, I tested some models, but don't think they were working properly. there was clearly a difference between texture 0, 1 and 2, but the texture was not mapped in the expected way.
that's the model i used for testing whether it works...
hmm, I compiled todays svn trunk version and before the one from jan 22 and also tried the pd-extended version from jan21st. I think there were no changes between all these(?). I get different results for texture 0, texture 1 and texture 2, but texture 2 is not correct. see http://www.parasitaere-kapazitaeten.net/files/textures_uv.zip MacOSX 10.5.6, ATI Mobility Radeon X1600, MBP, Pd 0.41 Gem ver: 0.92.CVS. Marius.
marius schebella wrote:
IOhannes m zmoelnig wrote:
marius schebella wrote:
hi again, btw, can someone post a working model + UV texture, I tested some models, but don't think they were working properly. there was clearly a difference between texture 0, 1 and 2, but the texture was not mapped in the expected way.
that's the model i used for testing whether it works...
hmm, I compiled todays svn trunk version and before the one from jan 22 and also tried the pd-extended version from jan21st. I think there were no changes between all these(?). I get different results for texture 0, texture 1 and texture 2, but texture 2 is not correct. see http://www.parasitaere-kapazitaeten.net/files/textures_uv.zip MacOSX 10.5.6, ATI Mobility Radeon X1600, MBP, Pd 0.41 Gem ver: 0.92.CVS. Marius.
hmm, it might be a problem with the loading order.
try manually loading the image (or the model; can't remember which) first, by sending explicit [open( messages. it might be related to linux using threads to load the image (thus it might appear a bit after the model is loaded)...
fmgasdr IOhannes
IOhannes m zmoelnig wrote:
marius schebella wrote:
IOhannes m zmoelnig wrote:
marius schebella wrote:
hi again, btw, can someone post a working model + UV texture, I tested some models, but don't think they were working properly. there was clearly a difference between texture 0, 1 and 2, but the texture was not mapped in the expected way.
that's the model i used for testing whether it works...
hmm, I compiled todays svn trunk version and before the one from jan 22 and also tried the pd-extended version from jan21st. I think there were no changes between all these(?). I get different results for texture 0, texture 1 and texture 2, but texture 2 is not correct. see http://www.parasitaere-kapazitaeten.net/files/textures_uv.zip MacOSX 10.5.6, ATI Mobility Radeon X1600, MBP, Pd 0.41 Gem ver: 0.92.CVS. Marius.
hmm, it might be a problem with the loading order.
try manually loading the image (or the model; can't remember which) first, by sending explicit [open( messages. it might be related to linux using threads to load the image (thus it might appear a bit after the model is loaded)...
loading either one first does not make a difference :(. I am not sure how I could provide you with additional information. what do you need to know? to me it looks strange that I only see stripes. with the old version of gem I saw the image projected from above when I used texture 0 and mapped onto the model (not the ground) when using texture 1 (but of course not putting the things at the right place.) but now all three textures look very similar like they was only 1 dimension. marius.
fmgasdr IOhannes
marius schebella wrote:
loading either one first does not make a difference :(. I am not sure how I could provide you with additional information. what do you need to know? to me it looks strange that I only see stripes. with the old version of gem I saw the image projected from above when I used texture 0 and mapped onto the model (not the ground) when using texture 1 (but of course not putting the things at the right place.) but now all three textures look very similar like they was only 1 dimension. marius.
you were right. a fix should be in svn by now. until then, use a [pix_flip] right before [pix_texture] to get the image orientation right, which will magically make UV-texturing work for you :-)
fgmasdr IOhannes
IOhannes m zmoelnig wrote:
marius schebella wrote:
loading either one first does not make a difference :(. I am not sure how I could provide you with additional information. what do you need to know? to me it looks strange that I only see stripes. with the old version of gem I saw the image projected from above when I used texture 0 and mapped onto the model (not the ground) when using texture 1 (but of course not putting the things at the right place.) but now all three textures look very similar like they was only 1 dimension. marius.
you were right. a fix should be in svn by now. until then, use a [pix_flip] right before [pix_texture] to get the image orientation right, which will magically make UV-texturing work for you :-)
actually it is still NOT fixed in svn. however, [pix_flip] should help you for now (just put it into the chain and don't set anything: by default it will fix any orientation issues)
mfgasdr IOhannes
IOhannes m zmoelnig wrote:
IOhannes m zmoelnig wrote:
marius schebella wrote:
loading either one first does not make a difference :(. I am not sure how I could provide you with additional information. what do you need to know? to me it looks strange that I only see stripes. with the old version of gem I saw the image projected from above when I used texture 0 and mapped onto the model (not the ground) when using texture 1 (but of course not putting the things at the right place.) but now all three textures look very similar like they was only 1 dimension. marius.
you were right. a fix should be in svn by now. until then, use a [pix_flip] right before [pix_texture] to get the image orientation right, which will magically make UV-texturing work for you :-)
actually it is still NOT fixed in svn. however, [pix_flip] should help you for now (just put it into the chain and don't set anything: by default it will fix any orientation issues)
it's working!!! this is exciting. the world is not flat anymore! thanks. marius.
mfgasdr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Hello
It does not work with me. I use the Gem release 0.93.3 on MacIntel. What is the good release?
Thanks!
tw
Le 24/08/09 22:05, « marius schebella » marius.schebella@gmail.com a écrit :
IOhannes m zmoelnig wrote:
IOhannes m zmoelnig wrote:
marius schebella wrote:
loading either one first does not make a difference :(. I am not sure how I could provide you with additional information. what do you need to know? to me it looks strange that I only see stripes. with the old version of gem I saw the image projected from above when I used texture 0 and mapped onto the model (not the ground) when using texture 1 (but of course not putting the things at the right place.) but now all three textures look very similar like they was only 1 dimension. marius.
you were right. a fix should be in svn by now. until then, use a [pix_flip] right before [pix_texture] to get the image orientation right, which will magically make UV-texturing work for you :-)
actually it is still NOT fixed in svn. however, [pix_flip] should help you for now (just put it into the chain and don't set anything: by default it will fix any orientation issues)
it's working!!! this is exciting. the world is not flat anymore! thanks. marius.
mfgasdr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
Thibault Walter wrote:
Hello
It does not work with me. I use the Gem release 0.93.3 on MacIntel. What is the good release?
the good release has never been released yet. otoh, 0.93.3 (which has not been released either) surely already has the fix included.
i'm planning a release pretty soon (in order to avoid cyrille pestering me more :-))
gfmasdr IOhannes
IOhannes m zmoelnig a écrit :
i'm planning a release pretty soon (in order to avoid cyrille pestering me more :-))
THANKS! cyrille
gfmasdr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev