Tag Info

New answers tagged

0

Be sure you open the Sprite sheet from the path of the asset. You can achieve this either opening the sheet within the project window or going thru your documents to the asset folder of the project location. You can open it with your editor of choice and can then update and apply the changes to the project file "your sprite sheet" doing this will update ...


0

I suppose one way to speed up the process is to format your sprite sheet in a way that its easy to edit. For example each animation to be in a couple of rows, and if there is space left, then let it white. In the end, after you have settled on a texture, go and edit the white spaces out and reattach the correct textures coordinates for all animations. I ...


2

It is possible to just pass the Content Manager to your modules, and have them load their own textures/data. Its also tidier, as the Module is responsible for loading its own textures, and doesn't have to depend on its resources being loaded elsewhere. I do something similar - my data objects have a string specifying a texture/model, and my rendering code ...


0

On your run configuration make sure you have set your "Working directory" to your asset folder. Example: This only applies for the desktop run config.


0

With rect_coordinate ranging from -1 to 1 and assuming sin/cos functions take radian as inputs, for each pixel in the rectangular texture do: color CubeToRectangle(vec2 rect_coordinate) { vec3 cube_map_coordinate; cube_map_coordinate.x = cos(rect_coordinate.x * PI * 2) * cos(rect_coordinate.y * PI); cube_map_coordinate.y = sin(rect_coordinate.y ...


0

Your problem is where you commented out glBindFramebuffer(GL_FRAMEBUFFER, 0);. You need to bind to a different FBO there, otherwise you lose everything you just rendered when you call glClear a couple lines down. Because of this reading from and writing to the same FBO texture at once cannot work. You'll need a separate FBO and texture to write to.


1

Usage of glVertexAttribPointer is suspicious. glVertexAttribPointer( 2, // 3, // Mistake in TexCoords, should be 2 GL_FLOAT, // GL_FALSE, // 0, // Should be size of your vertex (void*)0 // Should be offset within vertex ); Check the documentation ...


1

An .obj model file may come with a companion file with the extension .mtl. Such a file is a material library that contains entries mapping from a material name to properties, including texture filenames to use for things like diffuse and specular. In your obj-file, there are mtllib a.mtl directives to indicate the material library to use, and usemtl aaaa ...


0

For this kind of thing, it depends on what your goals is. If you're looking to ensure that lines are 1 pixel wide, then you could draw the grid using lines instead of textured triangles: However with ensuring that lines are 1 pixel wide, when they're so far away that the individual grid spaces are less than 1px, it will look like a solid: With your ...


0

You can't avoid this problem, you can try super sampling to make it less jarring ... but high frequency + high contrast works very bad in quantisize space. I go around this with a very small bit of blurring on the texture, it's counter intuitive but then you have more chance than a pixel pick a blur value and make the line looks antialiased on the texture, ...


0

The way you draw them, you have big cells that contain 10x10 small cells. Would it be acceptable to draw only the big cells when they're at a certain distance from the camera? That would be one possibility. Another would be to actually draw lines, like in a wireframe mesh. They are always exactly one pixel wide. That's all the ideas i have right now.


1

If you use a point sampler for your mask texture, then you can store as many IDs as bits in your texture: for a 32-bit RGBA texture you'd be able to store 128 different IDs. In such a case though, as you have a single bit per ID, there's virtually no blending as you have only 0 or 1. The more bits you devote per ID, the greater the blending granularity, ...


0

Double check if you are truly using viewport correctly. You're not rebinding the texture to the FBO. That SHOULDN'T be necessary, however the spec makes no guarantee that glTexImage won't screw up any attached framebuffers, so assume that it can. If that doesn't work then its the way you're sampling from it. For simply allocating a texture with undefined ...


2

To be safe I'd delete and recreate the entire FBO. Some drivers have strange stability issues when recycling/resizing FBOs. I've had entire screen flickers and occasional crashes. Switching attached textures to another of the same size & type seem to work fine all the time on all drivers but with some drivers it is much faster (more than 100x) to have ...


1

To calculate perspective projection divide by w. vec4 result = vec4(x, y, z, 1) * perspective_view_model_matrix; result /= w; You are then left with the (x,y) in screen space (-1 to 1). Multiply this by 1/2 screen width,height and you get pixel coordinates. You then need to take the corresponding vertex UVs, multiply by the texture size and you get ...


0

You could very well have two separate shaders. A nice way to do this would be to create a Material object that would contain pointers to some shader and maybe a texture (resources should be stored inside a ResourceManager or something similar). But if that's too much work you could always use a special texture that always exists for objects with missing ...


1

You should always do 3D textures in powers of 2. Just because of how video hardware operates, it is more efficient for them to deal with image dimensions in powers of 2; in most cases this processing difference won't be noticeable, but for complex graphics these little things can add up.


1

I'm not sure what you mean by un-normalized texture coordinates. All texture lookups are going to be in the range of 0-1. You can have them be anywhere in that range however. If you're having precision problems in the range of 0-1 I suspect something else going on. A couple of hints to help fix this: For example, make sure you don't have GL_LINEAR set ...


2

Since there's no accepted answer I add some info, I wanted just to add things not already said by Sean in his answer. TexelFetch treat the texture as a Image, so you can access exactly the content of pixels. You usually do that when you need exactly that content, wich is in few but usefull occasions: Certain post processing filters (Guassian blur exploits ...


0

All you need to do is first create a mesh and then distort it. Create a mesh that's just a strip of triangles. Texture the mesh using your terrain texture. Deform each vertex of the mesh by using perlin noise. What I mean exactly is this: // Deform a 3D vertex by noise vertex.position.y += Perlin(vertex.position.x, vertex.position.y, vertex.position.z); ...


1

If you let your library scale down the textures and drop the originals from memory then you will not have any problems with memory consumption. Your load times will however increase drastically, along with the download size and storage space needed for your game. If you are going to ship on phones then you should definitely scale your textures lower than ...


1

I've never used libGDX but textures Cost a lot of memory in general. Which isn't a big deal on PC but you have to watch out with mobile devices which have limited resources. Let's say you have a device with 256MB of memory, you have 10 textures in your scene and each texture is about 8MB (assuming we're using 2048x2048 32-bit png). Thats using about 30% of ...



Top 50 recent answers are included