Thursday, June 19, 2008

MFC host Winform and WPF

非托管的vc工程中部分文件使用.Net Framwork

http://www.cppblog.com/mzty/archive/2006/08/17/11334.html

C++/CLI与C#常用语法对比

http://www.cppblog.com/mzty/archive/2008/06/02/51878.html

Host Winform in MFC Dialog:

http://www.voidnish.com/Articles/ShowArticle.aspx?code=MfcWinFormsOff

http://msdn.microsoft.com/zh-cn/magazine/cc163605(en-us).aspx

Host WPF in MFC Dialog:

http://www.codeguru.com/cpp/cpp/cpp_managed/interop/article.php/c14589/

C#调用COM组件:
http://hi.baidu.com/buildingit/blog/item/0fa9d382c91f43bd6c8119a5.html


C#调用C++写的非托管的DLL中导出的函数
http://hi.baidu.com/buildingit/blog/item/5c89d625b673d36234a80fd8.html

所谓混合类是指CLI/C++中native的Class中可以包含CLR对象,CLR的class也可以包含Naitve的对象。
1)native的class中包含CLR对象,必须通过gcroot<>或auto_gcroot<>。

2)CLR中的class中包含native的对象,必须是指针,也可以使用高手写的CAutoNativePtr智能指针。


注意:C#中不能调用CLI/C++中的Native的class。同样Native C++中也不能调用CLI/C++中的Ref的class。

Native C++的project调用C#的DLL,一般有3中方法:
1)通过COM封装
2)通过CLI/C++的Wrapper
3) 在VS中可以直接修改NativeC++的project或是部分文件为使用CLR来调用C#的DLL

Thursday, June 12, 2008

迪斯尼经典运动规律(转)

以下就是十条最经典的动画规律的详细讲解。


一、Squash and Stretch压缩与伸展


    这是影响最深远的一项动画原理。在人物或对象的动作传递过程中,拉扯与碰撞等互动性动作都会做出压缩与伸展的表现,透过这个动作,也表现出物体的质感与量感。


    这不见得是真实的物理表现,可是一般人却期待在动画中看到这种夸张的表现,压扁拉长,尽量夸大角色身体变形的程度,来达到动作上的张力与效果(喜感,惊讶感…….)对应到现在的三滴动画软件中,皆有提供形变(Deformation)的功能,从最基本的scale到不等比缩放,以及进阶控制的,如FFD BOX……等网格式形变功能,都能帮助我们轻易的达到压缩与伸展的效果。


二、Anticipation预备


    动画中人物所表现之情绪(emotion)与讯息(information)必须以观众,也就是人类共通的肢体语言来传递,让角色的动作带给观众清楚的�预期性�,这个角色作出了这个预备动作,观众就能推测他接下来的行动。反之,则难以说服观众将认知投射在角色上。


    不管是使用何种软件,什么功能…….在角色的动作设计上,这是相当�核心�的一点,端赖动画师长期的观察不同特性的人类情绪、动作表现来获得肢体语言的各种表现方式与经验的累积,方能为之。


三、Exaggeration夸张


    基本上,动画就是夸张的……动画中的人物的每一个感情与动作,必须以相对性的较高级来传达才会更有真实感(说服力)。如主角进入一个快乐情绪,便让它更为高兴,感觉悲伤时会更有悲伤的表现。


    夸张的表现方式五花八门,有在技术面上利用各种形变等功能,产生造型上的夸张,也有来自角色动作上的夸张……. 相较于真实拍摄的电影,以(计算机)动画来表现夸张的效果,是轻而易举的一件事。但夸张的意义并不完全是动作幅度大,而是经过深思熟虑后挑选的精采动作,将传递出角色动作的精髓。


四、Straight ahead and pose to pose(就是p2p)


    这是动画制作上相对的不同技巧,用来区分绘制动画时,需考虑之动作种类。连续动作在进行时,一次一个步骤,一张一张绘制,直到整个动作结束�而重点动作则是先将各主要动作画面完成后,再绘制连接主要画面的中间画格。


    对应于计算机动画制作上,几乎所有的计算机动画软件都是以Key frame的方式来设定人物角色的动作或是物体的行进路线(主要动作);而由电脑依所赋予的各项参数计算出中间的画格(连续动作)。主要画面的设置,与中间画面之间,存在着极微妙的关系。


五、Follow through and overlapping跟随动作与重叠动作


    可让角色的各个动作彼此影响,融混,重叠…….在移动中的物体或各个部分并不会永远一起移动,有些部分会先行移动,其它部分随后再到,然后再对先行移动的部分作重叠的夸张表情。


    这也是我们在动画中常见的表现方式,如跑步时身体先离开画面了,屁股还留在原地,再�嗖�一声弹出去的趣味效果。


    比起传统手绘制作的动画,在计算机动画中所有的动作都会转化为各种数值,物体的行进路线也会构成控制的曲线(PATH),我们能很精准的调校各个部分动作发生的时间与幅度,经由这种设定来达到�跟随�与�重叠�的效果。这种夸张的趣味,可以说是动画之所以吸引人的一个重点吧。


六、Slow in and Slow out淡入淡出


    将动作的起始与结束放慢;加快中段动作的速度,放慢动作的起始与结束。我们知道举凡肢体、对象等的移动,并不是以等速度运动,而多半呈一个�物线加(减)速度进行。


    对于一个从静止状态开始移动的动作而言,需要以先慢后快的设定来完成。在动作结束之前,速度也要逐渐减缓,乍停一个动作会带来突兀的感觉。而每一个主要动作之间必须完整的填进足够的中间画面来使得每一个动作都会以平滑的感觉开始,而且以平滑的感觉结束,而不至于产生跳格或是动作生硬的情形(反之亦然)。


    由以上的原则可知,动作的速度变化,可以清楚的说明动作的种类、程度……带给观者不同的感受,我们在制作计算机动画时,所有的动作都会转化为各种数值,物体的行进路线也会构成控制的曲线(PATH),每一个Key frame在动线上会形成一个事件刻度(Control Point),这个刻度与动线所形成的切线种类,会影响到事件开始执行与结束的速度,经由这种设定来达到"平滑开始与结束"的效果。


七、Arcs圆弧动作


    动画中的动作,除了机械类的对象之外,几乎都是以圆滑的动线在进行移动。所以在描绘中间画面的时,要注意连接主要画面的动作是以圆滑的曲线在进行动作设定,而不是以锐利的曲线形成动作,以免形成不自然的感觉。


    让角色的动作沿着圆弧动线来进行,不要走完全的直线。反之,如果是机械性的动作,就会是僵硬的、笔直行进的,藉由动线上的差异,传达出不同角色的特性。


    在计算机动画制作上,我们可以直接在Key frame上调整,或透过诸如Track View的动线轨迹上形成的事件刻度(Control Point),这个刻度与动线所形成的切线种类,也可以控制物体运动的方式,经由这种设定来达到"圆弧动作"的要求。


八、Secondary Action二次运动


    以较小的运动来为定义动作的主要运动作辅助。在角色进行主要动作时,如果加上一个相关的第二动作,会使主角的主要动作便得更为真实以及具有说服力。但这个第二动作需要是以配合性的动作出现,不能过于独立或剧烈以至于影响主要动作的清晰度。


    例如以跳跃的脚步来表达快乐的感觉,同时也可以加入手部摆动的动作来加强效果……第二动作可能相当的细微,但却有画龙点睛之效,在制作计算机动画时。我们可以将主要动作设置好,透过反复预视,再加入辅助的动作,但什么是恰当的Secondary Action?则必须透过经验的累积、对动作的观察,转化为属于动画师的肢体语言的风格!


九、Timing and Weight时间控制(也就是节奏)与重量感


    运动是动画中最基本和最重要的部分,而运动最重要的是节奏与时间。


    时间控制是动作真实性的灵魂,过长或过短的动作会折损动画的真实性。除了动作的种类影响到时间的长短外,角色的个性刻画也会需要�时间控制�来配合表演。


    量感是赋予角色生命力与说服力的关键,如何表现出物体应有的质感属性?动作的节奏会影响量感,如果物体的动作(速度)和我们预期上的视觉经验有出入时,将会产生不协调的感觉。


    在计算机动画的制作上,修改动作发生的时间是相当容易的一件事,透过各种的控制方式能对Key Frame作相当精准的调整,而预视(Preview)的功能更是比传统方式能够更快的观察出动画在时间上所发生的问题,而能径行修改。


十、Staging表演


    角色在场景中所要叙述的故事情节,都需要以清楚的表演来完成,场景或高潮的气氛与强度,带进画面中角色的位置与行动里去。一个情绪可能需要十多个小动作来表达。每一个小动作都必须清楚的表达,简单完整、干净俐落是这个原理的要求标准,太过复杂的动作在同一时间内发生,会让观众失去观赏的焦点。


    很幸运的,计算机动画可以一再的重复运作,预视并在最大的范围内作修正,创作者可以尝试不同的动作方式、画面构成(并付出最少的成本),当然,我们还是要强调,好的动画来自好的设计,每一个动作、镜头的位置都必须是精心设计而有其意义的。


    自第一部动画片问世以来,动画都是通过片中主要角色和次要角色的动作来营造幽默气氛和阐述剧情的。动画就是动的艺术,而角色动作则是表现重点,角色动作的实现手段更是随着科技的发展而有了很大的不同:最早的动画片,诸如max Flesher兄弟的《逃出墨水井》,用的是最为直观方便的办法来实现的,将胶片上的人物角色的动作一张一张的描摹下来。经过一段时间的发展,动画成了一门独立且包罗万象的视觉媒体艺术,制作程序也渐渐的流程化,科学的工作分配使角色的动作实现起来变地烦琐。按照迪斯尼的经验和要求,首先,要对真实的表现对象进行长时间的临摹,对角色的形象、结构,乃至习性和习惯动作都要有一个系统的观察临摹,再进行艺术夸张,把一张对角色形象性格逆造有帮助的要素夸张出来,有的是极度夸张,使最后在画面中的角色有血有肉,有性格有弱点,有他们自己的生活。这时的角色动作创作要经过上述的艺术夸张之后,再进行提炼,画出关键的特点动作,再在这些关键张之间按照角色的性格不同所需要的不同节奏画出数量不等的中间张,这就是一直沿用至今流传世界的关键张的办法。


    实际上,现在的动画大多数在制作过程中都包含了各种各样的技术的段,比如一些迪斯尼的三维动画片,在制作的不同阶段用不同的软件,甚至一部影片下来,要用十种以上的软件,这样做的目的是为了呈现完美的最终效果,发挥不同软件的不同优势。现在的动画技术也一样开始有趋同的趋势,很多运用在三维中的技术现在渐渐的应用到了二维的高端软件中,以用来实现二维中完美的空间效果,方便的用计算机运算出中间张。还有的干脆就用三维动画来实现二维效果,就像《埃及王子》中摩西用神杖将红海一分二为的宏大场面,就是用的三维模型贴上二维的海面贴图,将三维细腻的运动和二维华丽的贴图完美结合到一起。


    《花木兰》中,匈奴的千军万马冲下雪山的这场戏,则应用了更为复杂的技术,不仅将匈奴做成三维模型,还通过计算机运算,使匈奴的形象随机生成,避免产生过于类似的感觉。而且,现在很多二维动画影片中开始流行用三维模型通过特殊的上角程序变成可以自由的从不同角度进行观察的二维形象,解决了二维动画中角色的转面动作不易处理的难题。


    所以,随着技术的演进,传统的动画规律必然面临着新的转化,但动作设计的基本规律还是合理内核,这就是上述的迪斯尼的经典动画规.

 

Wednesday, June 11, 2008

C++ VS. C#

 

There are a number of areas to contrast and compare advantages of C++ and C#.

There are also questions of managed C++ (C+/CLI) compared to unmanaged ("classic") C; for now we're comparing unmanaged C+ to C#, which uses a managed memory model.

Code Writing

Memory

C#'s strengths:

·         Automatic memory initialization and management. While coding little attention is needed for who owns what memory, meaning that coding is faster in general. The whole problem of freeing memory when handling an exception does not exist.

·         Memory freeing happens automatically in C# through garbage collection. Overloading pointers to perform reference counting can help ameliorate memory freeing problems in C++, but these schemes are often involved to get exactly right.

C++'s strengths:

·         You are in control of memory, though this feature can be a double-edged sword. You can exactly tell how much memory is needed in advance, and precisely control how that memory is laid out, if need be. There will never be any delays due to garbage collection.

Both languages can have the problem of holding onto memory after it should have been freed. In C++ this is common, as a destructor might not explicitly free memory it should have. However, C# can also hold onto memory; for example, an event might need to be unregistered for memory it references to be let go.

Syntax

C#'s strengths:

·         Single file: there is no .cpp/.h code vs. header file separation. This makes writing code simpler, and encourages a good programming style: it is so simple to add a method to a class that it is worth just doing so. In C++ adding a new method involves editing two files, adding a similar but not quite the same method descriptor to each, and compiling to check your work.

·         Extremely fast compilation. Large systems take minutes to compile, not an hour, leading to less programmer down time. For example, Autodesk Design Review, in C++, can take a solid hour to build it. Inventor can take hours to build. C# is fast enough that the whole build can be performed automatically whenever a checkin is done, quickly showing any build problems.

·         One set of common libraries. C# has a large number of classes supporting common operations, handling data and exceptions in a consistent way. C++ has STL, which is not as comprehensive or universal.

C++'s strengths:

·         Every programmer (pretty much) is familiar with the language and has used it for years. That said, short books such as O'Reilly C# Essentials book can ease the transition; even just reading a "differences article" like this one can get programmers most of the way there. C# is about 85% like C++, with a few new constructs and a few kinks ironed out.

·         You are "closer to the metal" with C++, in that you can intuit a bit better what operations are quick and what are not.

·         Integration of assembly code into inner loops of C++ code can make it faster. C# uses CLR, so assembly is unavailable.

Language Strengths

C#'s strengths:

·         Confusing and difficult to debug templates and #defines do not exist. Some design patterns are implemented by C#, such as C#'s delegates.

·         Reflection allows code to parse other data structures without much intervention from the user. This can allow, for example, simple dialogs to be automatically constructed and interpreted that allow someone debugging the code to quickly change parameter values.

·         #include files and the headaches of getting these to compile are almost non-existent in C#; it's "use" mechanism is geared for large projects.

·         There are many other little improvements of C# over C++: property set/get is a part of the language, there is direct support for events, enums can represent bits in a bit string and accessed correctly, "int" has a platform independent meaning, for example (important for 64-bit platforms), and so on. A good summary can be found here

C++'s strengths:

·         C#'s class reference system can sometimes be confusing to debug. Class references have no "pointer handle" to look at in the debugger, making it difficult to know what data is being examined. C++'s use of pointers means data can be precisely identified. (Note that you can achieve the same result while debugging C# by using the "Make Object ID" feature in the debugger, it's just a little more obscure to use - Steve Anderson.)

·         A number of C++ constructs can be used to perform the same functionality as C# (underneath the hood everything is machine code, so this statement is obviously true). In some cases C++ can be a bit more straightforward, see David Brownell's blog. That said, most programmers still use the default "new/delete" functionality, dumb pointers, etc. Informed C++ practice guidelines set by expert programmers can help avoid these problems.

Maintenance

C#'s strengths:

·         Automatic memory initialization and bounds checking. Some of the most difficult defects to track down (if they are noticed at all before the product is released) are those that occur sporadically, often only on release compiles of C++ code. These defects are almost always due to one of two problems: initialization or reading/writing out-of-bounds memory locations. C# avoids or identifies these problems early on: code will not compile if use of an uninitialized variable is detected, and execution will halt if an array overflow occurs.

C++'s strengths:

·         Over time a number of tools have been developed that can help the C++ developer, such as tools for finding uninitialized

Performance

As mentioned, C++ can be faster that C# for a number of operations.

There is a startup cost with getting C#'s CLR into machine code when the program is first executed. There is also a memory overhead for the CLR system itself, though this is a fixed cost so is not as important for larger applications. C++ does not have these costs.

An interesting fact is that C++ code is normally compiled for the least common denominator platform, e.g. a Pentium II processor, rather than for the commonly used CPU. C# uses CLR, which at least in theory can be compiled and optimized on the fly for the platform it is on. I do not know if this optimization is done in practice.

This is an interesting series of posts, starting here http://www.codinghorror.com/blog/archives/000299.html. The author notes: "This managed code is a line for line conversion in the dumbest possible way of his initial program with no attempt whatsoever to optimize anything." Yet it was more than 10x faster than the original C++ code. One iteration of optimization made the C# program considerably faster, though eventually the C++ program, after 6 iterations of optimization, is finally a bit faster than the C# code. In the process, the C++ coder had to write his own string class, file I/O code, memory allocator, international code support, etc. More around here: http://blogs.msdn.com/ricom/archive/2005/05/10/performance-quiz-6-chinese-english-dictionary-reader.aspx (find the rest here: http://blogs.msdn.com/ricom/archive/2005/05.aspx\), on the MSDN site.

Another relevant article is at http://www.xtremedotnettalk.com/showthread.php?t=83128 – tidbit that Tom Miller, lead dev. for managed !DirectX, says Managed !DirectX is 3-5% slower than unmanaged !DirectX. Tom writes about how the initial version of managed !DirectX had some problems, now fixed: http://msdn.microsoft.com/msdnmag/issues/05/08/EndBracket/. Managed !DirectX is not a toy, shipping products include those by http://www.koiosworks.com/.

One fairly comprehensive article with an older version of .NET (which is constantly improving):
http://www.ddj.com/184401976 - June 2005, in-depth comparison of common operations. C# is similar to C++ in performance, except for matrix multiplication (see http://www.ddj.com/dept/cpp/184401976?pgno=5 - why? Note this is not 4x4 matrix multiply, so doesn’t really carry over to us directly). The two summary graphs:

http://www.ddj.com/showArticle.jhtml?documentID=cuj0507bruckschlegel&pgno=10 – without math

http://www.ddj.com/showArticle.jhtml?documentID=cuj0507bruckschlegel&pgno=11 – with math, more like what we do.

Bottom line for “with math”: C++, 761.5; C# 2.0 beta 2, 890.25 – C# is 16% slower overall (and surprisingly faster in some cases, e.g. lists, object creation & destruction).

Information from Ian Ameline (Maya):

I've done some performance comparisons, and when it comes to single precision floating point math (very common in 3D graphics and image/signal processing) C# and .net are substantially slower than C++. The Perlin noise generator used in Maya is very performance critical – for many renders, over 60% of the time is spent in this code.

Intel C++

V9.1.035

552 cycles/result

perf mult = 1.00

MS C++

V14.00.50727.762

1078 cycles/result

perf mult = 1.95

MS C++.net

V2.00.50727.42

1866 cycles/result

perf mult = 3.38 (or 1.73 compared to native MS)

MS C#.net

 

1195 cycles/result

perf mult = 2.16 (or 1.11 compared to native MS)

These were measured on a 3Ghz P4 Prescott with an 800 Mhz fsb, Windows XP SP2, freshly booted, nothing else running. All tests were run 10 times, and the best time for each test was used. (Variance from run to run was less than 2%)

As a reference, on this platform, my hand coded SSE assembler version was 684 cycles/result – slower than the code generated by the Intel compiler (but slightly faster than the Intel V8 compiler.)

These numbers are consistent with what many are reporting – that .net is not that much slower than native code – the problem is that the native code they're comparing to is the garbage produced by the native MS C++ compiler.

Good native code is over 2x faster than .net on a number of problem domains of significant interest to us, and not many people are making that comparison.

This sort of code is typical for many of the performance critical paths of Maya.

(We compile all of our performance critical code with the Intel compiler. It does a substantially better job of generating fast code when compared to MS's compiler. I know what I'm talking about here; I spent 8 years working at IBM's research labs on the compiler teams as the architect for their x86 optimizing back end.)

So I went to look at why .net was so slow. The answer is that it does a very simple and naive translation to x87 floating point instructions. Virtually no optimizations to speak of.

The Intel compiler does a fairly smart job of using the SSE instructions for floating point, but does not vectorize this code – it's still scalar. When the Intel compiler does autovectorize, it gets another 2 to 3x performance out of your code. For our billow (clouds, etc.) texture generator, it's 3.5 times faster than MSVC 8, and about 6 times faster than C#.

The MS compiler is just too stupid to know that it doesn't need to promote all the single precision math to double precision. That's why it compares so badly to the Intel compiler.

Interfacing

It's clear that interfacing one C++ program with another C++ program is fairly straightforward, and a well-known quantity (though link errors can still be mysterious at times). C# to C++ and C++ to C# are less common ways of interfacing, and each has its issues and limitations.

Tools and Library Support

C#'s strengths:

·         Autocompletion of code just happens, by default, in Visual Studio. This same feature can be made to work for C+, but it's sometimes hit or miss. The ADR C+ developers complain about the incredible amount of time the latest Visual Studio takes to generate Intellisense databases for their C++ files, to the point that they will turn the feature off.

C++'s strengths:

·         Almost every outside library written will interface with C++, since the language is ubiquitous. A major problem for C# is the lack of commitment by Microsoft to fully support managed !DirectX 10, and managed wrappers for 64-bit machines.

Compile Time

C# code, or generally managed code, compiles in a small fraction of the time that it takes to compile comparable C++ code. While specific examples are not provided here, the difference is dramatic and leads to a substantial improvement in productivity, particularly for large projects. This speed is due in part to managed code being compiled to [http://en.wikipedia.org/wiki/Common_Intermediate_Language]an intermediate language], not machine code. Compiling is done at application run-time, through [http://en.wikipedia.org/wiki/Just-in-time_compilation]just-in-time compilation] (JIT).

Platforms

C# is tied to Microsoft and .NET, vs. C++ being platform agnostic. There are efforts to make C# work on Linux and Macs, e.g. the Mono Project, an open-source project supported by Novell.

 

Modeler: A faceted solid modeling system

A Modeler is a faceted solid modeling system. It should provides the following

functionality:

 

-  B-Rep data structure for the faceted representation of solid bodies.

 

-  Combination of bodies using the regularized Boolean operations -- union,

   intersection, and difference -- and sectioning bodies with a plane.

 

-  Perspective or parallel projection with hidden lines removed.

 

-  Box, cylinder, cone, sphere, torus, pipe, rectangleToCircleReducer,

   convex hull and other primitives.

 

-  Set of sweep operations including general extrusion along the path,

   allowing one profile to morph to another profile while being extruded.

   Importing and sweeping 2D polylines from a DXF files.

 

-  Geometric transformations translation, rotation, scaling, stretching, and

   mirroring; general alignment of bodies in space.

 

-  Calculation of area, volume, centroid, moments of inertia and products of

   inertia for bodies; calculation of area, perimeter, and centroid for faces.

 

-  Checking interference of bodies; testing location of a point with respect

   to a body.

 

-  Picking entities (vertices, edges, faces, and bodies) in projected views.

 

-  Storing bodies in a native format; storing projected or triangulated bodies

   in DXF files.

 

-  Modern object oriented software architecture.