[Bf-committers] Decimation / Surface Simplifier...

Jaevixa McNomera jjv.mnr at gmail.com
Wed Jan 12 04:29:49 CET 2011


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 <gsr.b3d at infernal-iceberg.com> wrote:

> Hi,
> sergey.forum at gmail.com (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
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>


More information about the Bf-committers mailing list