K, I see what you mean here. Shouldn't be a big problem... Fabrice
On Feb 25, 2010, at 12:25 AM, Mike Kelley wrote: > > the Mdf2.load() should load the BitmapFileMaterial from a url *relative* ... > > Typo -- meant Md2.load(), not Mdf2.load() > > On Wed, Feb 24, 2010 at 3:23 PM, Mike Kelley <[email protected]> wrote: > Hi Fabrice, btw great work on Away3D, thanks from another happy user :) > > To clarify: a pcx parser would be ok but that's not what I'm asking -- > personally, I'm fine skipping pcx support. (I think mapping pcx to a more > common format may be the right design, as pcx is kind of hassle to deal with > nowdays. png seems smaller anyway.) > > What I was suggesting is that the Mdf2.load() should load the > BitmapFileMaterial from a url *relative* to the md2 file path. Right now it I > can't load a pair of foo.md2 & foo.png by just passing a url, e.g. > Md2.load("http://models.myapp.com/foo.md2") does not work because the loader > tries to load the bitmap from "foo.png" instead of > "http://models.myapp.com/foo.png". > > Or, if that does not seem right, maybe it could support texturePath for the > load path... > > mwk > > > On Wed, Feb 24, 2010 at 2:03 PM, Fabrice3D <[email protected]> wrote: > Sorry for the slow answer, > was at FITC... > > This is actually a temp state. a pcx parser is not yet implemented, but > should be added in a not too far > future, since Makc provided me a parser for this format. The actual code, is > just allowing to load/change > the pcx embedded file with another resource. The url is the filename (with > extraction of the pcx extension) > Its triggered only if am image is embedded into the original file. > so the code is expecting to found the file [filename]+extension either png or > jpg replacement next to the md2 file. > I have some new work to do on Prefab ex/importers, so while at it, i'll see > if I cannot speed up the implementation of it. > > Fabrice > > On Feb 22, 2010, at 6:08 PM, mwk wrote: > > > Hi, I'm loading an md2 file & texture from a url, e.g.: http://foo/bar/1.md2 > > and http://foo/bar/1.png > > > > I expected I could call Md2.load and have it automatically load the > > mesh and and the texture, like so: > > var path:String = "http://foo/bar/"; > > loader = Md2.load(path + "1.md2", {pcxConvert:"png"}); > > > > But the above does not load the texture. Instead I have to explicitly > > load the texture: > > var material:BitmapFileMaterial = new BitmapFileMaterial(path + > > "1.png"); > > loader = Md2.load(path + "1.md2", {material:material}); > > > > Looking at Md2.as, the issue is the loader uses the texture name from > > the .md2 file as an absolute path, so although the pcxConvert param > > successfully maps the texture name to 1.png, it tries to load "1.png" > > instead of "http://foo/bar/1.png". > > > > Here's the code from MD2.as: > > //overridden by the material property in constructor > > if (material) { > > mesh.material = material; > > } else if(url.substring(url.length -4, url.length -3) == "."){ > > if(url.toLowerCase().indexOf("pcx") != -1){ > > url = url.substring(-1, url.length -3) + pcxConvert; > > } > > trace("Material source: "+url+". Pass pcxConvert:'gif' or 'png' to > > load other file types. ..."); > > mesh.material = new BitmapFileMaterial(url); > > } > > > > Just for fun I tried setting texturePath explicitly but it has no > > effect (and I don't see it in the code above): > > loader = Md2.load(path + "1.md2", {pcxConvert:"png", > > texturePath:path}); > > > > Questions: > > - Am I just doing something dumb here? Is there something I should be > > setting up so the loader looks in the right path? > > - If not... should the md2 loader treat the texture as a relative > > path? What's the convention for the other loaders? (imho it should, as > > the md2 texture name is only 64 chars so not intended to be carrying > > full urls etc) > > - Or maybe it should just support the texturePath parameter? That > > might be an easy solution. Do the other loaders use texturePath? > > > > Thanks! > > > > btw all the md2 examples I found avoid the issue by loading and > > assigning the texture like my workaround. > > >
