Irrlicht 3D Engine 笔记系列 之 自己定义Animator

作者: i_dovelemon

日期: 2014 / 12 / 17

来源: CSDN

主题: Custom Animator, Referenced count

引言

在昨天的文章《Irrlicht 3D Engine 笔记系列 之 教程4 - Movement》中,博主向大家保证会在今天向大家实际操作怎样扩展Irrlicht引擎的Animator特性。假设读者对Irrlicht的Animator的特性不是非常了解的话,请先了解下前面的那篇文章,本片文章是在上次文章的基础上进行的。

Custom Animator

经过昨天我们的分析,发现仅仅要我们继承ISceneNodeAnimator这个接口来实现我们自己的Animator就能够了。所以以下,我们就按着这个思路来对创建我们自己定义的Animator。

首先,对我们将要创建的Animator进行下简单的描写叙述:

博主想要创建一个沿着某条直线进行循环运动,而且物体本身在旋转的Animator。博主称之为Roll Animator(翻滚动画)。

好了。在明白了我们想要创建的Animator的功能之后。我们就实际动手来创建一个。

首先,我们来申明一个CMyRollAnimator的类,这个类继承至ISceneNodeAnimator,而且复写当中的两个纯虚拟函数animateNode和createClone,申明头文件例如以下所看到的:

//-------------------------------------------------------------------------------------------------
// declaration	: Copyright (c), by XJ , 2014. All right reserved .
// brief		: This file will define the custom roll animator.
// author		: XJ
// date			: 2014 / 12 / 17
// version		: 1.0
//--------------------------------------------------------------------------------------------------
#pragma once

#include<irrlicht.h>
using namespace irr ;
using namespace scene ;
using namespace core;

class CMyRollAnimator: public ISceneNodeAnimator
{
public:
	CMyRollAnimator(vector3df _startPos, vector3df _endPos,
		f32 _speed);

	//animate a node
	virtual void animateNode(ISceneNode* node, u32 timeMs);

	//clone a animator
	virtual ISceneNodeAnimator* createClone(ISceneNode* node, ISceneManager* newManager=0);

private:
	vector3df m_vStartPos ;
	vector3df m_vEndPos ;
	vector3df m_vCurPos ;
	f32       m_fSpeed  ;
	u32       m_uCurTime;

	//internal usage
	vector3df m_vDir    ;
	vector3df m_vRDir	;
};

读者能够看到博主上面定义的类很的简单,仅仅是加入了几个成员属性而已。除此之外就是复写的方法和一个构造函数。

为了实现前面描写叙述的运动,我们来介绍下这里面成员的含义。首先,我们须要知道物体运动应该从哪里開始。到哪里结束,而且须要知道这个运动的速度以及当前运动的时间。另外两个成员属性用于内部计算使用。以下来看看这个类的明白实现是怎么样的:

#include"CMyRollAnimator.h"

//constructor
CMyRollAnimator::CMyRollAnimator(vector3df _startPos, vector3df _endPos,
		f32 _speed)
		:m_vStartPos(_startPos),
		m_vEndPos(_endPos),
		m_fSpeed(_speed),
		m_vCurPos(_startPos),
		m_uCurTime(0)
{
	m_vDir = m_vEndPos - m_vStartPos ;
	m_vDir.normalize();
	m_vRDir = m_vDir ;
	m_vRDir.rotateXZBy(90.0f);
}

//animate a node
void CMyRollAnimator::animateNode(ISceneNode* _pNode, u32 timeMs)
{
	if(0 == m_uCurTime)
	{
		m_uCurTime = timeMs ;
		_pNode->setPosition(m_vStartPos);
	}
	else
	{
		u32 _deltaTime = timeMs - m_uCurTime ;
		f32 _fDeltaTime = _deltaTime / 1000.0f ;
		m_uCurTime = timeMs ;
		m_vCurPos += _fDeltaTime * m_fSpeed * m_vDir ;

		if(abs(m_vCurPos.X - m_vEndPos.X) < 0.01f &&
			abs(m_vCurPos.Y - m_vEndPos.Y) < 0.01f &&
			abs(m_vCurPos.Z - m_vEndPos.Z) < 0.01f)
		{
			m_vCurPos = m_vStartPos ;
		}

		_pNode->setPosition(m_vCurPos);
		_pNode->setRotation(-m_vRDir * 180.0f * timeMs/1000.0f);
	}
}// end for animateNode

//clone an animator
ISceneNodeAnimator* CMyRollAnimator::createClone(ISceneNode* node, ISceneManager* newManager)
{
	CMyRollAnimator* _pAnimator = new CMyRollAnimator(m_vStartPos, m_vEndPos, m_fSpeed);
	return _pAnimator ;
}// end for createClone

事实上实现。也十分的简单。最重要的控制方案是在animateNode这个函数里面实现的。对于这个函数,我们须要知道一点,它的參数列表中的第二个參数的意义并非类似cocos2d-x里面的调用该函数的时间间隔。在Irrlicht内部维持了一个时间计数器,这个计数器从系统启动開始就開始计时。这里的timeMs就是系统此时的时间,以MS计算。

所以读者大概。就行明确博主为什么要在类内部定义的当前时间了。我们通过这个所谓的当前时间来与系统实际的当前时间进行比較,计算出时间间隔,从而控制节点进行移动。

想要实现自己的Animator是不是十分的简单啊???仅仅要掌握了这个主要的规则。我们就能够发挥我们自己的想象来制作出十分复杂的Animator出来。

大家能够借鉴下cocos2d-x里面的Action,试着在Irrlicht中也实现它们,而且将代码共享出来给大家使用。假设有空的话,博主可能会自己实现一些Animator共享给大家使用。

完整的代码和教程4中的代码一致。所不同的是将FlyCircleAnimator换成我们这里自定义的Animator而已,例如以下所看到的:

#include<irrlicht.h>
#include"MyEventReceiver.h"
#include"CMyRollAnimator.h"
using namespace irr;
using namespace core;
using namespace gui;
using namespace scene;
using namespace video;

#ifdef _IRR_WINDOWS_
#pragma comment(lib,"irrlicht.lib")
#pragma comment(linker,"/subsystem:windows /ENTRY:mainCRTStartup")
#endif

int main()
{
	//Create the irrdevice
	MyEventReceiver _receiver;
	IrrlichtDevice* _pDevice = createDevice(EDT_DIRECT3D9,dimension2d<u32>(800,640),32U,
		false,
		false,
		false,
		&_receiver);

	//Check if create successfully
	if(NULL == _pDevice)
		return 1 ;

	//Get the video driver and scene manager
	IVideoDriver* _pVideoDriver = _pDevice->getVideoDriver();
	ISceneManager* _pSceneManager = _pDevice->getSceneManager();

	//Create a sphere node
	ISceneNode* _pNode = _pSceneManager->addSphereSceneNode();

	//Check if create successfully
	if(NULL == _pNode)
		return 1 ;
	_pNode->setPosition(vector3df(0,0,30));
	_pNode->setMaterialTexture(0,_pVideoDriver->getTexture("wall.bmp"));
	_pNode->setMaterialFlag(EMF_LIGHTING,false);

	//Create a cube node
	ISceneNode* _pCubeNode = _pSceneManager->addCubeSceneNode();

	//Check if create successfully
	if(NULL == _pCubeNode)
		return 1 ;
	_pCubeNode->setMaterialTexture(0,_pVideoDriver->getTexture("t351sml.jpg"));
	_pCubeNode->setMaterialFlag(EMF_LIGHTING, false);

	//Create a scene node animator for cube node
	//ISceneNodeAnimator* _pAnimator = _pSceneManager->createFlyCircleAnimator(vector3df(0,0,30),
	//	20.0f);
	CMyRollAnimator * _pAnimator = new CMyRollAnimator(vector3df(-20,0,30), vector3df(20,0,30),
		10.0f);

	//Check if create successfully
	if(NULL == _pAnimator)
		return 1 ;

	_pCubeNode->addAnimator(_pAnimator);

	//Drop the animator
	_pAnimator->drop();

	//Add one camera node
	_pSceneManager->addCameraSceneNode();

	int _nlastFPS = -1 ;

	u32 _uLastTime = _pDevice->getTimer()->getTime();

	const f32 MOVEMENT_SPEED = 5.0f ;

	//Do loop
	while(_pDevice->run())
	{
		const u32 _now = _pDevice->getTimer()->getTime();
		const f32 _frameDeltaTime = (f32)(_now - _uLastTime)/1000.0f;
		_uLastTime = _now ;

		vector3df _pos = _pNode->getPosition();

		if(_receiver.IsKeyDown(KEY_KEY_W))
			_pos.Y += MOVEMENT_SPEED * _frameDeltaTime ;
		else if(_receiver.IsKeyDown(KEY_KEY_S))
			_pos.Y -= MOVEMENT_SPEED * _frameDeltaTime ;

		if(_receiver.IsKeyDown(KEY_KEY_A))
			_pos.X -= MOVEMENT_SPEED * _frameDeltaTime ;
		else if(_receiver.IsKeyDown(KEY_KEY_D))
			_pos.X += MOVEMENT_SPEED * _frameDeltaTime ;

		_pNode->setPosition(_pos);

		//Draw the scene
		_pVideoDriver->beginScene();
		_pSceneManager->drawAll();
		_pVideoDriver->endScene();
	}// end while

	_pDevice->drop();

	return 0 ;
}// end 

Referenced Counter

博主在编写这个实验程序的时候。发现当我们调用_pAnimator->drop的时候,animator并没有销毁。所以,博主对于引擎内部是怎样保存一个对象技术感到好奇。决心研究一下。

在Irrlicht引擎中,通过一个十分简单的引用技术(Referenced Counter)系统来对系统中的对象进行跟踪。

这个功能是通过一个名为IReferenceCounted接口来实现的,引擎中大部分的类都继承了这个接口。从而实现了引用技术操作。以下来看下。这个类的申明:

// Copyright (C) 2002-2012 Nikolaus Gebhardt
// This file is part of the "Irrlicht Engine".
// For conditions of distribution and use, see copyright notice in irrlicht.h

#ifndef __I_IREFERENCE_COUNTED_H_INCLUDED__
#define __I_IREFERENCE_COUNTED_H_INCLUDED__

#include "irrTypes.h"

namespace irr
{

	//! Base class of most objects of the Irrlicht Engine.
	/** This class provides reference counting through the methods grab() and drop().
	It also is able to store a debug string for every instance of an object.
	Most objects of the Irrlicht
	Engine are derived from IReferenceCounted, and so they are reference counted.

	When you create an object in the Irrlicht engine, calling a method
	which starts with 'create', an object is created, and you get a pointer
	to the new object. If you no longer need the object, you have
	to call drop(). This will destroy the object, if grab() was not called
	in another part of you program, because this part still needs the object.
	Note, that you only need to call drop() to the object, if you created it,
	and the method had a 'create' in it.

	A simple example:

	If you want to create a texture, you may want to call an imaginable method
	IDriver::createTexture. You call
	ITexture* texture = driver->createTexture(dimension2d<u32>(128, 128));
	If you no longer need the texture, call texture->drop().

	If you want to load a texture, you may want to call imaginable method
	IDriver::loadTexture. You do this like
	ITexture* texture = driver->loadTexture("example.jpg");
	You will not have to drop the pointer to the loaded texture, because
	the name of the method does not start with 'create'. The texture
	is stored somewhere by the driver.
	*/
	class IReferenceCounted
	{
	public:

		//! Constructor.
		IReferenceCounted()
			: DebugName(0), ReferenceCounter(1)
		{
		}

		//! Destructor.
		virtual ~IReferenceCounted()
		{
		}

		//! Grabs the object. Increments the reference counter by one.
		/** Someone who calls grab() to an object, should later also
		call drop() to it. If an object never gets as much drop() as
		grab() calls, it will never be destroyed. The
		IReferenceCounted class provides a basic reference counting
		mechanism with its methods grab() and drop(). Most objects of
		the Irrlicht Engine are derived from IReferenceCounted, and so
		they are reference counted.

		When you create an object in the Irrlicht engine, calling a
		method which starts with 'create', an object is created, and
		you get a pointer to the new object. If you no longer need the
		object, you have to call drop(). This will destroy the object,
		if grab() was not called in another part of you program,
		because this part still needs the object. Note, that you only
		need to call drop() to the object, if you created it, and the
		method had a 'create' in it.

		A simple example:

		If you want to create a texture, you may want to call an
		imaginable method IDriver::createTexture. You call
		ITexture* texture = driver->createTexture(dimension2d<u32>(128, 128));
		If you no longer need the texture, call texture->drop().
		If you want to load a texture, you may want to call imaginable
		method IDriver::loadTexture. You do this like
		ITexture* texture = driver->loadTexture("example.jpg");
		You will not have to drop the pointer to the loaded texture,
		because the name of the method does not start with 'create'.
		The texture is stored somewhere by the driver. */
		void grab() const { ++ReferenceCounter; }

		//! Drops the object. Decrements the reference counter by one.
		/** The IReferenceCounted class provides a basic reference
		counting mechanism with its methods grab() and drop(). Most
		objects of the Irrlicht Engine are derived from
		IReferenceCounted, and so they are reference counted.

		When you create an object in the Irrlicht engine, calling a
		method which starts with 'create', an object is created, and
		you get a pointer to the new object. If you no longer need the
		object, you have to call drop(). This will destroy the object,
		if grab() was not called in another part of you program,
		because this part still needs the object. Note, that you only
		need to call drop() to the object, if you created it, and the
		method had a 'create' in it.

		A simple example:

		If you want to create a texture, you may want to call an
		imaginable method IDriver::createTexture. You call
		ITexture* texture = driver->createTexture(dimension2d<u32>(128, 128));
		If you no longer need the texture, call texture->drop().
		If you want to load a texture, you may want to call imaginable
		method IDriver::loadTexture. You do this like
		ITexture* texture = driver->loadTexture("example.jpg");
		You will not have to drop the pointer to the loaded texture,
		because the name of the method does not start with 'create'.
		The texture is stored somewhere by the driver.
		\return True, if the object was deleted. */
		bool drop() const
		{
			// someone is doing bad reference counting.
			_IRR_DEBUG_BREAK_IF(ReferenceCounter <= 0)

			--ReferenceCounter;
			if (!ReferenceCounter)
			{
				delete this;
				return true;
			}

			return false;
		}

		//! Get the reference count.
		/** \return Current value of the reference counter. */
		s32 getReferenceCount() const
		{
			return ReferenceCounter;
		}

		//! Returns the debug name of the object.
		/** The Debugname may only be set and changed by the object
		itself. This method should only be used in Debug mode.
		\return Returns a string, previously set by setDebugName(); */
		const c8* getDebugName() const
		{
			return DebugName;
		}

	protected:

		//! Sets the debug name of the object.
		/** The Debugname may only be set and changed by the object
		itself. This method should only be used in Debug mode.
		\param newName: New debug name to set. */
		void setDebugName(const c8* newName)
		{
			DebugName = newName;
		}

	private:

		//! The debug name.
		const c8* DebugName;

		//! The reference counter. Mutable to do reference counting on const objects.
		mutable s32 ReferenceCounter;
	};

} // end namespace irr

#endif

这个接口十分的简洁,我们仅仅要通过grab()和drop()这两个函数来进行操作就行。操作的规则在上面已经说的很清楚了。

对于在引擎中使用create方法创造出来的对象,一般来说在create方面里面会调用new来构造一个对象。看这个接口的构造函数。我们发现,进行构造之后引用计数就是1了。

假设我们接着调用drop()函数。引用计数值就会变成0,从而自我进行销毁。也就是说,调用drop的次数要比调用grab的次数大1才可以使引用计数值变为0,从而销毁自身。

这就是导致在上面,博主调试实验程序的时候,发现调用_pAnimator->drop()的时候,并没有自我销毁的原因。

在我们将animator加入到node里面的时候,node中会保存一个这个对象的副本,从而调用一次grab()函数。

也就是。我们须要再次的调用一次drop函数,才可以销毁掉这个animator。可是,博主这里并没有这么做。

亲爱的读者们啊,也请你千万不要这么做。

我们上面的全部创造过程,都是在程序主循环之上进行构造的。也就是说,在程序的主循环中还须要使用我们创建的这个animator,从而才可以随着时间的进行,控制节点进行移动。

那么,就有一个问题了,这个对象究竟在什么地方进行终于的销毁了?

博主发现,在教程4的结尾处,当程序主循环结束之后,会调用一下_pDevice->drop()函数。是不是和这个对象的释放有关了?

我们跟踪这个类的析构方法。依次得到例如以下的代码:

CIrrDeviceStub::~CIrrDeviceStub()
{
	VideoModeList->drop();
	FileSystem->drop();

	if (GUIEnvironment)
		GUIEnvironment->drop();

	if (VideoDriver)
		VideoDriver->drop();

	if (SceneManager)
		SceneManager->drop();

	if (InputReceivingSceneManager)
		InputReceivingSceneManager->drop();

	if (CursorControl)
		CursorControl->drop();

	if (Operator)
		Operator->drop();

	if (Randomizer)
		Randomizer->drop();

	CursorControl = 0;

	if (Timer)
		Timer->drop();

	if (Logger->drop())
		os::Printer::Logger = 0;
}

CIrrDeviceStub是Irrlicht引擎中全部IrrlichtDevice设备的共同拥有的一个桩类。

用于实现那些全部设备都同样的部分。通过这个桩类在IrrlichtDevice这个接口与实际的CIrrDeviceWin32之间进行一个桥接。实现那些共同拥有的功能。在这个桩类析构函数中,发现会依次的调用各个子系统的drop函数,从而释放里面的资源。对于node来说,它保存在SceneManager里面,继续跟踪,发如今引擎中仅仅有一个SceneManager。为CSceneManager。查看这个类的析构函数。得到例如以下的函数:

//! destructor
CSceneManager::~CSceneManager()
{
	clearDeletionList();

	//! force to remove hardwareTextures from the driver
	//! because Scenes may hold internally data bounded to sceneNodes
	//! which may be destroyed twice
	if (Driver)
		Driver->removeAllHardwareBuffers();

	if (FileSystem)
		FileSystem->drop();

	if (CursorControl)
		CursorControl->drop();

	if (CollisionManager)
		CollisionManager->drop();

	if (GeometryCreator)
		GeometryCreator->drop();

	if (GUIEnvironment)
		GUIEnvironment->drop();

	u32 i;
	for (i=0; i<MeshLoaderList.size(); ++i)
		MeshLoaderList[i]->drop();

	for (i=0; i<SceneLoaderList.size(); ++i)
		SceneLoaderList[i]->drop();

	if (ActiveCamera)
		ActiveCamera->drop();
	ActiveCamera = 0;

	if (MeshCache)
		MeshCache->drop();

	for (i=0; i<SceneNodeFactoryList.size(); ++i)
		SceneNodeFactoryList[i]->drop();

	for (i=0; i<SceneNodeAnimatorFactoryList.size(); ++i)
		SceneNodeAnimatorFactoryList[i]->drop();

	if (LightManager)
		LightManager->drop();

	// remove all nodes and animators before dropping the driver
	// as render targets may be destroyed twice

	removeAll();
	removeAnimators();

	if (Driver)
		Driver->drop();
}

在这个析构函数中,能够发现有一个名为removeAnimators()的函数,我们继续跟踪,例如以下所看到的:

		//! Removes all animators from this scene node.
		/** The animators might also be deleted if no other grab exists
		for them. */
		virtual void removeAnimators()
		{
			ISceneNodeAnimatorList::Iterator it = Animators.begin();
			for (; it != Animators.end(); ++it)
				(*it)->drop();

			Animators.clear();
		}

哈哈,在这里,调用了一次drop(),从而实现了对Animator对象的销毁。

在这次的追踪发现了。当我们调用_pDevice->drop函数的时候。会依次的释放系统中全部的资源和对象。

可是这里,博主又有一个疑问?非常多对象仅仅有在这最后的步骤才会调用实际的析构函数进行销毁。那么也就是说,假设在系统的中途。我们已经决定了不再使用某个对象。而且保证在之后的过程中都不再使用了,假设仅仅是简单的调用一次drop是不是还是会让这个对象依旧残留在系统里面,从而导致内存被占用。不须要的资源长期持有着了?Irrlicht引擎是否有某种机制可以让我们主动的释放掉一些资源了?查看源码发现,的确有这种一些方法。大部分都是通过remove开头的来实现这种功能。可是请注意,千万不要主动的调用两次drop()函数。

尽管这种确可以将对象提前销毁,可是违背了使用引言计数的初衷。在Irrlicht内部会出现野指针的情况。

毕竟你还是须要和Irrlicht打交道的,这样做实在不好也不合理。

最适当的方法。就是通过remove方法来通知Irrlicht来释放掉你不想使用的资源。

如今给大家总结下,本篇文章的核心内容:

1.通过继承ISceneNodeAnimator来实现我们自己的Animator

2.Irrlicht引用计数系统十分的简单,却很的有用。请大家依照它定义的规则来使用它。否则会出现意想不到的结果。

在博主自己进行分析Irrlicht所使用的各种框架技术之后,博主有股冲动,想要自己的来实现下或者说仿制下这些技术。毕竟。研究引擎。一方面是为了熟悉它,使用它。另外一个更重要的原因是为了学习这些技术,并把它据为己有。

所以。在今后,博主可能会另外在开一个系列。专门用来仿制引擎中的各种特性。试着实现一些仿真程序。

最后给出。本次试验程序的程序截图。十分的简单,一个Cube来回的移动而已:

这次的文章就到此结束了,感谢大家的关注。!

时间: 2024-10-01 10:31:20

Irrlicht 3D Engine 笔记系列 之 自己定义Animator的相关文章

Irrlicht 3D Engine 笔记系列 之 自定义Animator

作者: i_dovelemon 日期: 2014 / 12 / 17 来源: CSDN 主题: Custom Animator, Referenced count 引言 在昨天的文章<Irrlicht 3D Engine 笔记系列 之 教程4 - Movement>中,博主向大家保证会在今天向大家实际操作如何扩展Irrlicht引擎的Animator特性.如果读者对Irrlicht的Animator的特性不是很了解的话,请先了解下前面的那篇文章,本片文章是在上次文章的基础上进行的. Custo

Irrlicht 3D Engine 笔记系列之 教程4 - Movement

作者: i_dovelemon 日期: 2014 / 12 / 16 来源: CSDN 主题: Event Receiver, Animator, Framerate independent movement and framerate dependent movement 引言 从今天開始,博主将进行对3D Engine的学习.而且,在博客中将自己学习的心得一一分享给大家.希望可以对大家有所帮助.也希望可以找到志同道合的同伴一起学习3D 游戏引擎方面的知识. 为什么选择Irrlicht? 在非

Irrlicht 3D Engine 笔记系列 之 教程6- 2D Graphics

作者:i_dovelemon 日期:2015 / 7 / 1 来源: CSDN 主题:2D Graphics, Irrlicht 教程翻译 本篇教程将要向大家展示如何使用Irrlicht引擎绘制2D图形.绘制2D图形能够让我们制作一个2D游戏或者绘制一些漂亮的用户界面和HUD出来. 和以前一样,包含一些头文件,使用irr命名空间,并且通知连接器链接lib文件: #include <irrlicht.h> #include "driverChoice.h" using nam

Irrlicht 3D Engine 笔记系列 之 教程5- User Interface

作者:i_dovelemon 日期:2014 / 12 / 18 来源:CSDN 主题:GUI 引言 今天,博主学习了第五个教程.这个教程讲解了如何使用Irrlicht内置的一个基础模块,GUI模块,来开发一些GUI程序.作为Irrlicht的重要基础模块,博主有必要对此进行一些代码跟踪和深入的了解.详细的教程过程请看官网. 设备选择 以前在使用Ogre的时候,它的程序运行之初都会问你需要使用的是哪一种API.那么在Irrlicht引擎中是否有同样的功能了?答案是肯定,在Irrlicht的dri

mongodb学习笔记系列一

一.简介和安装 ./bin/mongod --dbpath /path/to/database --logpath /path/to/log --fork --port 27017 mongodb非常的占磁盘空间, 刚启动后要占3-4G左右,--smallfiles 二.基本命令 1.登录mongodb client /use/local/mongo 2.查看当前数据库 show databases; show dbs; 两个可能 3.admin是和管理有关的库,local 是放schema有关

《Mastering Opencv ...读书笔记系列》车牌识别(I)

http://blog.csdn.net/jinshengtao/article/details/17883075/  <Mastering Opencv ...读书笔记系列>车牌识别(I) http://blog.csdn.net/jinshengtao/article/details/17954427   <Mastering Opencv ...读书笔记系列>车牌识别(II) Mastering Opencv ...读书笔记系列>车牌识别(I) 标签: 车牌分割svm西

《3D数学基础》系列视频 1.6向量的投影

理解数学,理解代码! 大家好,我是老G! 今天为大家带来<3D数学基础>系列视频. 主要讲解:游戏开发中用到的3D数学知识,包括:定义,定理,推论. 也包括他们的推导过程,以及应用举例. 本套视频完全免费,欢迎捐助,帮助我完成这套视频 支付宝帐号:[email protected] 今天带来的是系列第7讲,关于向量的内容 本次视频,主要讲解一下向量的投影: 定义 向量的投影公式 投影公式的矩阵形式 国内网盘: http://pan.baidu.com/s/1c0ldm5U 苹果iTunes U

《3D数学基础》系列视频 1.5 向量的夹角

理解数学,理解代码! 大家好,我是老G! 今天为大家带来<3D数学基础>系列视频. 主要讲解:游戏开发中用到的3D数学知识,包括:定义,定理,推论. 也包括他们的推导过程,以及应用举例. 本套视频完全免费,欢迎捐助,帮助我完成这套视频 支付宝帐号:[email protected] 今天带来的是系列第6讲,关于向量的内容 本次视频,主要讲解一下向量的夹角: 公式 快速判断两向量方向一致性 国内网盘: http://pan.baidu.com/s/1c0ldm5U 苹果iTunes U注册代码:

C++语言笔记系列之十六——赋值兼容规则&amp;多继承的二义性

1.赋值兼容规则 (1)派生类对象可以给基类对象赋值,这种情况下派生类对象将从基类继承的成员的值赋值给一个基类对象:但是不允许将一个基类的对象赋值给一个派生类. (2)可以将派生类对象的地址赋给基类指针,使基类指针指向派生类对象,通过基类指针引用成员时只可以引用派生类从基类继承而来的成员,而不允许引用派生类的新成员. (3)引用与指针相同. 2.多继承 (1)一个派生类从两个以上的基类中去继承. (2)说明: class 派生类名:继承方式 基类1, 继承方式 基类2,...... {派生类成员