• Advertisement
Sign in to follow this  

[SlimDX] Write textures to disk

This topic is 3474 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Heya, is there a way in SlimDX to write DirectX 10 textures to disk after they have been created? My textures are all 16 and 32 bit floats (not RGB, even though internally that is just value mapping). Any help would be greatly appreciated. Thanks Marcel

Share this post


Link to post
Share on other sites
Advertisement
Texture.ToFile() seems like it would do the trick.

Share this post


Link to post
Share on other sites
I see, it's a static... I assume I would need DDS format to store the data exactly the way it exists in memory, right?

Share this post


Link to post
Share on other sites
DDS will pretty much dump the texture as it exists in memory* verbatim onto disk. Of course, any non lossy format (PNG, BMP, etc) will preserve the data as long as it can handle the pixel format.
*May not be strictly true due to drivers messing with data format, but is close enough to reality.

Share this post


Link to post
Share on other sites
Thanks guys, got it to work... now, would it be possible to add a ToStream() method to the Texture class? The texture in raw format are a tad large in dds format, and so I would like to run the stream through a gzip to compress the data. Unfortunately I can't use png which is compressed as my texture format is 16 bit floats and png doesn't seem to support that texture format.

I know this is a pretty rare request, though maybe some other people might find it useful too if they can get ToStream, and maybe even ToMemory, i.e. the same methods as the ones used to load a texture map.

Thanks
Marcel

Share this post


Link to post
Share on other sites
Quote:

now, would it be possible to add a ToStream()

Unlikely. If you file a bug report I can look into it, but my guess is that there isn't any way we can do that and still have reasonable performance -- our FromStream methods are already a hidden performance pitfall, ToStream would engender even worse performance since we'd need to readback the data to get it into memory (not always doable) or write to disk and read into a stream.

The issue is that there is no native method to do this.

What's wrong with locking the texture? It produces a DataStream, which models System.IO.Stream.

Share this post


Link to post
Share on other sites
well, my system will create the textures dynamically on one server, store them gzipped in dds format on the disk and then load them on multiple other servers for rendering.

I guess I'll have to write the dds to disk and then gzip it there... shouldn't be a problem, I was just hoping I could do it straight in the program without having to do a 'two-step'

Thanks for the insight though

Marcel

Share this post


Link to post
Share on other sites
Quote:
Original post by jpetrie
The issue is that there is no native method to do this.

That's not entirely accurate. Texture.ToFile just calls D3DX10SaveTextureToFile. A ToFileInMemory method could simply call D3DX10SaveTextureToMemory.

Share this post


Link to post
Share on other sites
I missed that function the last time I went through the documentation. Since it takes a blob, however, we'd still need to perform much the same 'extra work' that causes FromStream to be inefficient.

We would have to call the native method, and then stream the data out of the blob and into the stream passed as a parameter to ToStream. I don't know how the native method is implemented, but chances are it does a lock and a read of all the suitable data -- so we'll end up reading and writing the entire texture twice, plus whatever overhead is involved in converting the texture data to the appropriate format.

I don't like the stream-related methods we have at all because of their hidden performance implications, but since there is a native mechanism to call which does provide extra functionality you can't easily get from manually locking, I could probably be convinced to implement it.

Share this post


Link to post
Share on other sites
well, if you get around to do that, great, otherwise I fully understand and if needed I can work around on my side...

Again, thanks for the great support you guys are giving

Marcel

Share this post


Link to post
Share on other sites
I'll take a look at it this evening. I am concerned there might be even more overhead involved in getting the native memory into the managed stream, but we'll see.

Share this post


Link to post
Share on other sites
Heya,

updated my code with the latest revision 653 and 32bit compiles ok, when I try to compile 64bit I get the following error:

Error 4 error LNK2020: unresolved token (0600081B) SlimDX.Direct3D9.StateBlock::.ctor Device.obj SlimDX
Error 5 error LNK2020: unresolved token (0600081C) SlimDX.Direct3D9.StateBlock::.ctor Device.obj SlimDX
Error 6 error LNK2020: unresolved token (0600081D) SlimDX.Direct3D9.StateBlock::.ctor Device.obj SlimDX
Error 7 error LNK2020: unresolved token (0600081E) SlimDX.Direct3D9.StateBlock::FromPointer Device.obj SlimDX
Error 8 error LNK2020: unresolved token (0600081F) SlimDX.Direct3D9.StateBlock::FromPointer Device.obj SlimDX
Error 9 error LNK2020: unresolved token (06000822) SlimDX.Direct3D9.StateBlock::Apply Device.obj SlimDX
Error 10 error LNK2020: unresolved token (06000823) SlimDX.Direct3D9.StateBlock::Capture Device.obj SlimDX
Error 11 error LNK2020: unresolved token (06000824) SlimDX.Direct3D9.StateBlock::get_Device Device.obj SlimDX

Share this post


Link to post
Share on other sites
Clean your solution (entirely, manually, by removing all the build output directories by hand). A number of the configuration output directories (particularly for publish) ended up stepping on each other, causing nastiness if you tried to do a full SlimDX build from the command-line. So I moved them, and this caused similar errors until I manually blew away every bit of intermediate crud on the machine.

You also might want to right-click the Direct3D 10 Stateblock.cpp, select Properties, and under C++ -> Outputs make sure it has an overloaded intermediate file name (something like $(IntDir)/$(InputName)2.obj). VS can't do this automatically, which is exceedingly annoying.

EDIT: Poking in the .vcproj for 653 looks like the Release|x64 and Public|x64 configurations are not included in the handling for intermediate file renaming by the tool I wrote, so performing the above tweak should fix you.

Sometimes I wish I didn't volunteer to work on the build system. :\ I'll fix the generator tool when I get home tonight.

Share this post


Link to post
Share on other sites
kk, that worked, only getting one warning now, not sure that is important:

Warning 2 warning C4018: '<' : signed/unsigned mismatch c:\Program Files\SlimDX\Source\source\direct3d10\Texture.cpp 93 SlimDX

Share this post


Link to post
Share on other sites
ok, saw what this is refering to, doesn't seem to be a problem.

I did find a small spelling error though:

static bool ToStream( Texture^ teture, ImageFileFormat format, System::IO::Stream^ stream );

should be

static bool ToStream( Texture^ texture, ImageFileFormat format, System::IO::Stream^ stream );

texture instead of teture

Share this post


Link to post
Share on other sites
Quote:
Original post by jpetrieYou also might want to right-click the Direct3D 10 Stateblock.cpp, select Properties, and under C++ -> Outputs make sure it has an overloaded intermediate file name (something like $(IntDir)/$(InputName)2.obj). VS can't do this automatically, which is exceedingly annoying.


VS can do this automatically, and usually does. For some reason it forgets to do this every once in a while, causing us headaches like this.

Quote:
ok, saw what this is refering to, doesn't seem to be a problem.


Even though it may never be a problem, we make it a point to clear up every warning.

Quote:
I did find a small spelling error though:

static bool ToStream( Texture^ teture, ImageFileFormat format, System::IO::Stream^ stream );

should be

static bool ToStream( Texture^ texture, ImageFileFormat format, System::IO::Stream^ stream );

texture instead of teture


OK, we'll be sure to fix that up. FxCop most likely would have caught that anyway.

Share this post


Link to post
Share on other sites
Quote:

VS can do this automatically, and usually does. For some reason it forgets to do this every once in a while, causing us headaches like this.

I'm skeptical. I can only remember one situation where it's done The Right Thing for me. Most of the rest of the time it breaks the build rather nicely -- I forget to fix the object file, and everybody but me isn't buildable because I didn't do full rebuild of every configuration and platform every time. :|

Share this post


Link to post
Share on other sites
Quote:
Original post by jpetrie
Quote:

VS can do this automatically, and usually does. For some reason it forgets to do this every once in a while, causing us headaches like this.

I'm skeptical. I can only remember one situation where it's done The Right Thing for me. Most of the rest of the time it breaks the build rather nicely -- I forget to fix the object file, and everybody but me isn't buildable because I didn't do full rebuild of every configuration and platform every time. :|


I think it just doesn't like you :) It's never caused a problem for me.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement