I want to clarify that it is not mainly a lack of time or resources that has motivated this decision of ours. It is a design choice that we've made to promote good practice. So although contributions on many parts of the engine are welcome, and Ross is right about that, I would not encourage anyone to submit a patch for this because it will likely not be accepted.
A general-purpose system for this might make it into the engine at some point in time, but again, if you're feeling like contributing focus on something else for now. :) Cheers /R On Jun 21, 6:33 pm, Ross Smith <[email protected]> wrote: > I have been blown away by the responsiveness and supportiveness of the > Away3D team. They make time around their personal lives to keep this engine > going strong. Thank you Richard for all the work you have contributed - and > that goes for Fabrice, Peter, Rob, and all the other devs who have made > Away3D possible. > > Makc, there's a saying that goes around a non-profit corporation that I help > to manage : "Thanks for volunteering." Whenever someone says the word > "should" as though the great vast void will do work for them, we laugh. And > then we say, "That *should* happen, eh? Great. Thanks for volunteering." > > If you want to see it done, write the patch and submit it to the Away3D > team. That's how open source works. > > --Ross > > > > > > > > > > On Tue, Jun 21, 2011 at 12:08 PM, richardolsson <[email protected]> wrote: > > Makc, if you don't feel like the Away3D team care about our users (the > > programmers) then that's unfortunate. We do very much care about the > > programmers and the products that they create using our engine, which > > is why we want to encourage good practice. If your artists are > > incapable of resizing textures then maybe you can do it for them? > > Write a script that does it, the programmer way. I don't see why (and > > I'm sure your product owner agrees) users should have to download > > textures that are often too big just to then have their CPU scale them > > down. Store and deploy them with the right size, which will decrease > > both loading and initialization time. > > > As far as the video material is concerned, that entire system in > > broomstick is a contribution that has not yet gone through proper > > review (as is often the case in an open-source project's alpha cycle) > > but chances are we will keep some sort of dimensions check there since > > in that particular material the engine is creating the bitmap and > > hence there is no way for the programmer to control it. In a bitmap > > material the bitmap is an external file and you have the option to > > resize it. > > > Know though that your feature request (or whatever you meant for it to > > be) has been noted and we will consider adding some sort of automatic > > resizing, although as previously stated it will most likely be turned > > off by default. > > > Cheers > > /R > > > On Jun 21, 3:30 pm, makc <[email protected]> wrote: > > > check out what I just found in your VideoMaterial: > > > > trace("Warning: "+ size + " is not a valid material size. Updating to > > > the closest supported resolution: " + validSize); > > > > :-P''' > > > > what about some consistency? > > -- > Ross Smith > [email protected]
