Ładowanie modeli
-w tym zadaniu przećwiczymy ładowanie modeli z plików, wykorzystamy do tego bibliotekę assimp (The Open Asset Import Library ), która zapewnia wspólny interfejs dla różnych typów plików.
-Funkcja loadModelToContext pobiera ścieżkę do pliku z modelem i wczytuje go przy użyciu importera assimp.
const aiScene* scene = import.ReadFile(path, aiProcess_TriangulateaiProcess_Triangulate | aiProcess_CalcTangentSpace);Importer przyjmuje ścieżkę i flagi preprocesingu, które mówią jakie operacje ma wykonać importer przed przekazaniem nam pliku. W naszym przypadku dokonuje triangularyzacji (zamienia wszystkie wielokąty na trójkąty) i oblicza przestrzeń styczną (o której będzie mowa później).
---Wywołaj funkcję dla ścieżki do statku ./models/spaceship.obj i zmiennej globalnej
-Core::RenderContext sphereContext. Dodaj breakpoint po załadowaniu sceny i obejrzyj jak wygląda struktura załadowanego obiektu
Załadowany obiekt posiada szereg pól jak na przykład tekstury, oświetlenia, materiały, węzły (Node) czy modele. Węzły odpowiadają za hierarchię elementów w modelu, co ułatwia jego animację, wykorzystamy to w późniejszych zajęciach, w trakcie tych zajęć będziemy się skupiać na modelach. Nasze obiekty składają się z tylko jednego modelu, wywołaj context.initFromAiMesh z nim jako argumentem.
Zadanie
-Jeśli tego nie zrobiłeś wywołaj metodę context.initFromAiMesh z argumentemscene->mMeshes[0] po wczytaniu sceny. Metoda nie jest kompletna, uzupełnij ją o ładowanie indeksów, wierzchołków, normalnych i współrzędnych tekstur do bufora. Współrzędne tekstur i indeksy zostały przekonwertowane do odpowiedniego formatu i znajdują się w zmiennych std::vector<float> textureCoord i std::vector<unsigned int> indices odpowiednio. Pozostałe są dostępne jako atrybuty aiMesh, mianowicie mesh->mVertices zawiera wierzchołki a mesh->mNormals normalne
Dodatkowo
-unsigned int vertexDataBufferSize = sizeof(float) * mesh->mNumVertices * 3;
-unsigned int vertexNormalBufferSize = sizeof(float) * mesh->mNumVertices * 3;
-unsigned int vertexTexBufferSize = sizeof(float) * mesh->mNumVertices * 2;zawierają rozmiary buforów.
-Wykorzystaj w renderScene funkcję Core::DrawContext(Core::RenderContext& context)
-
|
-
-
-
-The OpenGL Extension Wrangler Library- - - - -Automatic Code Generation- --Starting from release 1.1.0, the source code and parts of the -documentation are automatically generated from the extension -specifications in a two-step process. In the first step, -specification files from the OpenGL registry are downloaded and -parsed. Skeleton descriptors are created for each extension. These -descriptors contain all necessary information for creating the source -code and documentation in a simple and compact format, including the -name of the extension, url link to the specification, tokens, function -declarations, typedefs and struct definitions. In the second step, -the header files as well as the library and glewinfo source are -generated from the descriptor files. The code generation scripts are -located in the auto subdirectory. - - --The code generation scripts require GNU make, wget, and perl. On -Windows, the simplest way to get access to these tools is to install -Cygwin, but make sure that the -root directory is mounted in binary mode. The makefile in the -auto directory provides the following build targets: - - -
Adding a New Extension- --To add a new extension, create a descriptor file for the extension in -auto/core and rerun the code generation scripts by typing -make clean; make in the auto directory. - - --The format of the descriptor file is given below. Items in -brackets are optional. - - -
-<Extension Name> -Take a look at one of the files in auto/core for an -example. Note that typedefs and function signatures should not be -terminated with a semicolon. - - -Custom Code Generation--Starting from GLEW 1.3.0, it is possible to control which extensions -to include in the libarary by specifying a list in -auto/custom.txt. This is useful when you do not need all the -extensions and would like to reduce the size of the source files. -Type make clean; make custom in the auto directory -to rerun the scripts with the custom list of extensions. - - --For example, the following is the list of extensions needed to get GLEW and the -utilities to compile. - - -
-WGL_ARB_extensions_string Separate Namespace- --To avoid name clashes when linking with libraries that include the -same symbols, extension entry points are declared in a separate -namespace (release 1.1.0 and up). This is achieved by aliasing OpenGL -function names to their GLEW equivalents. For instance, -glFancyFunction is simply an alias to -glewFancyFunction. The separate namespace does not effect -token and function pointer definitions. - - -Known Issues- --GLEW requires GLX 1.2 for compatibility with GLUT. - - - - |
-
|
-
-
-
-The OpenGL Extension Wrangler Library- - - - -Initializing GLEW--First you need to create a valid OpenGL rendering context and call -glewInit() to initialize the extension entry points. If -glewInit() returns GLEW_OK, the initialization -succeeded and you can use the available extensions as well as core -OpenGL functionality. For example: - - -
-#include <GL/glew.h> Checking for Extensions- --Starting from GLEW 1.1.0, you can find out if a particular extension -is available on your platform by querying globally defined variables -of the form GLEW_{extension_name}: - - -
-if (GLEW_ARB_vertex_program) -In GLEW 1.0.x, a global structure was used for this task. To ensure -binary compatibility between releases, the struct was replaced with a -set of variables. - - --You can also check for core OpenGL functionality. For example, to -see if OpenGL 1.3 is supported, do the following: - - -
-if (GLEW_VERSION_1_3) -In general, you can check if GLEW_{extension_name} or -GLEW_VERSION_{version} is true or false. - - --It is also possible to perform extension checks from string -input. Starting from the 1.3.0 release, use glewIsSupported -to check if the required core or extension functionality is -available: - - -
-if (glewIsSupported("GL_VERSION_1_4 GL_ARB_point_sprite")) -For extensions only, glewGetExtension provides a slower alternative -(GLEW 1.0.x-1.2.x). Note that in the 1.3.0 release -glewGetExtension was replaced with -glewIsSupported. - - -
-if (glewGetExtension("GL_ARB_fragment_program")) Experimental Drivers- --GLEW obtains information on the supported extensions from the graphics -driver. Experimental or pre-release drivers, however, might not -report every available extension through the standard mechanism, in -which case GLEW will report it unsupported. To circumvent this -situation, the glewExperimental global switch can be turned -on by setting it to GL_TRUE before calling -glewInit(), which ensures that all extensions with valid -entry points will be exposed. - - -Platform Specific Extensions- --Platform specific extensions are separated into two header files: -wglew.h and glxew.h, which define the available -WGL and GLX extensions. To determine if a certain -extension is supported, query WGLEW_{extension name} or -GLXEW_{extension_name}. For example: - - -
-#include <GL/wglew.h> -Alternatively, use wglewIsSupported or -glxewIsSupported to check for extensions from a string: - - -
-if (wglewIsSupported("WGL_ARB_pbuffer")) Utilities- --GLEW provides two command-line utilities: one for creating a list of -available extensions and visuals; and another for verifying extension -entry points. - - -visualinfo: extensions and visuals- --visualinfo is an extended version of glxinfo. The -Windows version creates a file called visualinfo.txt, which -contains a list of available OpenGL, WGL, and GLU extensions as well -as a table of visuals aka. pixel formats. Pbuffer and MRT capable -visuals are also included. For additional usage information, type -visualinfo -h. - - -glewinfo: extension verification utility- --glewinfo allows you to verify the entry points for the -extensions supported on your platform. The Windows version -reports the results to a text file called glewinfo.txt. The -Unix version prints the results to stdout. - - -Windows usage: -- -glewinfo [-pf <id>] where <id> is the pixel format id for which the -capabilities are displayed. - -Unix usage: -- -glewinfo [-display <dpy>] [-visual <id>] where <dpy> is the X11 display and <id> is -the visual id for which the capabilities are displayed. - - - |
-
|
-
-
-
-The OpenGL Extension Wrangler Library- - - - -Building GLEW- -Windows- -A MS Visual Studio project is provided in the build/vc6 directory. -Pre-built shared and static libraries are also available for download. - -Makefile- -For platforms other than MS Windows, the provided Makefile is used. - -Command-line variables- -
Make targets- -
Requirements- -
sudo apt-get install libXmu-dev libXi-dev libgl-dev dos2unix git wget-Fedora: sudo yum install libXmu-devel libXi-devel libGL-devel dos2unix git wget- - |
-
|
-
-
-
-The OpenGL Extension Wrangler Library- - - - --Author, copyright and licensing information on github. - - |
-
|
-
-
-
-The OpenGL Extension Wrangler Library- - - - -Supported GLX Extensions- -
|
-
|
-
-
-
-The OpenGL Extension Wrangler Library- - - - --The OpenGL Extension Wrangler Library (GLEW) is a cross-platform -open-source C/C++ extension loading library. GLEW provides efficient -run-time mechanisms for determining which OpenGL extensions are -supported on the target platform. OpenGL core and extension -functionality is exposed in a single header file. GLEW has been -tested on a variety of operating systems, including Windows, Linux, -Mac OS X, FreeBSD, Irix, and Solaris. - - -Downloads-
-GLEW is distributed
-as source and precompiled binaries. - --
-An up-to-date copy is also available using git: - -
Supported Extensions--The latest release contains support for OpenGL 4.5, compatibility and forward-compatible contexts and the following extensions: - - - -News-
Links- - - - |
-
|
-
-
-
-The OpenGL Extension Wrangler Library- - - - -Installation- --To use the shared library version of GLEW, you need to copy the -headers and libraries into their destination directories. On Windows -this typically boils down to copying: - - -
- - --where {VC Root} is the Visual C++ root directory, typically -C:/Program Files/Microsoft Visual Studio/VC98 for Visual -Studio 6.0 or C:/Program Files/Microsoft Visual -Studio .NET 2003/Vc7/PlatformSDK for Visual Studio .NET. - - --On Unix, typing make install will attempt to install GLEW -into /usr/include/GL and /usr/lib. You can -customize the installation target via the GLEW_DEST -environment variable if you do not have write access to these -directories. - - -Building Your Project with GLEW--There are two ways to build your project with GLEW. - -Including the source files / project file--The simpler but less flexible way is to include glew.h and -glew.c into your project. On Windows, you also need to -define the GLEW_STATIC preprocessor token when building a -static library or executable, and the GLEW_BUILD preprocessor -token when building a dll. You also need to replace -<GL/gl.h> and <GL/glu.h> with -<glew.h> in your code and set the appropriate include -flag (-I) to tell the compiler where to look for it. For -example: - -
-#include <glew.h> -Depending on where you put glew.h you may also need to change -the include directives in glew.c. Note that if you are using -GLEW together with GLUT, you have to include glew.h first. -In addition, glew.h includes glu.h, so you do not -need to include it separately. - --On Windows, you also have the option of adding the supplied project -file glew_static.dsp to your workspace (solution) and compile -it together with your other projects. In this case you also need to -change the GLEW_BUILD preprocessor constant to -GLEW_STATIC when building a static library or executable, -otherwise you get build errors. - --Note that GLEW does not use the C -runtime library, so it does not matter which version (single-threaded, -multi-threaded or multi-threaded DLL) it is linked with (without -debugging information). It is, however, always a good idea to compile all -your projects including GLEW with the same C runtime settings. - - -Using GLEW as a shared library- --Alternatively, you can use the provided project files / makefile to -build a separate shared library you can link your projects with later. -In this case the best practice is to install glew.h, -glew32.lib, and glew32.dll / libGLEW.so to -where the OpenGL equivalents gl.h, opengl32.lib, and -opengl32.dll / libGL.so are located. Note that you -need administrative privileges to do this. If you do not have -administrator access and your system administrator will not do it for -you, you can install GLEW into your own lib and include subdirectories -and tell the compiler where to find it. Then you can just replace -<GL/gl.h> with <GL/glew.h> in your -program: - - -
-#include <GL/glew.h> -or: - - -
-#include <GL/glew.h> -Remember to link your project with glew32.lib, -glu32.lib, and opengl32.lib on Windows and -libGLEW.so, libGLU.so, and libGL.so on -Unix (-lGLEW -lGLU -lGL). - - --It is important to keep in mind that glew.h includes neither -windows.h nor gl.h. Also, GLEW will warn you by -issuing a preprocessor error in case you have included gl.h, -glext.h, or glATI.h before glew.h. - - - - |
-
|
-
-
-
-The OpenGL Extension Wrangler Library- - - - -Change Log- --
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- - - |
-
|
-
-
-
-The OpenGL Extension Wrangler Library- - - - -Supported WGL Extensions- -
|