I've noticed that, towards the end of the docs, there's a pseudo-coded programmable pipeline implementation for dealing with the texture stacks.
This has looked promising, however the export API (I'm writing an import-to-export program) I'm working with is very simple feature-wise.
Also, the only rendering sub-system I have access to is the renderer this program is being written for, which has a content pipeline that's specifically catered towards importing data from the file format I'm exporting to. In other words, going tooth to nail and writing shaders isn't necessarily possible, as I'd likely find myself rewriting a large portion of the code.
So, I made an attempt to adapt the material model towards manipulating texture image data from aiMaterials on a per-pixel basis.
When I made the attempt, however, I realized something: given that there N different textures for an arbitrary texture stack, I don't know if there's a guarantee that, for the given stack, its N images will all hold the same dimensions for a particular material.
The reasoning for why this condition is necessary (at least, as far as I can tell) is that I need a buffer of image data which essentially contains the merged representation of all N textures evaluated within stack T (where T represents any texture type). In other words, this buffer would be a substitution for evaluating the texture stacks on a per-fragment basis with shaders.
So, can I rely on the dimensions for every texture within any stack being the same? If not, what would be some recommended approaches for working with the material system, given the current constraints? I'm open to pretty much anything at this point.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think it's a moot point, as you can't do what you're wanting anyway. Regardless of texture size, each texture can potentially have its own set of UV coordinates, so there never was any possibility of merging them together without doing something complicated like creating larger per-mesh textures and resolving every single pixel that can be generated for that mesh, at whatever resolution you desire.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've noticed that, towards the end of the docs, there's a pseudo-coded programmable pipeline implementation for dealing with the texture stacks.
This has looked promising, however the export API (I'm writing an import-to-export program) I'm working with is very simple feature-wise.
Also, the only rendering sub-system I have access to is the renderer this program is being written for, which has a content pipeline that's specifically catered towards importing data from the file format I'm exporting to. In other words, going tooth to nail and writing shaders isn't necessarily possible, as I'd likely find myself rewriting a large portion of the code.
So, I made an attempt to adapt the material model towards manipulating texture image data from aiMaterials on a per-pixel basis.
When I made the attempt, however, I realized something: given that there N different textures for an arbitrary texture stack, I don't know if there's a guarantee that, for the given stack, its N images will all hold the same dimensions for a particular material.
The reasoning for why this condition is necessary (at least, as far as I can tell) is that I need a buffer of image data which essentially contains the merged representation of all N textures evaluated within stack T (where T represents any texture type). In other words, this buffer would be a substitution for evaluating the texture stacks on a per-fragment basis with shaders.
So, can I rely on the dimensions for every texture within any stack being the same? If not, what would be some recommended approaches for working with the material system, given the current constraints? I'm open to pretty much anything at this point.
I think it's a moot point, as you can't do what you're wanting anyway. Regardless of texture size, each texture can potentially have its own set of UV coordinates, so there never was any possibility of merging them together without doing something complicated like creating larger per-mesh textures and resolving every single pixel that can be generated for that mesh, at whatever resolution you desire.