Hi everyone! :) No worries about ASM issues, I did it all inside one function and it's easy to pre-process it out :) I knew it'd be a problem from the start but still wanted to see how much faster it'd get if I did one version almost completely in ASM.
As for the different simplification algorithms, they are selectable during runtime from inside the modifier panel. (like how we can pick anti-aliasing method now in the render panel...) In reply to a few of the mails in this list: HI Moguri!!!!!! :) It's nice to see a familiar name in here! (I miss all of you!!!) I will do my best to get on IRC but the WiFi in the hospital here is weak signal where I am. About Quad Remeshing, already taken into consideration. :) I constructed the mesh reducer in such a way that you can specify a topological output model of whatever you'd like. Could anyone reading this send me a real-life 3-4 million polygon object for me to test against? The largest real world usage object I've tested was a little over 2 million, and I'd sure like to try it on some other cool stuff. :) Regarding BMesh, I spoke with Joeedh at length about this a while back. So long as nothing major has changed in BMesh since then, it'll work fine with ngon input, and can create ngon output as well. I also discussed some finer points of this system with ZanQdo about how this would affect a mesh with vertex groups used with an armature. We can still discuss it, but with his wisdom and experience in animating, I think he filled me in on all the most important things to consider. :) **thanks Danny!** If there is anyone reading this that worked on the rendering engine or the baking system, I do have a question or two... I can explain in great detail in another email. And Ton, you're the best! The first time I got to put a real shirt on instead of just a hospital gown, I put on the custom blender tshirt!!!! Thanks SO much!!!!!!!!!! Well, Hi again to all my friends out there! I miss you all a whole bunch!!!! and I don't have your email but I miss you too Briggs! God Bless you everyone! -- I moved BOTH my ankles for the 1st time today in MONTHS!!!! AAHH!!!! I'm so excited! Can't wait to walk again! Jae :) On Tue, Jan 11, 2011 at 3:11 PM, GSR <[email protected]> wrote: > Hi, > [email protected] (2011-01-11 at 1031.06 +0300): > > If asm is not 'build in' c code or can be modularized into separate files > > then maybe http://www.tortall.net/projects/yasm/ can be used - it is > > fairly portable across platforms. > > > > it is still should be decided if asm at all is acceptable, but at > > least - this way - it will be one code for all platforms. > > Define "all platforms". :] PPC is in the way out, but what if ARM > catches in general computers? Or what would do Debian anyway? They > ship for many plataforms, small or big "market", they do not care. Or > what if the ASM is SSEx level? AMD64 means SSE2 but does not guarantee > SSE4, and X86 CPU with just SSE1 are still running fine. > > The sane way is having C generic version and then optional ASM > versions that do the same but faster. The reason is two fold, first > compatibility fallback, second a good reference to check the results > match. If you are lucky the compiler generates a rather good op code > stream from the plain C and then you just save time trying to maintain > the hand made ASM. > > GSR > > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
