Search Results

Search found 4320 results on 173 pages for 'vertex arrays'.

Page 1/173 | 1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >

  • how can I specify interleaved vertex attributes and vertex indices

    - by freefallr
    I'm writing a generic ShaderProgram class that compiles a set of Shader objects, passes args to the shader (like vertex position, vertex normal, tex coords etc), then links the shader components into a shader program, for use with glDrawArrays. My vertex data already exists in a VertexBufferObject that uses the following data structure to create a vertex buffer: class CustomVertex { public: float m_Position[3]; // x, y, z // offset 0, size = 3*sizeof(float) float m_TexCoords[2]; // u, v // offset 3*sizeof(float), size = 2*sizeof(float) float m_Normal[3]; // nx, ny, nz; float colour[4]; // r, g, b, a float padding[20]; // padded for performance }; I've already written a working VertexBufferObject class that creates a vertex buffer object from an array of CustomVertex objects. This array is said to be interleaved. It renders successfully with the following code: void VertexBufferObject::Draw() { if( ! m_bInitialized ) return; glBindBuffer( GL_ARRAY_BUFFER, m_nVboId ); glBindBuffer( GL_ELEMENT_ARRAY_BUFFER, m_nVboIdIndex ); glEnableClientState( GL_VERTEX_ARRAY ); glEnableClientState( GL_TEXTURE_COORD_ARRAY ); glEnableClientState( GL_NORMAL_ARRAY ); glEnableClientState( GL_COLOR_ARRAY ); glVertexPointer( 3, GL_FLOAT, sizeof(CustomVertex), ((char*)NULL + 0) ); glTexCoordPointer(3, GL_FLOAT, sizeof(CustomVertex), ((char*)NULL + 12)); glNormalPointer(GL_FLOAT, sizeof(CustomVertex), ((char*)NULL + 20)); glColorPointer(3, GL_FLOAT, sizeof(CustomVertex), ((char*)NULL + 32)); glDrawElements( GL_TRIANGLES, m_nNumIndices, GL_UNSIGNED_INT, ((char*)NULL + 0) ); glDisableClientState( GL_VERTEX_ARRAY ); glDisableClientState( GL_TEXTURE_COORD_ARRAY ); glDisableClientState( GL_NORMAL_ARRAY ); glDisableClientState( GL_COLOR_ARRAY ); glBindBuffer( GL_ARRAY_BUFFER, 0 ); glBindBuffer( GL_ELEMENT_ARRAY_BUFFER, 0 ); } Back to the Vertex Array Object though. My code for creating the Vertex Array object is as follows. This is performed before the ShaderProgram runtime linking stage, and no glErrors are reported after its steps. // Specify the shader arg locations (e.g. their order in the shader code) for( int n = 0; n < vShaderArgs.size(); n ++) glBindAttribLocation( m_nProgramId, n, vShaderArgs[n].sFieldName.c_str() ); // Create and bind to a vertex array object, which stores the relationship between // the buffer and the input attributes glGenVertexArrays( 1, &m_nVaoHandle ); glBindVertexArray( m_nVaoHandle ); // Enable the vertex attribute array (we're using interleaved array, since its faster) glBindBuffer( GL_ARRAY_BUFFER, vShaderArgs[0].nVboId ); glBindBuffer( GL_ELEMENT_ARRAY_BUFFER, vShaderArgs[0].nVboIndexId ); // vertex data for( int n = 0; n < vShaderArgs.size(); n ++ ) { glEnableVertexAttribArray(n); glVertexAttribPointer( n, vShaderArgs[n].nFieldSize, GL_FLOAT, GL_FALSE, vShaderArgs[n].nStride, (GLubyte *) NULL + vShaderArgs[n].nFieldOffset ); AppLog::Ref().OutputGlErrors(); } This doesn't render correctly at all. I get a pattern of white specks onscreen, in the shape of the terrain rectangle, but there are no regular lines etc. Here's the code I use for rendering: void ShaderProgram::Draw() { using namespace AntiMatter; if( ! m_nShaderProgramId || ! m_nVaoHandle ) { AppLog::Ref().LogMsg("ShaderProgram::Draw() Couldn't draw object, as initialization of ShaderProgram is incomplete"); return; } glUseProgram( m_nShaderProgramId ); glBindVertexArray( m_nVaoHandle ); glDrawArrays( GL_TRIANGLES, 0, m_nNumTris ); glBindVertexArray(0); glUseProgram(0); } Can anyone see errors or omissions in either the VAO creation code or rendering code? thanks!

    Read the article

  • GLSL vertex shaders with movements vs vertex off the screen

    - by user827992
    If i have a vertex shader that manage some movements and variations about the position of some vertex in my OpenGL context, OpenGL is smart enough to just run this shader on only the vertex visible on the screen? This part of the OpenGL programmable pipeline is not clear to me because all the sources are not really really clear about this, they talk about fragments and pixels and I get that, but what about vertex shaders? If you need a reference i'm reading from this right now and this online book has a couple of examples about this.

    Read the article

  • How to create per-vertex normals when reusing vertex data?

    - by Chris Smith
    I am displaying a cube using a vertex buffer object (gl.ELEMENT_ARRAY_BUFFER). This allows me to specify vertex indicies, rather than having duplicate vertexes. In the case of displaying a simple cube, this means I only need to have eight vertices total. Opposed to needing three vertices per triangle, times two triangles per face, times six faces. Sound correct so far? My question is, how do I now deal with vertex attribute data such as color, texture coordinates, and normals when reusing vertices using the vertex buffer object? If I am reusing the same vertex data in my indexed vertex buffer, how can I differentiate when vertex X is used as part of the cube's front face versus the cube's left face? In both cases I would like the surface normal and texture coordinates to be different. I understand I could average the surface normal, however I would like to render a cube. Also, this still doesn't work for texture coordinates. Is there a way to save memory using a vertex buffer object while being able to provide different vertex attribute data based on context? (Per-triangle would be idea.) Or should I just duplicate each vertex for each context in which it gets rendered. (So there is a one-to-one mapping between vertex, normal, color, etc.) Note: I'm using OpenGL ES.

    Read the article

  • Minimum vs Minimal vertex covers

    - by panicked
    I am studying for an exam and one of the sample questions is as follows: Vertex cover: a vertex cover in a graph is a set of vertices such that each edge has at least one of its two end points in this set. Minimum vertex cover: a MINIMUM vertex cover in a graph is a vertex cover that has the smallest number of vertices among all possible vertex covers. Minimal vertex cover a MINIMAL vertex cover in a graph is a vertex cover that does not contain another vertex cover (deleting any vertex from the set would create a set of vertices that is not a vertex cover) Question: A minimal vertex cover isn't always a minimum vertex cover. Demonstrate this with a simple example. Can anyone get their head around this? I am failing to see the distinction between the two. More importantly, I'm having a hard time visualizing it. I seriously hope he's not gonna ask odd questions like this one on the exam!

    Read the article

  • effect and model vertex declaration compatibility

    - by Vodácek
    I have normal model drawing code. When I try to draw model without UV coordinates I got this exception: System.InvalidOperationException: The current vertex declaration does not include all the elements required by the current vertex shader. TextureCoordinate0 is missing. at Microsoft.Xna.Framework.Graphics.GraphicsDevice.VerifyCanDraw( Boolean bUserPrimitives, Boolean bIndexedPrimitives) at Microsoft.Xna.Framework.Graphics.GraphicsDevice.DrawIndexedPrimitives( PrimitiveType primitiveType, Int32 baseVertex, Int32 minVertexIndex, Int32 numVertices, Int32 startIndex, Int32 primitiveCount) at Microsoft.Xna.Framework.Graphics.ModelMeshPart.Draw() at Microsoft.Xna.Framework.Graphics.ModelMesh.Draw() ... I know what cause the exception, but is possible to avoid it? Is possible to check model before drawing it with current shader for vertex declaration compatibility?

    Read the article

  • Vertex 2 SSD is running faster than my Vertex 3 SSD?

    - by Kairan
    I used Acronis Disk Director to do a direct clone of my C:\ windows 7 x64 drive from my Vertex 2 to my new Vertex 3 SSD (Just to show the drive software winstall everything is identical.) I ran a performance test on Windows using the Windows Experience Index. The rating I am receiving when booting on the Vertex 2 is 7.5 While I am getting only a rating for the Vertex 3 of 6.9 My understanding is that the read/write speeds of the Vertex 2 is only up to 250MB/sec while the Vertex 3 is up to 500MB/sec. Copying a single file (3GB in size) from the Vertex 3 to itself was getting speed of approx 70-80MB/sec This speed is no better (maybe worse) than what I got from the Vertex 2 I am connected via the SATA 3 port on the motherboard, using an SATA 3 cable Is this issue caused by the drive cloning? Do I have a bad SSD?

    Read the article

  • Memory allocation strategy for the vertex buffers (DirectX 10/11)

    - by Alex
    I have the following question. I write CAD system. So I have a 3D scene and there are many different objects (walls, doors, windows and so on). User can add or delete some objects. The question is: how can I organise the keeping of vertices for all my objects. I can create vertex buffer for every object. But I think drawing/switching from one buffer to another would have performance penalty. Another way - I can create several big buffers for every object type. But I don't understand how to update such buffers. It is too big to update whole buffer (for example buffer for all walls). What I need to do if I want to delete the object from the middle of the buffer? Actually I have the similar question: http://stackoverflow.com/questions/5515700/how-to-properly-update-vertex-buffers-in-directx-10 Most examples I've found work with very static models. Therefore, they tend to create a single vertex buffer with their list of points, and then are just manipulated by matrix transformations. I, on the other hand, will be updating the scene very often.

    Read the article

  • What is the practical use of IBOs / degenerate vertex in OpenGL?

    - by 0xFAIL
    Vertices in 3D models CAN get cut in the process of optimizing 3D geometry, (degenerate vertices) by 3D graphics software (Blender, ...) when exporting because they aren't needed when reusing a vertex for multiple triangles. (In the current case 3D data is exported from Blender as .ply and read by a simple application that displays the 3D model) Every vertex has a few attributes like position, color, normal, tangent,... But the data for each vertex that is cut through the vertex sharing is lost and is missing in the vertex shader. Modern shader techniques like Bump or Normal mapping require normals/tangents per vertex which are also cut. To use complex shader techniques IBOs must not be used? Or is there a way to use IBOs and retain the data per vertex that was origionally lost?

    Read the article

  • Vertex Normals, Loading Mesh Data

    - by Ramon Johannessen
    My test FBX mesh is a cube. From what I surmise, it seems that the cube is on the extreme end of this issue, but I believe that the same issue would be able to occur in any mesh: Each vertex has 3 normals, each pointing a different direction. Of course loading in any type of mesh, potentially ones having thousands of vertices, I need to use indices and not duplicate shared verts. Currently, I'm just writing the normals to the vertex at the index that the FBX data tells me they go to, which has the effect of overwriting any previous normal data. But for lighting calculations I need more info, something that's equivalent to a normal per face, but I have no idea how this should be done. Do I average the 3 different verts' normals together or what?

    Read the article

  • Using raw vertex information for sprites rather than SpriteBatch in XNA

    - by The Communist Duck
    I have been wondering whether using SpriteBatch is the best option. Obviously for prototyping or small games it works well. However, I've been wanting to apply techniques such as shaders and lighting to my game. I know you can use shaders to some extent with SpriteSortMode.Immediate, but I'm not sure if you lose power using that. The other major thing is that you cannot store your vertex data in the graphics memory with buffers. In summary, is there an advantage of using VertexTextureNormal (or whatever they're called) structs for vertex data for 2D sprites, or should I stick with SpriteBatch, provided I wish to use shaders?

    Read the article

  • Mapping a Vertex Buffer in DirectX11

    - by judeclarke
    I have a VertexBuffer that I am remapping on a per frame base for a bunch of quads that are constantly updated, sharing the same material\index buffer but have different width/heights. However, currently right now there is a really bad flicker on this geometry. Although it is flickering, the flicker looks correct. I know it is the vertex buffer mapping because if I recreate the entire VB then it will render fine. However, as an optimization I figured I would just remap it. Does anyone know what the problem is? The length (width, size) of the vertex buffer is always the same. One might think it is double buffering, however, it would not be double buffering because it only happens when I map/unmap the buffer, so that leads me to believe that I am setting some parameters wrong on the creation or mapping. I am using DirectX11, my initialization and remap code are: Initialization code D3D11_BUFFER_DESC bd; ZeroMemory( &bd, sizeof(bd) ); bd.Usage = D3D11_USAGE_DYNAMIC; bd.ByteWidth = vertCount * vertexTypeWidth; bd.BindFlags = D3D11_BIND_VERTEX_BUFFER; //bd.CPUAccessFlags = 0; bd.CPUAccessFlags = D3D11_CPU_ACCESS_WRITE; D3D11_SUBRESOURCE_DATA InitData; ZeroMemory( &InitData, sizeof(InitData) ); InitData.pSysMem = vertices; mVertexType = vertexType; HRESULT hResult = device->CreateBuffer( &bd, &InitData, &m_pVertexBuffer ); // This will be S_OK if(hResult != S_OK) return false; Remap code D3D11_MAPPED_SUBRESOURCE resource; HRESULT hResult = deviceContext->Map(m_pVertexBuffer, 0, D3D11_MAP_WRITE_DISCARD, 0, &resource); // This will be S_OK if(hResult != S_OK) return false; resource.pData = vertices; deviceContext->Unmap(m_pVertexBuffer, 0);

    Read the article

  • Beginner question about vertex arrays in OpenGL

    - by MrDatabase
    Is there a special order in which vertices are entered into a vertex array? Currently I'm drawing single textures like this: glBindTexture(GL_TEXTURE_2D, texName); glVertexPointer(2, GL_FLOAT, 0, vertices); glTexCoordPointer(2, GL_FLOAT, 0, coordinates); glDrawArrays(GL_TRIANGLE_STRIP, 0, 4); where vertices has four "xy pairs". This is working fine. As a test I doubled the sizes of the vertices and coordinates arrays and changed the last line above to: glDrawArrays(GL_TRIANGLE_STRIP, 0, 8); since vertices now contains eight "xy pairs". I do see two textures (the second is intentionally offset from the first). However the textures are now distorted. I've tried passing GL_TRIANGLES to glDrawArrays instead of GL_TRIANGLE_STRIP but this doesn't work either. I'm so new to OpenGL that I thought it's best to just ask here :-) Cheers!

    Read the article

  • Find inner arrays in nested arrays

    - by 50ndr33
    I have a nested array in PHP: array ( '0' => "+5x", '1' => array ( '0' => "+", '1' => "(", '2' => "+3", '3' => array ( '0' => "+", '1' => "(", '2' => array ( // I want to find this one. '0' => "+", '1' => "(", '2' => "+5", '3' => "-3", '4' => ")" ), '3' => "-3", '4' => ")" ), '4' => ")" ) ); I need to process the innermost arrays here, the one with the comment: "I want to find this one." Is there a function for that? I have thought about doing (written as an idea, not as correct PHP): foreach ($array as $id => $value) { if ($value is array) { $name = $id; foreach ($array[$id] as $id_2 => $value_2) { if ($value_2 is array) { $name .= "." . $id_2; foreach ($array[$id][$id_2] as $id_3 => $value_3) { if ($value_3 is array) { $name .= "." . $id_3; foreach ($array[$id][$id_2][$id_3] as $id_4 => $value_4) { if ($value_4 is array) { $name .= "." . $id_4; foreach [and so it goes on]; } else { $listOfInnerArrays[] = $name; break; } } } else { $listOfInnerArrays[] = $name; break; } } } else { $listOfInnerArrays[] = $name; break; } } } } So what it does is it makes $name the current key in the array. If the value is an array, it goes into it with foreach and adds "." and the id of the array. So we would in the example array end up with: array ( '0' => "1.3.2", ) Then I can process those values to access the innner arrays. The problem is that the array that I'm trying to find the inner arrays of is dynamic and made of a user input. (It splits an input string where it finds + or -, and puts it in a separate nested array if it contains brackets. So if the user types a lot of brackets, there will be a lot of nested arrays.) Therefore I need to make this pattern go for 20 times down, and still it will only catch 20 nested arrays no matter what. Is there a function for that, again? Or is there a way to make it do this without my long code? Maybe make a loop make the necessary number of the foreach pattern and run it through eval()? Long answer to J. Bruni: <?php $liste = array ( '0' => "+5x", '1' => array ( '0' => "+", '1' => "(", '2' => "+3", '3' => array ( '0' => "+", '1' => "(", '2' => array ( '0' => "+", '1' => "(", '2' => "+5", '3' => "-3", '4' => ")" ), '3' => "-3", '4' => ")" ), '4' => ")" ) ); function find_deepest( $item, $key ) { echo "0"; if ( !is_array( $item ) ) return false; foreach( $item as $sub_item ) { if ( is_array( $sub_item ) ) return false; } echo "1"; print_r( $item ); return true; } array_walk_recursive( $liste, 'find_deepest' ); echo "<pre>"; print_r($liste); ?> I wrote echo 0 and 1 to see what the script did, and here is the output: 00000000000000 Array ( [0] => +5x [1] => Array ( [0] => + [1] => ( [2] => +3 [3] => Array ( [0] => + [1] => ( [2] => Array ( [0] => + [1] => ( [2] => +5 [3] => -3 [4] => ) ) [3] => -3 [4] => ) ) [4] => ) ) )

    Read the article

  • AndEngine Physics Editor loading level

    - by Khawar Raza
    I have created a .pes file using PhysicsEditor and imported as xml and have added to my project. When I parsed it and created bodies, it is showing strange behavior. The mapping of bodies that I created in PhysicsEditor is totally different what I see in my application means the shapes I draw in PhysicsEditor are rendering differently in my app. Here is my xml and code to parse and add bodies to scene. PhysicsEditor XML file: <?xml version="1.0" encoding="UTF-8"?> <!-- created with http://www.physicseditor.de --> <bodydef version="1.0"> <bodies numBodies="1"> <body name="car_path" dynamic="false" numFixtures="1"> <fixture density="2" friction="1" restitution="0" filter_categoryBits="1" filter_groupIndex="0" filter_maskBits="65535" isSensor="false" type="POLYGON" numPolygons="20" > <polygon numVertexes="6"> <vertex x="277.0000" y="152.0000" /> <vertex x="356.0000" y="172.0000" /> <vertex x="413.0000" y="194.0000" /> <vertex x="476.0000" y="223.0000" /> <vertex x="173.0000" y="232.0000" /> <vertex x="174.0000" y="148.0000" /> </polygon> <polygon numVertexes="4"> <vertex x="1556.0000" y="221.0000" /> <vertex x="1142.0000" y="94.0000" /> <vertex x="1255.0000" y="-15.0000" /> <vertex x="1554.0000" y="-14.0000" /> </polygon> <polygon numVertexes="3"> <vertex x="-192.0000" y="177.0000" /> <vertex x="-888.0000" y="139.0000" /> <vertex x="-549.0000" y="-125.0000" /> </polygon> <polygon numVertexes="6"> <vertex x="1762.0000" y="24.0000" /> <vertex x="1862.0000" y="27.0000" /> <vertex x="1927.0000" y="68.0000" /> <vertex x="2078.0000" y="222.0000" /> <vertex x="1643.0000" y="212.0000" /> <vertex x="1642.0000" y="38.0000" /> </polygon> <polygon numVertexes="3"> <vertex x="-1150.0000" y="146.0000" /> <vertex x="-1776.0000" y="140.0000" /> <vertex x="-1476.0000" y="-25.0000" /> </polygon> <polygon numVertexes="4"> <vertex x="-2799.0000" y="103.0000" /> <vertex x="-2684.0000" y="223.0000" /> <vertex x="-3112.0000" y="256.0000" /> <vertex x="-3108.0000" y="98.0000" /> </polygon> <polygon numVertexes="3"> <vertex x="3112.0000" y="255.0000" /> <vertex x="2422.0000" y="222.0000" /> <vertex x="3120.0000" y="-71.0000" /> </polygon> <polygon numVertexes="4"> <vertex x="1142.0000" y="94.0000" /> <vertex x="1556.0000" y="221.0000" /> <vertex x="709.0000" y="226.0000" /> <vertex x="911.0000" y="93.0000" /> </polygon> <polygon numVertexes="6"> <vertex x="-2111.0000" y="89.0000" /> <vertex x="-2067.0000" y="94.0000" /> <vertex x="-2002.0000" y="139.0000" /> <vertex x="-2344.0000" y="223.0000" /> <vertex x="-2196.0000" y="112.0000" /> <vertex x="-2153.0000" y="91.0000" /> </polygon> <polygon numVertexes="4"> <vertex x="105.0000" y="233.0000" /> <vertex x="-94.0000" y="178.0000" /> <vertex x="69.0000" y="106.0000" /> <vertex x="91.0000" y="104.0000" /> </polygon> <polygon numVertexes="3"> <vertex x="-2002.0000" y="139.0000" /> <vertex x="-2067.0000" y="94.0000" /> <vertex x="-2032.0000" y="110.0000" /> </polygon> <polygon numVertexes="4"> <vertex x="-1150.0000" y="146.0000" /> <vertex x="105.0000" y="233.0000" /> <vertex x="-2344.0000" y="223.0000" /> <vertex x="-2002.0000" y="139.0000" /> </polygon> <polygon numVertexes="3"> <vertex x="413.0000" y="194.0000" /> <vertex x="356.0000" y="172.0000" /> <vertex x="376.0000" y="176.0000" /> </polygon> <polygon numVertexes="3"> <vertex x="105.0000" y="233.0000" /> <vertex x="-192.0000" y="177.0000" /> <vertex x="-94.0000" y="178.0000" /> </polygon> <polygon numVertexes="4"> <vertex x="105.0000" y="233.0000" /> <vertex x="-1150.0000" y="146.0000" /> <vertex x="-888.0000" y="139.0000" /> <vertex x="-192.0000" y="177.0000" /> </polygon> <polygon numVertexes="3"> <vertex x="3112.0000" y="255.0000" /> <vertex x="-3112.0000" y="256.0000" /> <vertex x="-2684.0000" y="223.0000" /> </polygon> <polygon numVertexes="3"> <vertex x="3112.0000" y="255.0000" /> <vertex x="1556.0000" y="221.0000" /> <vertex x="1643.0000" y="212.0000" /> </polygon> <polygon numVertexes="3"> <vertex x="709.0000" y="226.0000" /> <vertex x="173.0000" y="232.0000" /> <vertex x="476.0000" y="223.0000" /> </polygon> <polygon numVertexes="3"> <vertex x="3112.0000" y="255.0000" /> <vertex x="2078.0000" y="222.0000" /> <vertex x="2422.0000" y="222.0000" /> </polygon> <polygon numVertexes="3"> <vertex x="3112.0000" y="255.0000" /> <vertex x="105.0000" y="233.0000" /> <vertex x="173.0000" y="232.0000" /> </polygon> </fixture> </body> </bodies> <metadata> <format>1</format> <ptm_ratio></ptm_ratio> </metadata> </bodydef> And here is my code: private void loadLevel() { // TODO Auto-generated method stub AssetManager assetManager = getAssets(); try { InputStream stream = assetManager.open("tmx/path1.xml"); if(stream != null) { try { DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance(); dbf.setValidating(false); dbf.setIgnoringComments(false); dbf.setIgnoringElementContentWhitespace(true); dbf.setNamespaceAware(true); DocumentBuilder db = null; db = dbf.newDocumentBuilder(); Document document = db.parse(stream); Element root = document.getDocumentElement(); NodeList bodiesNodeList = root.getElementsByTagName("bodies"); for(int i = 0; i < bodiesNodeList.getLength(); i++) { BodyDef bodyDef = new BodyDef(); bodyDef.type = BodyType.StaticBody; bodyDef.fixedRotation = true; Element bodiesElement = (Element)bodiesNodeList.item(i); NodeList bodyList = bodiesElement.getElementsByTagName("body"); for(int j = 0; j < bodyList.getLength(); j++) { Element bodyElement = (Element)bodyList.item(j); Body body = mPhysicsWorld.createBody(bodyDef); NodeList fixtureList = bodyElement.getElementsByTagName("fixture"); for(int k = 0; k < fixtureList.getLength(); k++) { Element fixtureElement = (Element)fixtureList.item(k); FixtureDef fixtureDef = new FixtureDef(); if(fixtureElement != null) { String density = fixtureElement.getAttribute("density"); String friction = fixtureElement.getAttribute("friction"); String restitution = fixtureElement.getAttribute("restitution"); fixtureDef = PhysicsFactory.createFixtureDef(Float.parseFloat(density), Float.parseFloat(friction), Float.parseFloat(restitution)); } NodeList polygonList = fixtureElement.getElementsByTagName("polygon"); if(polygonList != null && polygonList.getLength() > 0) { for(int m = 0; m < polygonList.getLength(); m++) { PolygonShape polyShape = new PolygonShape(); Element polygonElement = (Element)polygonList.item(m); NodeList vertexList = polygonElement.getElementsByTagName("vertex"); if(vertexList != null && vertexList.getLength() > 0) { Vector2 [] vectors = new Vector2[vertexList.getLength()]; for(int n = 0; n < vertexList.getLength(); n++) { Element vertexElement = (Element)vertexList.item(n); if(vertexElement != null) { float x = Float.parseFloat(vertexElement.getAttribute("x")); float y = Float.parseFloat(vertexElement.getAttribute("y")); vectors[n] = new Vector2(x/PIXEL_TO_METER_RATIO_DEFAULT, y/PIXEL_TO_METER_RATIO_DEFAULT); } } polyShape.set(vectors); fixtureDef.shape = polyShape; } body.createFixture(fixtureDef); } } } mScene.attachChild(bgSprite); mPhysicsWorld.registerPhysicsConnector(new PhysicsConnector(bgSprite, body, false, false)); } } } catch(Exception e) { e.printStackTrace(); } } } catch (IOException e) { // TODO Auto-generated catch block e.printStackTrace(); } } Any idea where I am going wrong?

    Read the article

  • Something other than Vertex Welding with Texture Atlas?

    - by Tim Winter
    What options (in C# with XNA) would there be for texture usage in a procedural generated 3D world made of cubes to increase performance? Yes, it's like Minecraft. I've been doing a texture atlas and rendering faces individually (4 vertices per face), but I've also read in a couple places about using texture wrapping with two 1D atlases to merge adjacent faces with the same texture. If two or more adjacent faces share the same image, it'd be quite easy to wrap in this way reducing vertices by a large amount. My problem with this is having too many textures, swapping too often, and many image related things like non-power of 2 images. Is there a middle ground option between the 1D texture atlas trick and rendering 4 vertices per cube face? This is a picture of what I have currently (in wireframe). 4 vertices per face seems extremely inefficient to me.

    Read the article

  • XNA 4.0 Point Vertex Rendering

    - by luis
    I have a buffer of about 134 million particles and a very powerful computer to render them smoothly but I am getting an error when trying to render them as primitive lines it says I cannot render more than around 1 million. I wonder how can I do this, also if is there a better way to render this other than with lines, I'm comfortable with having 1 pixel points or anything as long as the vertices are shown all the time. I'm basically just plotting the points. thanks.

    Read the article

  • Per-vertex position/normal and per-index texture coordinate

    - by Boreal
    In my game, I have a mesh with a vertex buffer and index buffer up and running. The vertex buffer stores a Vector3 for the position and a Vector2 for the UV coordinate for each vertex. The index buffer is a list of ushorts. It works well, but I want to be able to use 3 discrete texture coordinates per triangle. I assume I have to create another vertex buffer, but how do I even use it? Here is my vertex/index buffer creation code: // vertices is a Vertex[] // indices is a ushort[] // VertexDefs stores the vertex size (sizeof(float) * 5) // vertex data numVertices = vertices.Length; DataStream data = new DataStream(VertexDefs.size * numVertices, true, true); data.WriteRange<Vertex>(vertices); data.Position = 0; // vertex buffer parameters BufferDescription vbDesc = new BufferDescription() { BindFlags = BindFlags.VertexBuffer, CpuAccessFlags = CpuAccessFlags.None, OptionFlags = ResourceOptionFlags.None, SizeInBytes = VertexDefs.size * numVertices, StructureByteStride = VertexDefs.size, Usage = ResourceUsage.Default }; // create vertex buffer vertexBuffer = new Buffer(Graphics.device, data, vbDesc); vertexBufferBinding = new VertexBufferBinding(vertexBuffer, VertexDefs.size, 0); data.Dispose(); // index data numIndices = indices.Length; data = new DataStream(sizeof(ushort) * numIndices, true, true); data.WriteRange<ushort>(indices); data.Position = 0; // index buffer parameters BufferDescription ibDesc = new BufferDescription() { BindFlags = BindFlags.IndexBuffer, CpuAccessFlags = CpuAccessFlags.None, OptionFlags = ResourceOptionFlags.None, SizeInBytes = sizeof(ushort) * numIndices, StructureByteStride = sizeof(ushort), Usage = ResourceUsage.Default }; // create index buffer indexBuffer = new Buffer(Graphics.device, data, ibDesc); data.Dispose(); Engine.Log(MessageType.Success, string.Format("Mesh created with {0} vertices and {1} indices", numVertices, numIndices)); And my drawing code: // ShaderEffect, ShaderTechnique, and ShaderPass all store effect data // e is of type ShaderEffect // get the technique ShaderTechnique t; if(!e.techniques.TryGetValue(techniqueName, out t)) return; // effect variables e.SetMatrix("worldView", worldView); e.SetMatrix("projection", projection); e.SetResource("diffuseMap", texture); e.SetSampler("textureSampler", sampler); // set per-mesh/technique settings Graphics.context.InputAssembler.SetVertexBuffers(0, vertexBufferBinding); Graphics.context.InputAssembler.SetIndexBuffer(indexBuffer, SlimDX.DXGI.Format.R16_UInt, 0); Graphics.context.PixelShader.SetSampler(sampler, 0); // render for each pass foreach(ShaderPass p in t.passes) { Graphics.context.InputAssembler.InputLayout = p.layout; p.pass.Apply(Graphics.context); Graphics.context.DrawIndexed(numIndices, 0, 0); } How can I do this?

    Read the article

  • When should I use indexed arrays of OpenGL vertices?

    - by Tartley
    I'm trying to get a clear idea of when I should be using indexed arrays of OpenGL vertices, drawn with gl[Multi]DrawElements and the like, versus when I should simply use contiguous arrays of vertices, drawn with gl[Multi]DrawArrays. (Update: The consensus in the replies I got is that one should always be using indexed vertices.) I have gone back and forth on this issue several times, so I'm going to outline my current understanding, in the hopes someone can either tell me I'm now finally more or less correct, or else point out where my remaining misunderstandings are. Specifically, I have three conclusions, in bold. Please correct them if they are wrong. One simple case is if my geometry consists of meshes to form curved surfaces. In this case, the vertices in the middle of the mesh will have identical attributes (position, normal, color, texture coord, etc) for every triangle which uses the vertex. This leads me to conclude that: 1. For geometry with few seams, indexed arrays are a big win. Follow rule 1 always, except: For geometry that is very 'blocky', in which every edge represents a seam, the benefit of indexed arrays is less obvious. To take a simple cube as an example, although each vertex is used in three different faces, we can't share vertices between them, because for a single vertex, the surface normals (and possible other things, like color and texture co-ord) will differ on each face. Hence we need to explicitly introduce redundant vertex positions into our array, so that the same position can be used several times with different normals, etc. This means that indexed arrays are of less use. e.g. When rendering a single face of a cube: 0 1 o---o |\ | | \ | | \| o---o 3 2 (this can be considered in isolation, because the seams between this face and all adjacent faces mean than none of these vertices can be shared between faces) if rendering using GL_TRIANGLE_FAN (or _STRIP), then each face of the cube can be rendered thus: verts = [v0, v1, v2, v3] colors = [c0, c0, c0, c0] normal = [n0, n0, n0, n0] Adding indices does not allow us to simplify this. From this I conclude that: 2. When rendering geometry which is all seams or mostly seams, when using GL_TRIANGLE_STRIP or _FAN, then I should never use indexed arrays, and should instead always use gl[Multi]DrawArrays. (Update: Replies indicate that this conclusion is wrong. Even though indices don't allow us to reduce the size of the arrays here, they should still be used because of other performance benefits, as discussed in the comments) The only exception to rule 2 is: When using GL_TRIANGLES (instead of strips or fans), then half of the vertices can still be re-used twice, with identical normals and colors, etc, because each cube face is rendered as two separate triangles. Again, for the same single cube face: 0 1 o---o |\ | | \ | | \| o---o 3 2 Without indices, using GL_TRIANGLES, the arrays would be something like: verts = [v0, v1, v2, v2, v3, v0] normals = [n0, n0, n0, n0, n0, n0] colors = [c0, c0, c0, c0, c0, c0] Since a vertex and a normal are often 3 floats each, and a color is often 3 bytes, that gives, for each cube face, about: verts = 6 * 3 floats = 18 floats normals = 6 * 3 floats = 18 floats colors = 6 * 3 bytes = 18 bytes = 36 floats and 18 bytes per cube face. (I understand the number of bytes might change if different types are used, the exact figures are just for illustration.) With indices, we can simplify this a little, giving: verts = [v0, v1, v2, v3] (4 * 3 = 12 floats) normals = [n0, n0, n0, n0] (4 * 3 = 12 floats) colors = [c0, c0, c0, c0] (4 * 3 = 12 bytes) indices = [0, 1, 2, 2, 3, 0] (6 shorts) = 24 floats + 12 bytes, and maybe 6 shorts, per cube face. See how in the latter case, vertices 0 and 2 are used twice, but only represented once in each of the verts, normals and colors arrays. This sounds like a small win for using indices, even in the extreme case of every single geometry edge being a seam. This leads me to conclude that: 3. When using GL_TRIANGLES, one should always use indexed arrays, even for geometry which is all seams. Please correct my conclusions in bold if they are wrong.

    Read the article

  • Arrays of pointers to arrays?

    - by a2h
    I'm using a library which for one certain feature involves variables like so: extern const u8 foo[]; extern const u8 bar[]; I am not allowed to rename these variables in any way. However, I like to be able to access these variables through an array (or other similar method) so that I do not need to continually hardcode new instances of these variables into my main code. My first attempt at creating an array is as follows: const u8* pl[] = { &foo, &bar }; This gave me the error cannot convert 'const u8 (*)[]' to 'const u8*' in initialization, and with help elsewhere along with some Googling, I changed my array to this: u8 (*pl)[] = { &foo, &bar }; Upon compiling I now get the error scalar object 'pl' requires one element in initializer. Does anyone have any ideas on what I'm doing wrong? Thanks.

    Read the article

  • Adding to arrays and printing arrays in Java

    - by nfoggia
    I need help figuring out how to get the user to input a number of integers no more than 10, and then add them to an array and print them out from the array. The code I have below, when run, asks the user for the integers and then runs forever and doesn't work. What am I doing wrong? public static void main(String[] args) { Scanner input = new Scanner(System.in); // create a new scanner System.out.print("Enter integers between 1 and 100\n "); int[] nextNumber = new int[10]; int i = 0; int number = input.nextInt(); while (i < nextNumber.length){ i++; nextNumber[i] = number; number = input.nextInt(); } int a = 0; while (a < nextNumber.length){ a++; System.out.println(nextNumber[a]); }

    Read the article

  • What is a better abstraction layer for D3D9 and OpenGL vertex data management?

    - by Sam Hocevar
    My rendering code has always been OpenGL. I now need to support a platform that does not have OpenGL, so I have to add an abstraction layer that wraps OpenGL and Direct3D 9. I will support Direct3D 11 later. TL;DR: the differences between OpenGL and Direct3D cause redundancy for the programmer, and the data layout feels flaky. For now, my API works a bit like this. This is how a shader is created: Shader *shader = Shader::Create( " ... GLSL vertex shader ... ", " ... GLSL pixel shader ... ", " ... HLSL vertex shader ... ", " ... HLSL pixel shader ... "); ShaderAttrib a1 = shader->GetAttribLocation("Point", VertexUsage::Position, 0); ShaderAttrib a2 = shader->GetAttribLocation("TexCoord", VertexUsage::TexCoord, 0); ShaderAttrib a3 = shader->GetAttribLocation("Data", VertexUsage::TexCoord, 1); ShaderUniform u1 = shader->GetUniformLocation("WorldMatrix"); ShaderUniform u2 = shader->GetUniformLocation("Zoom"); There is already a problem here: once a Direct3D shader is compiled, there is no way to query an input attribute by its name; apparently only the semantics stay meaningful. This is why GetAttribLocation has these extra arguments, which get hidden in ShaderAttrib. Now this is how I create a vertex declaration and two vertex buffers: VertexDeclaration *decl = VertexDeclaration::Create( VertexStream<vec3,vec2>(VertexUsage::Position, 0, VertexUsage::TexCoord, 0), VertexStream<vec4>(VertexUsage::TexCoord, 1)); VertexBuffer *vb1 = new VertexBuffer(NUM * (sizeof(vec3) + sizeof(vec2)); VertexBuffer *vb2 = new VertexBuffer(NUM * sizeof(vec4)); Another problem: the information VertexUsage::Position, 0 is totally useless to the OpenGL/GLSL backend because it does not care about semantics. Once the vertex buffers have been filled with or pointed at data, this is the rendering code: shader->Bind(); shader->SetUniform(u1, GetWorldMatrix()); shader->SetUniform(u2, blah); decl->Bind(); decl->SetStream(vb1, a1, a2); decl->SetStream(vb2, a3); decl->DrawPrimitives(VertexPrimitive::Triangle, NUM / 3); decl->Unbind(); shader->Unbind(); You see that decl is a bit more than just a D3D-like vertex declaration, it kinda takes care of rendering as well. Does this make sense at all? What would be a cleaner design? Or a good source of inspiration?

    Read the article

1 2 3 4 5 6 7 8 9 10 11 12  | Next Page >