ah yes, good point about keeping such overhead out of the end-user side. And thanks for all the help you have been providing as I learn the framework. Hopefully some of these exchanges will be helpful in the documentation stage
On May 16, 3:26 am, richardolsson <[email protected]> wrote: > @Choons: > It's something that we are discussing, but we are leaning towards > having the programmers take care of that themselves, and not try to do > their work for them (and keeping them in the dark about it). If the > error isn't thrown, people might never know that this is something > that needs to be taken care of, and hence end up relying to heavily on > the library to do janitor work for them. In the end, that means that > image processing (possibly for hundreds of images in a game level) > that could have been done better in Photoshop at author-time is > instead done on every single CPU that runs the game, and that's not > good for anyone. > > Basically, our philosophy is that Away3D should be as simple as > possible, but still a programmer's tool and a programmer should be > expected to do certain things themselves. > > What we definitely should do however is prevent that player error and > instead throw a nicer-looking one that explains the issue properly. > > Cheers > /R > > On May 16, 10:08 am, Choons <[email protected]> wrote: > > > > > > > > > yep changing the texture image to a power2 512 X 512 square solved the > > problem. I didn't know I could stretch a mapped texture like that and > > still have it look right, so thanks for that bit of knowledge! Peter > > Stromberg's wave demo posted in this forum has a function in it that > > takes any bitmap input and makes a power2 square out of it. If I > > understand correctly, the square image thing has to do with how the > > hardware handles things. It might make sense to have a utility > > function like that in the parser if it requires square bitmap data to > > work with? > > > On May 16, 2:28 am, richardolsson <[email protected]> wrote: > > > > A couple of pointers: > > > > 1) You should be able to set (or modify) the material either on > > > ASSET_COMPLETE or RESOURCE_COMPLETE. So there you should be able to > > > set the mipmap property. Currently some parsers have the problem that > > > they return a mesh (via ASSET_COMPLETE) even before it's material has > > > been finalized. If that's the case with OBJParser (I can't remember > > > right now) then there might be a problem with doing it on > > > ASSET_COMPLETE, but you should be able to do it on RESOURCE_COMPLETE. > > > > 2) UV coordinates are relative, so as long as you're not changing the > > > crop box of the texture, you can change it's dimensions all you want > > > and it will still work. Just try it. Use "Resize Image" (not "Resize > > > Canvas") in Photoshop and scale it up to 1024x1024 (or preferably > > > something smaller like 512x512 for the sake of saving memory.) You'll > > > see that there is no visible difference once mapped to a 3D object. > > > > Cheers > > > /R > > > > On May 16, 9:04 am, Choons <[email protected]> wrote: > > > > > Hi Richard - I'm still using this approach since it's so clean: > > > > > AssetLibrary.enableParser(OBJParser); > > > > AssetLibrary.addEventListener(AssetEvent.ASSET_COMPLETE, > > > > onLoadComplete); > > > > AssetLibrary.load(new URLRequest("../some.obj")); > > > > > onLoadComplete(event : AssetEvent):void { > > > > if (event.asset.assetType == AssetType.MESH) { > > > > mesh = event.asset as Mesh; > > > > } > > > > > } > > > > > I'm not even declaring any material since it will automatically get it > > > > from the mtl and the image file it references and assign it to the > > > > mesh. That's brilliant how that works, but then there is apparently no > > > > way to set the mipmap property to false? The textures are already UV > > > > mapped so I don't want to change their dimensions. The code above > > > > worked very well with a different very complex OBJ model, mtl and > > > > image file so I know it does work. I guess the question is how to > > > > access the material properties when taking this approach. > > > > > On May 16, 1:33 am, richardolsson <[email protected]> wrote: > > > > > > Bitmaps should be recognized and if they are not then that's a bug > > > > > that i will fix. Thanks for letting us know! > > > > > > The texture error I'm not sure about, but have you tried with a square > > > > > texture, or disabling mipmapping on the material before the first > > > > > render()? > > > > > > /R > > > > > > On May 16, 6:38 am, Choons <[email protected]> wrote: > > > > > > > So I have been trying to get Broomstick to load some old obj/mtl > > > > > > files > > > > > > from CB Model Pro. First I was getting 'unable to load mtl' errors > > > > > > until Richard told me I should use the GitHub build. Did that, and > > > > > > the > > > > > > load error went away, but then I was getting Error #2044: Unhandled > > > > > > IOErrorEvent:. text=Error #2124: Loaded file is an unknown type. > > > > > > Looking at the mtl and texture file I noticed it uses a .bmp texture > > > > > > which I thought may be the issue, so I saved a jpg version of the > > > > > > bmp > > > > > > texture and changed the mtl to reference that instead. Now I'm > > > > > > getting > > > > > > Error #3700: A texture sampler binds an incomplete texture. Looking > > > > > > around on the forum here I see it might be mipmap or power2 issue. > > > > > > The > > > > > > jpg version of the texture is 256 X 1024 so that's power2 but not > > > > > > square so don't know if that's a problem. Anyone had/solved this > > > > > > kind > > > > > > of problem?
