There does exist a flavour of Wavefront's *.obj that facilitates Vertex Coloring..
I know of two applications that can export these namely "MeshLab" (free) and "MeshMixer"
(also free from Autodesk)..
The vertex colours is actually found just after each vertex definition as shown below..
(Piece of *.obj)
# OBJ File Generated by Meshlab
Blender can export PLY files (.ply), which are text-based, very easy to parse, and include vertices colors. The hard way is to change the OBJ exporter code so that it includes the vertices colors (thus breaking obj compatibility).
Wavefront OBJ supports materials, which color groups of meshes the same color.
Material statements look like this:
Kd 1.00 0.00 0.00
Ks 0.50 0.50 0.50
So, Kd is the diffuse component, Ks specular.
These would be specified inside a .mtl file that accompanies the .obj file. Inside the .obj file are statements like
This may be a winding issue. Are you sure that the texture coordinates are parsed in the right sense of rotation?
However, this how you should debug you program.
Draw in wire frame mode to find out how the rectangle is composed out of two triangles. The OpenGL command for this is glPolygonMode(GL_FRONT_AND_BACK, GL_LINE);.
Use a texture with a gradient ...
I'm assuming you opened the file in Notepad. Notepad doesn't recognize some new line formats.
The OBJ format does indeed use newlines as delimiters, and your files likely contain them. It's just not looking that way in Notepad. Try opening them in Notepad++ instead: I'll bet they'll appear correctly.
To make sure your parser function works correctly on all ...
There are several factors that contribute to how the geometry is saved and processed in different mediums (programs, file formats, APIs). I did implement several commercial geometry analysis programs, so I have some experience with it.
First I am sure this has nothing to do with Unity simplifying anything. But in case it did there are several decimation ...
You've mentioned "parse the data" a few times, which suggests to me that you're probably using .obj files; even if not, the fact that you have to parse data is sufficient.
The fastest work is the work that you don't have to do at all. Parsing data can be slow; parsing, interpreting, converting and validating plain text data from a .obj file is even slower.
You don't have 3 textures per face but 3 points on one texture. Connecting them with lines you'll get a triangle on your texture, and this is the exact part that will be used on your face when rendered.
You may look at this answer.
First of all can I say I've never encountered by total chance someone encountering such an incredibly specific issue that I also encountered, so good job on that, universe.
So as you've already discovered, Unity's model importers discard all edges and points.
I haven't completely solved this problem myself for a similar project, but I have a partial ...
You are using the wrong UV coordinates and yes, it's normal to have more UVs than positions.
Consider a cube. A cube has 8 positions but for correct normals it needs either 3 normals per position since each face of the cube needs a different normal. Similarly imagine you had a texture atlas with 6 different images, one for each face of the cube. You'd need ...
First, there's no error checking in the code.
The obj loading seems incorrect.
The vertices are copied into mesh.vertices (l. 212-214 in BlockRenderer). Using the DefaultCube, mesh.vertices contains 12*3 vertices, and the index buffer 36 ints.
Problem seems that the indices reference into the original verts array and not into mesh....
There were no normals, so nothing was displaying. I updated the git repo to warn on missing normals.
Unfortunately, I have no ground-breaking debugging techniques to report. I opened up the working .obj file and the "broken" .obj file, and by comparing them I noticed that one of the files had normals, and the other one didn't.
You just need to flip your texture!
Your texture width and height must to be like in this order:
(2X2), (8X8), (32X32), (64X64), (128X128), (256X256), (512X512), (1024X1024) and so on! (else your texture will fill with black areas!)
The solution is to use slick library for loading your textures!
(You must download the Slick library and add it to your java ...
1: Im not 100% sure, but those 3d-softwares i know WILL write all the vertices before the faces
2: No not everytime and you cant calculate them
Edit: Of course, if it has a texture it will have texture-coordinates (if your 3d-modeling-software doesnt suck :D )
3: You cant put an texture directly on the mesh, you can only put an material on the mesh which ...
800 MB / 3 minutes = 4.4 MB/sec—a far cry from peak disk bandwidth, which is in the hundreds of MB per second (exact value depends on what kind of disk interface you have). So you're definitely not saturating I/O bandwidth. You should be able to load 800MB into memory in a few seconds.
You mentioned converting from .obj to a binary representation, but it ...
Obj formats are strange in particular because the positions, normals and texture coordinates are separated and each face can choose whatever index from each stream. When you refer to vertex count you think that the vertex positions and normals count is not the same and you can't really refer to the whole count.
During loading all these three attributes ...
You need two vertexes in such this case. There is no way around it. If the faces have a different texture then you will need a different vertexes to define them. To simplify it you could try to save the mesh in such way - check whatever modelling program you use. Sometime it may be as simple as telling it not to weld vertexes together.
Basically, there is Vertex data, which is stored in one or more VBOs. Typical (3D) vertex has like: vec3 pos, vec2 uv, mat3 tbn (or vec3 normal) - maybe some other modifiers, possibly several different uv coords or something like that. Anyways, no matter if you store those to 1 or multiple VBOs, IBO will index all the buffers with same index.
So, each pos/...
There are better ways than what I show here, but if you're working on a small game (aka.: you're not working on an A++ game) then you'll be fine with this:
The part where you extract the vertex, texture and the normal information from the file is good and should work, but you need to rearrange them so the information for the same vertex should have the same ...
Sorry for this question. I solved my problem. But I'll leave this post with it's answer here. I forgot to add my uv texture cords correctly. To do this in blender I pressed 'u' and chose "Smart UV Project" in edit-mode. This worked but gave me interesting uv's. To mark your uv's on your own in the edit-mode you can select the vertices you need. Press ctrl + '...
I looked and I totally boned up the implementation of -fliptc. It was flipping in U instead of in V, and you could only do it if you were also reversing the face winding.
I've updated the master branch of GitHub with some fixes. -fliptc has been removed. Instead I added flipv which inverts just the v texcoord without reversing the winding, and -flipz which ...
The problem is that obj files contain vertex data in parts:pos,tex,normal and indices in them point to each of these parts individually.
In OpenGL you need to combine those parts into one data object - vertex.
And have your indices point to vertices, not their parts.
My code (scala, but should be ok)
val vertexListB = new RList[vec3]()//output positions
Your picture is of a cube, so I assume that's what you're talking about.
You can only share vertices between continuous surfaces. That is, on a sphere, you share all/most of the vertices. On a cube, you must you separate vertices for each face.
Aside from texturing, think of the normals you need for lighting. The normal for each side of a cube should point ...
Your TryToCreateNewMiner function can call it again. If your RandomPercent calculator keeps returning true, the callstack gets deeper and deeper.
The problem with the obj format is that it isn't standardised. So you'll see some that use clockwise winding (not good for a naive implementation in OpenGL) some that use counter-clockwise winding (not good for a naive implementation in DirectX) plus all other kinds of quirks that are vendor-dependent (eg. triangles vs quads as primitives).
The most usual ...
There is a good documentation on Wikipedia. The format is made by Wavefront, you'll find lot more information online with this name. This is the Wikipedia article.
Basically, v means vertex position, vt means texture coordinate and vn means vertex normal. f defines indices of a face.
It isn't that easy to draw *.obj models in a modern way, since their ...
What kind of shading do you use. I assume some kind of blinn-phong. If that's the case, your shading depends on the dot product of your normal and the half vector of reflected light: (http://en.wikipedia.org/wiki/Blinn%E2%80%93Phong_shading_model)
The dot-product will be below zero on your triangles if your prof is right and your normals are pointing in the ...
OBJ format is not meant to reflect how you store things in memory and operate on data. The fact that you're using an OBJ format is hence not relevant. You need to be loading your data into an appropriate in-memory format that makes the operations you need efficient.
In the most general case you store a list of Triangle objects and iterate over each to do ...