'분류 전체보기'에 해당되는 글 17건

  1. 왜 gl3.h가 필요한가. 2013.01.11
  2. glFrustum때문에 벌어진 삽질 2013.01.11
  3. Lambda Expressions in C++ 2012.12.23
  4. unity 렌더링 여부 체크 2012.12.04
  5. D언어에서의 함수 포인터 2011.06.25

http://www.opengl.org/discussion_boards/showthread.php/175645-Why-is-gl3-h-necessary


09-19-2011, 01:36 AM

Junior MemberNewbie
Join Date
Sep 2011
Posts
11

Why is gl3.h necessary?

Probably a silly question for an experienced OpenGL developer, but this is a beginners forum (and I am a beginner - more or less), so I guess it's the right place to ask.

I mean, this is the first library that I used where the header carries a version number, and I find that very bizarre. So, if someone could explain why that was done (or point me to some documentation that explains it), I would appreciate that.

Also, in regards to 3.x and higher: Do I have to create a 3.x context in order to use 3.x features, or does GLEW allow me to use them? My current understanding is that this is what GLEW is for ... although, I have to use it even for just basic shaders, and that's supposed to be in 2.x domain, from what I understand (it's like everything in 2.x is being treated like an extension on my system - I would like to know if this is generally how things work, or if it's something specific to my system that maybe needs fixing).


Senior MemberOpenGL Guru
Join Date
May 2009
Posts
4,413

Re: Why is gl3.h necessary?

I mean, this is the first library that I used where the header carries a version number, and I find that very bizarre.
That's because most libraries are not backwards compatible. Or if they are, then they are backwards compatible by not removing old APIs.

Various functions and enumerators were removed from OpenGL at version 3.1. The purpose of gl3.h is to provide a header that includes only the functions and enumerators relevant to 3.1 and above.

Do I have to create a 3.x context in order to use 3.x features, or does GLEW allow me to use them?
It depends on what you mean by that. If you're using GLEW, then you should not care about gl3.h; just use GLEW's headers and you'll be fine.

OpenGL since version 3.2 has been divided into two specifications: core and compatibility. As the name suggests, compatibility means that all of the removed functions are restored. Core means that they're gone.

On most platforms, you must specifically ask for an OpenGL core context, via wgl/glXCreateContextAttribs. If you do not, then you will get a compatibility context. MacOSX has a different way of dealing with it, primarily centered around the fact that they don't provide a compatibility implementation. You either get 2.1 or 3.2 core.

it's like everything in 2.x is being treated like an extension on my system
The OpenGL Wiki's Getting Started page explains this.

Junior MemberNewbie
Join Date
Sep 2011
Posts
11

Re: Why is gl3.h necessary?

Quote Originally Posted by Alfonse Reinheart
That's because most libraries are not backwards compatible. Or if they are, then they are backwards compatible by not removing old APIs.

Various functions and enumerators were removed from OpenGL at version 3.1. The purpose of gl3.h is to provide a header that includes only the functions and enumerators relevant to 3.1 and above.
So, it's not so much about new functions, as it is about breaking the old ones?

It depends on what you mean by that. If you're using GLEW, then you should not care about gl3.h; just use GLEW's headers and you'll be fine.
Yea, well, that's really what I'm asking: If GLEW makes gl3.h irrelevant (in terms of available features - where I can still access the latest GPU capabilities without gl3.h), then what's the point of having gl3.h in the first place?

Is it just to break the old stuff? Why can't GLEW be configured to do that (since it seems to be the arbiter of what's actually made available to the application)?

The OpenGL Wiki's Getting Started page explains this.
That means that all OpenGL functions have to be "loaded in" like that, extension or not - this is how I interpreted those 3 passages.

So, even with a 3.x context, I would still need GLEW.

PS: 

Hey, I've been reading your tutorial - thanks for making that: You can remove deprecated features from the API, but old documentation tends to linger like a bad smell.

Your modern tutorial is a breath of fresh air.

@V-man

Thanks for the info.















GL 공부를 다시 하던 중, x축이 화면 왼쪽을 가리키고 있는 기묘한 현상을 발견했다. 와인딩, 좌표 모두 문제 없었고 y,z는 오른손좌표계 그대로인데, x만 뒤집혀 있었던 것이다.


원인은 glFrustum함수의 left, right가 바뀌어있었던 것 때문이었다.


프러스텀이 +z에서 -z를 바라보고 있어야 했는데 left가 0.5, right가 -0.5인 상태였다. 정상으로 바꾸자 문제는 해결되었다.


프러스텀 설정에 문제가 있는걸 찾기까지 몇시간을 허비했다.

Lambda Expressions in C++

from 번역 2012.12.23 07:54
일러두기
  1. 원문 : http://msdn.microsoft.com/ko-kr/library/dd293608.aspx (12년 12월 23일 기준)
  2. 본문은 샘플 코드를 포함하지 않으며 샘플 코드는 원본을 참고. 문서의 권리는 MSDN 사용 약관 참고.
  3. 번역상 혼동이 올 수 있는 중요한 단어는 한글 단어 뒤에 영단어를 그대로 표기함.



Visual C++에서 lambda 표현식-이하 람다-이란, 상태를 유지하고, 자신을 감싸는enclosing 스코프의 변수에 접근할 수 있는 익명의 함수같은 것이다. 이 문서는 람다가 무엇인지 정의하고, 이것을 다른 프로그래밍 기법들과 비교하여, 그 장점을 서술하고 기본적인 예제를 제공한다.



람다에 대하여

많은 프로그래밍 언어들은 익명 함수의 개념을 제공하는데, 이는 몸체body가 있되 이름이 없는 함수이다. 람다는 익명 함수와 관련된 프로그래밍 기법이다. 하나의 람다는 암묵적으로 함수 객체function object를 정의하고 그 타입의 인스턴스를 만든다. 함수 객체에 대해 더 많은 정보를 얻고 싶다면, 함수 객체 항목을 보라.


[중요]

람다는 다음과 같은 공용 언어 런타임의 관리되는 entity를 지원하지 않는다 : ref class , ref struct, value class, value struct



함수 객체 vs 람다

우리가 코드를 작성할 때, 아마 함수 포인터와 함수 객체를 문제 해결에 사용하는데 특히 STL을 사용해 계산할 때 그렇다. 함수 포인터와 함수 객체는 장단점이 있는데 예를 들면, 함수 포인터는 구문상의 오버헤드는 최소화하지만 스코프 안의 상태를 유지할 수 없고, 함수 객체는 상태를 유지할 수 있지만 클래스 하나 분량의 구문상의 오버헤드를 요구한다.


람다는 함수 포인터와 함수 객체의 장점을 조합하고 그들의 단점을 회피한다. 함수 객체와 같이, 람다는 유연하고 상태를 유지할 수 있다. 그러나 함수 객체와 달리 람다의 컴팩트한 문법은 클래스 정의를 필요로 하지 않는다. 람다를 사용함으로서, 우리는 함수 객체와 동등하지만 덜 거추장스럽고 덜 오류를 발생시키는 코드를 작성할 수 있다.



예제 1 : 람다 사용하기

본 예제는 vector안의 요소가 홀수인지 짝수인지를 콘솔에 출력하기 위해, for_each 함수 호출 안에서 람다를 사용한다.


[코드:원문참고]


코멘트

예제 안에서, for_each의 3번째 인자는 람다이다. [&evenCount] 부분은 표현식의 캡처 항목을 명시하며, (int n)은 매개변수 목록을 명시하고, 나머지는 표현식의 몸체이다.



예제 2 : 함수 객체 사용하기. 

때때로 람다는 이전 예제 이상으로 확장하기에 불편할 수도 있다. 다음 예제는 for_each문과 함께 람다 대신 함수 객체를 사용해 예제 1과 같은 결과를 보여준다. 두 예제는 vector 안의 짝수의 갯수를 저장한다.  동작의 상태를 유지하기 위해서 FunctorClass 클래스는 m_evenCount 변수에 참조를 멤버변수로서 저장한다. 동작을 수행하기 위해 FunctorClass는 함수 호출 연산자인 operator()를 구현한다. Visual C++컴파일러는 예제 1의 람다 코드와 유사한 사이즈와 퍼포먼스의 코드를 생성한다. 본문의 것과 같은 기본적인 문제를 위해서는, 보다 단순한 람다 설계가 함수 객체 설계보다 낫다. 그러나 당신이 생각하기에 그 기능이 미래에 중요한 확장을 요구할 수도 있다면 함수 객체 설계가 코드 유지보수를 편하게 할 것이다.


operator()에 대해 더 많은 정보가 필요하면 함수 호출(C++)을 보라. for_each에 대해 더 많은 정보가 필요하면 for_each를 보라.


[코드:원문참고]


요약

람다는 강력하고 인상적인 프로그래밍 기법이다. 람다의 세부사항과 특성들에 대해 학습하려면 람다 표현식 구문을 보라. 람다를 당신의 프로그램에 어떻게 쓸 지 배우려면 람다 표현식 예제를 보라.

Tag // C++, lambda

어떤 카메라든 각 카메라의 절두체 안에 들어와 다음 프레임에 화면에 표시 될 경우,

OnBacameVisible이 호출된다.

반대로 어떤 카메라로부터도 보이지 않을 경우 OnBacameInvisible이 호출된다.

각자는 Renderer컴포넌트가 GameObject에 붙어있을 때에만 호출된다.

Tag // unity3D
D1에서는 아래와 같은 C스타일 함수포인터 선언이 가능했다.
typedef int (*functionName) (int a, int b);


D2부터는 C스타일의 함수 포인터 선언이 불가능해지고 D스타일 함수 포인터만을 사용해야 한다. (D2에서 typedef가 폐기된 영향으로 추측된다) 선언 형식은 다음과 같다.

alias [반환형] function ([매개변수 목록]) [이름];

대리자 포인터의 경우 function 대신 delegate를 사용하면 된다. 선언한 함수 포인터 변수에는 일반적인 함수의 주소, 또는 함수 리터럴을 대입할 수 있다. 함수 포인터 변수에 대리자 리터럴을 담을 수는 없다.

 
alias int function(string b) func;

int foo(string b)
{
	writeln(b);
	
	return 0;
}

void main()
{
	func f;
	
	f = &foo;
	
	f("hello D!");
	
	f = function(string b)
	{
		writeln(b);
		return 1;
	};
	
	f("hello D!");
}