0

My game is going to use a lot of Low poly Meshes with hard edges. That means many times, one vertex position is going to use more than one normal and UV Coordinate. Therefore it would make good sense for me to split Vertex Positions, Normals and UVs into 3 separate arrays and then use 3 indices per vertex to construct the mesh. Are there any data formats for meshes which support skeletal Animations, Lights, textures, materials and all that junk together with separately indexing positions, normals and UVs? Or is it rather a question of the way I save the data in the 3D editor (Blender)?

Cœur
  • 37,241
  • 25
  • 195
  • 267
stimulate
  • 1,199
  • 1
  • 11
  • 30

1 Answers1

2

Sadly, there is no efficient way of using different indices for position, normals, UV etc. Every combination would have to be a separate vertex.

This thread discusses the matter, but it's generally much more efficient to use individual vertices.

If you decide to export from a 3D-editor to a .obj format, each vertex will be provided in the file, along with it's data.

This video shows a full example of loading an .obj file, all the way from Blender to OpenGL.

Community
  • 1
  • 1
SporreKing
  • 483
  • 3
  • 14
  • I also noticed that .obj files use this way of storing vertices. there are all positions, normals and uvs and the faces are constructed of 3*3 integers. Unfortunately obj does not have all the functionality i need.. I have now decided to just stick with .dae for now and then i will just load the 3 seperate arrays myself and index them when loading the mesh. This way i will not have to send as much data to my shaders and i can move more of the calculations to the graphics card, which seems like a good thing, since my program will not excercise the graphics card in the first place. Thanks! – stimulate Dec 12 '16 at 14:13
  • @stimulate No problem, don't forget to mark as answer :) – SporreKing Dec 12 '16 at 14:20
  • hehe greedy old geezer you ;) – stimulate Dec 12 '16 at 14:24
  • @stimulate It's my fuel ;) – SporreKing Dec 12 '16 at 14:25
  • @SporreKing: "*Sadly, there is no efficient way of using different indices for position, normals, UV etc.*" [That is untrue.](http://stackoverflow.com/a/11148568/734069) – Nicol Bolas Dec 12 '16 at 15:00
  • @NicolBolas "be advised that this will likely decrease rendering performance", I said efficiently – SporreKing Dec 12 '16 at 16:40
  • @Nicol Bolas why is this slower than having data for every single vertex combination? Especially with edgy meshes, the GPU has to deal with **alot** less data, so sending vertex data to the pipeline and accessing it there should be faster shouldn´t it? Why isn´t this being supported? – stimulate Dec 12 '16 at 17:29
  • @stimulate If I've understood it correctly, it's because reading data is faster than performing logic. Pairing things together takes more time than simple reading. I might be wrong on that reason though. – SporreKing Dec 12 '16 at 17:35
  • @stimulate: It's slower because dedicated hardware fetching can do things that a software solution cannot. It can read multiple indices and fetch data for all of them, even before the VS gets executed. So if there are cache misses on that memory read, pipeline latency can help reduce that. VS reads can't really be pipelined. But the efficiency difference is primarily for hardware that actually has dedicated vertex pulling hardware. – Nicol Bolas Dec 12 '16 at 18:42
  • Ok thanks for the Information! Let's hope this is a feature that will be better supported in the future, because to me this seems like it's generally a good idea. – stimulate Dec 12 '16 at 21:58