> 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 <m...@huchley.com> 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 <fabric...@gmail.com> 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.
>>
>>
>

Reply via email to