Specify UV coordinates for a texture about three-d HOT 5 CLOSED

In the 0.4.0 release, there is full support for textures and uvs. I did not implement a composite mesh, at least not yet, but it is very simple to do yourself, just collect all meshes in a struct. Or simply call the render function for each sub mesh. Anyway, I will close this issue. Please let me know if there are more issues.

from three-d.

Hi. Thanks a lot, really great that you found it useful!

You are right. UV coordinates are not supported right now but it is a very common thing, so for sure it should be. I have a plan for how to do it and it should not be a lot of work at all, so give me a day or two, then I have something you can try out.

About meshes with multiple textures, I am not sure. It seems to be fairly common to just render the different parts of the mesh separately which you can already do (when uv coordinates are supported of course). So create a new Mesh for each sub mesh with common positions, normals and uv coordinates, but different indices. You can collect these sub meshes in a new struct with one render function so it seems as one mesh. The problem is of course that the buffers (position, normal and uvs) are created for each sub mesh and contain a lot of unused data. One option is to throw away unused data before sending it to the GPU which means that there is only little duplicate data (the data shared by multiple sub meshes). Another option is to let the user create and share the buffers which requires a bit more work from the user. The final option I can think of is to create a new composite mesh type which explicitly contains sub meshes. What do you think? What will solve your problem?

Also, if you have something at some point you want to show, I would appreciate a link or something to add to the examples list.

from three-d.

Everything always take longer than expected. Now, in the 'development' branch, there is a TexturedMesh in addition to the standard coloured Mesh which also takes uv coordinates as input. I have also added a textured penguin to the texture example so you can see how to do it. I will keep working on this so some parts of it might change a bit, but at least you can try it out.

from three-d.

Hey! Sorry this took me a while to get back to, it's been a busy week!

The composite mesh type sounds like a good idea, though I can try the first two options. I'll have to check how many actual objects (and polys) the project will render. It probably won't be too many, we can implement some basic streaming anyway if it's too many. The models in the project do contain a lot of composites though, usually for different texture sets that are shared among many individual meshes. For example, some objects in one area may share a generic texture for one part, then use a more specific texture for another part.

I'll check the dev branch when I get back to my project though, thanks for working on this! I'm fairly new to this level of 3D! I've been on the creation side a fair bit, but never touched the rendering part much until now.

from three-d.

No problem at all. Unfortunately, I know it all too well myself :)

I actually had yet another idea about composite meshes, but before I make a lot of changes, I have some questions about how the meshes are separated. Specifically, how is the relationship between the indices, positions, normals and uv coordinates? I guess there are several sets of indices, ie. one for each submesh, and also one texture for each submesh? Positions and normals could be shared at the seam between two submeshes BUT the uv coordinates should be different between submeshes, right? If I am right then two submeshes cannot share indices and the positions and normals at the seam has to be duplicated anyway. This means that there is no loss in creating a TexturedMesh for each submesh. It would of course be nice to collect the submeshes in one struct with one render function, but that I would leave to the user since it is very few lines of code and would be very difficult for me to do in general.

And about sharing textures, I will for sure make the render function take a texture reference as input, so the TexturedMesh does not own the texture such that it cannot be used elsewhere. So something like this:

mesh.render(&Mat4::identity(), &camera, &texture);

Also, I think it is perfect you are more into the creation side, since I don't have much experience with that (I have worked many years with rendering but in CAD and similar applications, not in games. And I am more of a backend technical guy, not an artist :) ). Therefore, I will for sure ask some stupid questions, so please feel free to ask some (stupid or not stupid) questions back :)

from three-d.