Re: [Bf-committers] Decimation / Surface Simplifier...
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 wrote: > Hi, > sergey.fo...@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@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Decimation / Surface Simplifier...
Hi, sergey.fo...@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@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Decimation / Surface Simplifier...
Thanks for the replies everyone! I'll leave the one ASM algorithm in the code but simply #ifdef it out for now. Is that reasonable? On the topic of quad remeshing, it does already support different topologies for input. In the screenshots all the meshes came out triangles, but Jae did end up making it work for quads, as well as BMesh ngons. She discussed this with Joe (I think...) a while back and has a very flexible system for both inputs and outputs. Additionally, in one of the algorithms, which she was just finishing up when she was hurt, the user can specify a particular output topology, no matter what the input is. I'm still pouring over the code to get all the specifics worked out, but that one does not reduce the input mesh by iterative edge collapses. Instead (again, one of the 4 different algos) it creates a "ball" of very small size somewhere near the mesh containing exactly the user-specified number of output faces, constructed of the correct topology to start with, and it appears to use some form of fluid dynamics calculations to "expand" the little ball until it optimally rests fitting the shape of the input mesh. She made it work like that so the input and output topologies were decoupled and it opens a whole word of possibilities. Or so it seems... Hoping to have more to show by early next week. I'll be going over to hospital for several hours each night this week to discuss this at length with Jae so I can get a better understanding of how it all works. Hoping to have a demo or something worthy of showing soon. As for BGE, I'll try my best to get in touch with you moguri :) Thanks! Peter On Tue, Jan 11, 2011 at 5:37 AM, Sergey Kurdakov wrote: > Hi Pete, > > for multiplatform asm also consider > http://x264dev.multimedia.cx/archives/191 , > together with yasm it makes multiplatform asm programming to be feasible. > > Regards > Sergey > ___ > Bf-committers mailing list > Bf-committers@blender.org > http://lists.blender.org/mailman/listinfo/bf-committers > ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Decimation / Surface Simplifier...
Hi Pete, for multiplatform asm also consider http://x264dev.multimedia.cx/archives/191 , together with yasm it makes multiplatform asm programming to be feasible. Regards Sergey ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Decimation / Surface Simplifier...
Hi Pete, cannot resist, but if there are several algorithms, then simplification can and should be combined with quad remeshing - as it is in the same domain see https://svn.blender.org/svnroot/bf-blender/branches/soc-2010-rohith291991/ - the author promised add something more (he estimated two weeks more time to be spent), but did not, but still code should be fairly usable, then take a look at paper http://openflipper.org/uploads/media/bommes_zimmer_2009_siggraph_01.pdf and also code used to perform things http://openflipper.org/index.php?id=271#c2029 in case you can pick this together with Jaevixa's simplifier that will be great. as for OpenCL - seems both Nvidia http://developer.nvidia.com/object/cuda_3_2_downloads.html and AMD ( announced but never seen ) moves in a direction so you can use plain C at GPU. Overall - rule of thumbs - features first, optimization next. While asm/OpenCL might be beneficial - that can be added when the whole concept is tested and integrated into designers workflow. Regards Sergey ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Decimation / Surface Simplifier...
Hi 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. Regards Sergey ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Decimation / Surface Simplifier...
I'm usually hanging out in the IRC channel (#blendercoders on Freenode) if you want to talk about BGE topics. Cheers, Mitchell Stokes (Moguri) ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
Re: [Bf-committers] Decimation / Surface Simplifier...
On Mon, Jan 10, 2011 at 03:30:52PM -0600, pete larabell wrote: > > Anyway, my questions to the developer community are this: > > Is it ever acceptable to have parts written in assembly? > -- note: Jae has 4 different algorithms implemented currently, one of which > uses quite a bit of ASM. The only problem with assembly code is porting and maintaining it on the umpteen platforms we support. -- Stephen Swaney sswa...@centurytel.net 231-271-7371 ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
[Bf-committers] Decimation / Surface Simplifier...
Hi all, A few weeks ago I officially picked up Jaevixa McNomera's code base for the high quality (and ridiculously fast) surface simplifier she was making for Blender before she was incapacitated. If it helps to remind anyone interested, here were some shots she took back when she was working on it. > > http://www.pasteall.org/pic/1077 > http://www.pasteall.org/pic/1078 > http://www.pasteall.org/pic/1079 > http://www.pasteall.org/pic/1080 > http://www.pasteall.org/pic/1081 > http://www.pasteall.org/pic/1082 > http://www.pasteall.org/pic/1083 > http://www.pasteall.org/pic/1084 > Thus far I have it working in Blender but with some definite bugs and some areas where the code is quite ummm... complex and without documentation. :) Anyway, my questions to the developer community are this: Is it ever acceptable to have parts written in assembly? -- note: Jae has 4 different algorithms implemented currently, one of which uses quite a bit of ASM. Is it worth trying to port this to OpenCL??? Are there any BGE devs I could talk to about how that end of a LOD modifier would work?? (I know nothing about BGE) Thanks, Peter ___ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers
