Currently volume textures aren't supported in the Content Pipeline. So if I have a mesh that references a volume texture it will fail compiling.
So, is it just a matter of writing a custom importer for volume dds files or is it all the way through the pipeline Will ContentManager.Load<Texture3d>(...) work if I just write the importer Say it is so...it is Christmas after all :-)
Where in content pipeline does volume textures fail?
Matt Deane
You're kidding No, you're probably not kidding. And a clone of one would probably be fixed as well.
In which case, I guess the only way really would be to create a completely custom class. That would be a pain. Though, I suppose at least the BitmapContent and even the MipMapChain classes are available to help out. Most of the rest of the work of a volume texture was going to have to be done anyways. Actually... come to think of it, it might not be a good idea to use the MipMapChain class either since the mip map should be blending in three dimensions instead of two.
So, from what I'm seeing, Malmer, or whoever else becomes interested in using a volume texture, will need to create a custom importer (preferably that processes a unique file extension so that it can be recognized automatically for external links in other resources such as models) that generates a custom content class. Because MipMapChainCollections can't be constructed and the ones created by other classes are marked as fixed, the TextureContent class is unusable as a basis for that custom content class. And, of course, at that point it is probably inappropriate to use the MipMapChain class since it won't blend across three dimensions and that makes using the BitmapContent class pointless since it would largely just be a container for raw data (may as well create a storage class that stores the raw data across all three dimensions simultaneously so that it can be blended nicely). Processing, at least, would be minimal (depending on at what stage its decided to create the mip maps). The data can basically be dumped for the serialization step, but then, of course, the actual 3D texture to be used in game would have to be created from that dumped data, though that also wouldn't be too bad. Well, actually, it either won't be too bad or is impossible to do. I haven't looked at how a 3D texture would be created in XNA at run time yet.
So, really, its that import step that's hard. And there's no way that any of us still see to make it easier I suppose if the pipeline assembly being created will only be used by the developers, using the Managed DirectX library to load the texture and the XNA library to provide the framework for processing/converting it would be an option to ease things a bit.
Still, I feel for Malmer on this one. That's painful.
I am me
But the TextureContent constructor requires a MipmapChainCollection. Passing a null does not work since then the Faces property will be null.
A really ugly hack is to do something like this in the constructor, but that really isn't pretty.
public
Texture3DContent() : base((new Texture2DContent()).Faces){
...
}
clint 2
So the best way as it is now to make all this automatic would be to do something like this, right
1. Create a custom importer that reads files with the extension ".ddsvolume" or similiar
The custom importer would output a raw byte array which XNA handles transparently.
Question: Is it possible to work with double extensions such as ".volume.dds" so that it works inside an external tool such as 3dsmax
2. Set the processor to "Pass through"
Will cause the data to just flow through as a byte array.
3. Create a serializing ContentTypeWriter<Texture3D>
Will probably just serialize the byte array.
4. Create a deserializing ContentTypeReader<Texture3D>
Will create a Texture3D object and simply do SetData with the stuff in the byte array.
5. Play and be happy.
Will this work
crussting
Noooooooo...!
Anyways, volume textures are useful for so many things. To begin with it is probably the easiest way to do simple animations for things like smoke and explosions. Just interpolate the w coordinate and there you have smooth transitions for free. Anyways...I've already made a post on connect about this when rtm was just released. Just hoped that maybe I could easily skip the whole waiting for it to be implemented thing. As it is now it feels like a little bit too much work, and I'm not entirely sure it will work with ContentManager.Load<Model>( ... ) calls anyways, which is desirable.
// Fredrik
DocMoriarty
That would be a nice work around but unfortunately the MipMapChainCollections created by Texture2DContent and TextureCubeContent are marked as fixed and will throw an exception if you try to add/remove items.
Cheers,
Leaf.
rmccullough
I sure hope this is a bug and not intentional. Are there more parts of the content pipeline that are similiar to this
Arun Narayan
I think this is why Eli suggested using a new file extension for volume textures. If your volume texture importer is the default for that file extension then it will automatically be selected and the ModelTextureProcessor works with TextureContent which your volume texture content type should be derived from. I'm only guessing though.
I had a quick look into this and it doesn't look like its possible to do this using TextureContent because the TextureContent constructor requires a MipMapChainCollection and the MipMapChainCollection constructor is internal. I can't see any other way to create a MipMapChainCollection. You could maybe add this to your suggestion on Connect.
Cheers,
Leaf.
Speedy2171
Sorry, there are no content readers for Texture3d, and no design time concept so it's going to have to be the whole pipeline. I'd recommend making a Texture3DContent that extends from TextureContent. Each level of the volume texture could be a member of the "faces" collection.
Also, when you write the volume texture importer, your life would probably be easiest if you made up a new file extension to use for volume textures, and set the importer to automatically handle that file type.
I'm curious what you're using this for, too. We're always interested in your feedback; if you think the content pipeline should handle volume textures, feel free to request it on connect.
n0n4m3
FernandoAlvarez
I've read the samples and it looks easy enough for simple things such as the example with the pixel shader, but ModelContent and associated classes feels painfully undocumented though. A detailed description of the heirarchy and common opaqe data etc would be great for the docs. Thankfully it looks as if TextureContent is quite easy on the eyes :-). I will look into this.
I don't really understand how it will work with Load<Model> though. How does it know that for a certain texture it should use Texture3D instead of Texture2D when loading sub thingies
JackTripper
hieu.nguyen
TextureContent only has one public constructor, that constructor takes an instance of MipMapChainCollection and that instance is used to back up the Faces property - if you can't pass in a valid instance then you can't use the Faces property.
Since you can't create a MipMapChainCollection, you can't create a TextureContent which means that you can't derive from TextureContent because you can't call the base constructor; unlike Texture2DContent and TextureCubeContent which are able to create and pass a MipMapChainCollection to their base constructor.
If you could create a MipMapChainCollection then you could very easily use it to handle volume texture data by creating one with a number of faces equal to the number of layers of the volume texture. At that point its likely that most of the methods that work with TextureContent would still work with volume textures, including as Eli said the Model* processors.
You're quite correct though that there are ways of building volume textures without deriving from TextureContent, I was just thinking that it would be the neatest and least amount of work to do so.
Cheers,
Leaf.
MickDotNet
I added the bug to the connect post. Here is the link:
https://connect.microsoft.com/feedback/ViewFeedback.aspx FeedbackID=245149&SiteID=226
Steven Syfuhs
Yeah, I noticed that too after my post. However, you could always pull a fast one on it and derive from Texture2DContent instead of TextureContent. The Texture2DContent class has a parameterless constructor. Then you would still be able to add new elements to the MipChainCollection created.
That is a workaround, though... but, then if at a later date they make it possible to construct the MipChainCollection, changing your class to derive from TextureContent instead of Texture2DContent should be relatively minor.