I have exported my Game world (Tiles + Collision Tiles) from Tiled as a Lua File, How do i integrate this into my Love2d Game and Determine which one is a Walkable path and Which one is not?
If you look in this question (What code do I wrap around Lua code in C++ with LuaBind?) you will find an example of what the lua file looks like. All it is is a file that when run in lua will return a dictionary containing all the data about your game world.
Assuming your map is called "mymap.lua" you would do this in one of the following ways:
require("mymap")
local mymap = love.filesystem.load("mymap.lua")()
Then, to use it, you would do something like:
-- loads the sprites of the first tileset
local tileset1 = love.graphics.newImage(mymap.tilesets[1].image)
-- print the width and height of the first layer
print(mymap.layers[1].width, mymap.layers[1].height)
As for what each piece of the imported data means, you will have to work it out yourself.
Related
I'm working on an older project that uses D3D9 for rendering 3D environments.
I have a texture file loaded into memory, that I'm applying onto a simple 3D model for rendering. I'm loading this file using the D3DXCreateTextureFromFileInMemory function (MS Docs function link: https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dxcreatetexturefromfileinmemory), and everything works okay.
However, instead of simply reading & loading the entire texture file, I want to only be able to read & load a square portion of it (a sub-texture of sorts). I have a pair of UV coordinates of the supposed square portion of the sub-texture (one UV coordinate for top-left corner of square, one for the bottom-right), relative to the main texture file, but I can't find a D3D9 function that does such a thing (I believe the correct wording for this would be a "Texture Atlas", but I've only heard it a couple of times and I'm not sure).
Here is an example diagram, to make sure my question is clear:
Looking over the MS Docs for the D3D9 texture functions, D3DXCreateTextureFromFileInMemoryEx (MS Docs link: https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dxcreatetexturefromfileinmemoryex) can also be found with is a supposed upgrade of the previous D3DXCreateTextureFromFileInMemory function, however it only accepts a "height" and a "width" parameters, but not any sort of positional parameter pair. There are also alternative functions that use "Resources" instead of files in memory, but they also do not appear to accept any sort of positional parameters (such as D3DXCreateTextureFromResourceEx, MS Docs link: https://learn.microsoft.com/en-us/windows/win32/direct3d9/d3dxcreatetexturefromresourceex).
There are also several functions for a "UV Atlas" present in the MS Docs archives (https://learn.microsoft.com/en-us/windows/win32/direct3d9/dx9-graphics-reference-d3dx-functions-uvatlas), however I do not think those would be helpful to me.
Is what I'm trying to achieve here even possible using D3D9? Are there any functions that I may be missing that could help me achieve this goal?
I'm working on a student project for which I want to texture a mesh that I scanned using an iPad equipped with the new LiDAR sensor.
To texture a mesh, however, I need to add texture coordinates. My current plan is to convert the scanned mesh to an MDLMesh and add all submeshes to an MDLAsset container. Afterwards, I iterate over the MDLMeshes using a foreach-loop. In each iteration I'm calling the function "MDLMesh.addUnwrappedTextureCoordinates" on the current mesh. unfortunately, it always results in a crash. Sometimes I can loop through 2 meshes before I get an error, sometimes I does not even add UV's to a single mesh.
I'm not at expert at swift or Model IO, but it seems strange to me, that this operation crashes while I can add normals just fine.
The error I'm getting looks like this:
Can't choose for edge creation
libc++abi.dylib: terminating with uncaught exception of type std::out_of_range: unordered_map::at: key not found
The code I'm using looks like this:
private func unwrapTextureCoordinates(asset: MDLAsset) -> MDLAsset{
let objects = asset.childObjects(of: MDLMesh.self)
for object in objects{
if let mesh = object as? MDLMesh{
mesh.addNormals(withAttributeNamed: MDLVertexAttributeNormal, creaseThreshold: 0.5)
mesh.addAttribute(withName: MDLVertexAttributeTextureCoordinate, format: .float2)
mesh.addUnwrappedTextureCoordinates(forAttributeNamed: MDLVertexAttributeTextureCoordinate)
}
}
return asset
}
Hopefully someone can tell me what's wrong or point me in the right direction.
After I could not figure out what was causing the issue, I resorted to Unity and its ARFoundation wrapper to see whether I was able to calculate any UVs there. I found that Unity's equivalent to Model I/O's "addUnwrappedTextureCoordinates", namely Unwrapping.GeneratePerTriangleUV, calculates 3 UVs for each triangle.
Now, when I run this function in Unity, I also get an out-of-range-exception for my mesh, just like in Swift. The error description says that the number of UV coordinates cannot exceed the number of vertices in the mesh - which makes sense since I get three times as many UV coordinates as I have vertices in my mesh. Therefore, I highly suspect that the out-of-range-exception in Swift using Model I/O has the same cause.
Surely, there are many workarounds for this, but I resorted to a different solution since the "Unwrapping" class is part of the "UnityEngine.Editor" namespace anyways and therefore I would not be able to use it in a finished build (which is what I want).
Instead, I came across the function in this thread to calculate a single set of UVs for my mesh. I utilized it, and it worked exactly as I want it to. The code is written in C# and therefore I decided to continue my project using the Unity Engine. However, I don't think it will be a lot of trouble to translate the function into Swift.
im searching now for a quite long time to find something working to import
Blender 3D .obj files into xcode to use it on an iphone application.
i cant find a description how to implement something like that anywhere!
i dont want to use any engine. i just want to know the steps i have to
fullfill and the basic things to do.
there is really nothing on the www. you can find articles from 2005 - 2008
but thats all not up to date and nothing working.
So, does anybody knows how to do that?
take a look at the source in libgdx, and take a look at the objloader. He built the lib to be able to load obj files, and is supposed to work across multiple platforms (including ios). From reading the source you will see that creating an object loader for just the vertices is really simple, but becomes more complicated when you start caring about the normals and texture coords. Here is a simple algorithm for scraping an obj file (I will leave parsing the associated tpl file for the reader's own research):
Read in the lines of the file, throwing out all lines that start with # (comments)
Vertices look like: v 1.000 1.000 1.000, so, if line starts with 'v ' split the line on the spaces and store (and convert to float) the 3 floats as a vertice.
Normals look like: vn 1.000 1.000 1.000, so, if the line starts with 'vn ' do the same as number 2, but store as a normal.
Texture coords look like vt 1.000 1.000 with a possible 3rd [w] value, split and store the line in the same way.
Now it gets tricky, there is the face descriptions that look like f 1/1/1 2/2/2 3/3/3 these are describing 3 vertices/textcoords/normals (in that order) for each of the vertices of a shape (normally they are triangles) by index. The hardest part about this is that the obj file type uses three indexes instead of one like opengl or direct3d. So you will have to shuffle around the order of your vertexes/coords/normals so that you can utilize indexed drawing on the sources.
E.g. Basically you have to get the f 1/300/30 40/22/400 20/30/10 to become more like f 1/1/1 2/2/2 40/40/40 through reshuffling the order.
This site gives you an idea of this same algorithm and shows you an example of how to go about this in a high level algorithm (go about midway down on the page), and the source code he references for you to check out can be found here.
Anyways, let me know if you need anymore assistance. :)
Edit:
By the way if you see something like this: f 1//4 2//5 3//7 don't be alarmed, this is a valid file as intended and just means (in this instance) that there are no texture coords
I used the GLEssentials sample app as a starting point. It is really bare bones, but its kind of what you want to start with so you can really understand the format for when you decide to add to it later.
https://developer.apple.com/library/mac/#samplecode/GLEssentials/Introduction/Intro.html
I am using the lua love engine to make a simple game. However, im having a little trouble with collision.
I have a polyline between a set of points (representing the rocky ground) and a box I need to collide with it, but I cant think of an easy implementation.
love.graphics.line( 0,60, 100,70, 150,300, 200,230, 250,230, 300,280, 350,220, 400,220, 420,150, 440,140, 480,340 )
If anyone could help with code snippets or advice, it would be much appreciated.
You need to create a more abstract representation of the ground, from which you can generate both the line for the graphics, and the body for the physics.
So for example:
--ground represented as a set of points
local ground = {0,60, 100,70, 150,300, 200,230, 250,230, 300,280, 350,220, 400,220, 420,150, 440,140, 480,340}
This may not be the best representation, but I will continue with my example.
You now have a representation of the ground, now you a way of converting that something that your physics can understand (to do the collision) and something that your graphical display can understand (do draw the ground). So you declare two functions:
--converts a table representing the ground into something that
--can be understood by your physics.
--If you are using love.physics then this would create
--a Body with a set PolygonShapes attached to it.
local function createGroundBody(ground)
--you may need to pass some additional arguments,
--such as the World in which you want to create the ground.
end
--converts a table representing the ground into something
--that you are able to draw.
local function createGroundGraphic(ground)
--ground is already represented in a way that love.graphics.line can handle
--so just pass it through.
return ground
end
Now, putting it all together:
local groundGraphic = nil
local groundPhysics = nil
love.load()
groundGraphic = createGroundGraphic(ground)
physics = makePhysicsWorld()
groundPhysics = createGroundBody(ground)
end
love.draw()
--Draws groundGraphic, could be implemented as
--love.graphics.line(groundGraphic)
--for example.
draw(groundGraphic)
--you also need do draw the box and everything else here.
end
love.update(dt)
--where `box` is the box you have to collide with the ground.
runPhysics(dt, groundPhysics, box)
--now you need to update the representation of your box graphic
--to match up with the new position of the box.
--This could be done implicitly by using the representation for physics
--when doing the drawing of the box.
end
Without knowing exactly how you want to implement the physics and the drawing, it is hard to give more detail than this. I hope that you use this as an example of how this code could be structured. The code that I have presented is only a very approximate structure, so it will not come close to actually working. Please ask about anything that I have been unclear about!
I've recently taken the plunge into DirectX and have been messing around a little with Anim8or, and have discovered several file types that models can be exported to that are text based. I've particularly taken to VTX files. I've learned how to parse some basics out of it, but I'm obviously missing a few things.
It starts with a .Faceset with is immediately (on the same line) followed by the number of meshes in the file.
For each mesh, there is one .Vertex section and one .Index section in that order and the first pair of .Vertex/.Index sections are the first mesh, the second set are the second mesh and so on as you'd expect.
In a .Vertex section of the file, there's 8 numbers per line and an undefined number of lines (unless you want to trust the comments Anim8or has put just before the section, but that doesn't seem to be part of the specs of the file, just Anim8or being kind). The first 3 numbers correspond to X, Y, and Z coordinates for a particular point that'll later be used as a vertex, the other 5 I have no idea. A majority of the time, the last 2 numbers are both 0, but I've noticed that's not ALWAYS true, just usually true.
Next comes the matching .Index section. This section has 4 numbers. The first 3 are reference numbers to the Vertexes previously stated and the 3 points mark a triangle in the model. 0 meaning the first mentioned Vertex, 1 meaning the next one, and so on, like a zero-based array. The 4th number appears to always be -1, I can't figure out what importance it has and I can't promise it's ALWAYS -1. In case you can't tell, I'm not too certain about anything in this file type.
There's also other information in the file that I'm choosing to ignore right now because I'm new and don't want to overcomplicate things too much. Such as after every .Index section is:
.Brdf
// Ambient color
0.431 0.431 0.431
// Diffuse color
0.431 0.431 0.431
// Specular color and exponent
1 1 1 2
// Kspecular = 0.5
// end of .Brdf
It appears to me this is about the surface of the mesh just described. But it's not needed for placement of meshes so I moved past it for now.
Moving on to the real problem... I can load a VTX file when there's only one mesh in the VTX file (meaning the .FaceSet is 1). I can almost successfully load a VTX file that has multiple meshes, each mesh is successfully structured, but not properly placed in relation to the other meshes. I downloaded an AT-AT model from an Anim8or thread in a forum and it's made up of 344 meshes, when I load the file just using the specs I've mentioned so far, it looks like the AT-AT is exploded out as if it were a diagram of how to make it (when loaded in Anim8or, all pieces are close and resemble a fully assembled AT-AT). All the pieces are oriented correctly and have the same up direction, but there's plenty of extra space between the pieces.
Does somebody know how to properly read a VTX file? Or know of a website that'll explain what those other numbers mean?
Edit:
The file extension .VTX is used for a lot of different things and has a lot of different structures depending on what the expected use is. Valve, Visio, Anim8or, and several others use VTX, I'm only interested in the VTX file that Anim8or exports and the structure that it uses.
I have been working on a 3D Modeling program myself and wanted a simple format to be able to bring objects in to the editor to be able to test the speed of my drawing routines with large sets of vertices and faces. I was looking for an easy one where I could get models quickly and found the .vtx format. I googled it and found your question. When I was unable to find the format on the internet, I played around and compared .OBJ exports with .vtx ones. (Maybe it was created just for Anim8or?) Here is what I found:
1) Yes, the vertices have eight numbers on each line. The first three are, as you guessed, the x, y, and z coordinates. The next three are the vertex normals, nx, ny, and nz. You may notice that each vertex appears multiple times with different normals for each face that contains it. The last two numbers are texture coordinates.
2) As for the faces, I reached the same conclusions as you did. The first three numbers are indices into the vertex list above. The last number does appear to always be -1. I am going to assume that it has something to do with the facing of the face. (e.g. facing in or out.) Since most models are created with the faces all facing appropriately, it stands to reason that this would be the same number for all of them.
3) One additional note: When comparing the .obj with the .vtx, I did notice that the positions of the vertices changed. This was also true when comparing with the .an8 file. This should not be a "HUGE" problem as long as they are all offset by the same amount in each vertex and every file. At least then it could be compensated for.
Have you considered using the .obj file format? It is text-based and is not extremely difficult to parse or understand. There is quite a bit of information about it online.
I am going to add that, after a few hours inspection, the vtx export in Anim8or seems to be broken. I experienced the same problem as you did that the pieces were not located properly. My assumption would be that anim8or exports these objects using the local coordinates for each mesh and not accounting for transformations that have been applied. I do also note that it will not IMPORT the vtx file...
Based on some googling, it seems you're at the wrong end of the pipeline. As I understand it: A VTX file is a Valve Proprietary File Format that is the result of a set of steps.
The final output of Studiomdl for each
Half-Life model is a group of files in
the gamedirectory/models folder ready
to be used by the Game Engine:
an .MDL
file which defines the structure of
the model along with animation,
bounding box, hit box, material, mesh
and LOD information,
a .VVD file which
stores position independent flat data
for the bone weights, normals,
vertices, tangents and texture
coordinates used by the MDL, currently
three separate types of VTX file:
.sw.vtx (Software),
.dx80.vtx (DirectX
8.0) and
.dx90.vtx (DirectX 9.0) which store hardware optimized material,
skinning and triangle strip/fan
information for each LOD of each mesh
in the MDL,
often a .PHY file
containing a rigid or jointed
(ragdoll) collision model, and
sometimes
a .ANI file for To do:
something to do with model animations
Valve
Now the Valve Source SDK may have some utilities in it to read VTX's (it seems to have the ability to make them anyway). Some people may have made 3rd party tools or have code to read them, but it's likely to not work on all files just cause it's a 3rd party format. I also found this post which might help if you haven't seen it before.