Jump to content

  • Log In with Google      Sign In   
  • Create Account

SOIL: new lightweight image loading lib


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
130 replies to this topic

#21 speciesUnknown   Members   -  Reputation: 527

Like
0Likes
Like

Posted 24 August 2007 - 02:56 PM

Well, Ive just read the header file and was astonished to find that it supports loading and saving files, and can automaticaly generate a screenshot. I'll definitely be using this for the next few days. Good Job!

Sponsor:

#22 ForestMaster   Members   -  Reputation: 164

Like
0Likes
Like

Posted 24 August 2007 - 09:31 PM

ye lonesock its becoming more and more interesting, keep up the good work!

#23 lonesock   Members   -  Reputation: 803

Like
0Likes
Like

Posted 25 August 2007 - 04:01 AM

@ speciesUnknown & ForestMaster: thanks!

Updated SOIL a bit:
* now has the SOIL_CREATE_NEW_ID enum in SOIL.h (as shown in the usage examples)
* can now load uncompressed DDS files (directly which will preserve MIPmaps, or via stb_image which will ignore the MIPmaps, then regenerate them if requested)

The next thing I'm going to implement is loading cubemaps from single image files. This would include DDS cubemap files, and also any other format where the width is 6x the height (or vice versa). This way you could stitch together your 6 265x265 cubemap faces side to side into a single 1536x256 texture, or vertically to form a 256x1536 texture, then save it as png/jpg(make sure that your image size is a multiple of 8 so the jpeg blocks don't cross image boundaries)/dds(ditto, but multiples of 4)/whatever.

I'd like to just add a flag to SOIL_load_OGL_texture(), SOIL_FLAG_SPLIT_CUBEMAPS. This way SOIL would automatically split any image texture where the width is 6x the height and load it as a cubemap. Here's my question...does that make sense to everybody, or should I introduce a new function (SOIL_load_OGL_single_cubemap() or similar)? I'm not sure which way would be more intuitive.

Please cast your votes!

P.S. this version of the zip only has the library built with MinGW and VC2k5 Express...the VC6 and VC2k3 versions will have to wait till I get back to work. But the project files are still there, so you can easily perform the build if necessary.

#24 ForestMaster   Members   -  Reputation: 164

Like
0Likes
Like

Posted 25 August 2007 - 05:50 AM

Quote:
Original post by lonesock
I'd like to just add a flag to SOIL_load_OGL_texture(), SOIL_FLAG_SPLIT_CUBEMAPS. This way SOIL would automatically split any image texture where the width is 6x the height and load it as a cubemap. Here's my question...does that make sense to everybody, or should I introduce a new function (SOIL_load_OGL_single_cubemap() or similar)? I'm not sure which way would be more intuitive.

Please cast your votes!


you can make two functions with the same name:

unsigned int
SOIL_load_OGL_texture
(
const char *filename,
int force_channels,
unsigned int reuse_texture_ID,
unsigned int flags
);
unsigned int
SOIL_load_OGL_texture
(
const char *filename,
int force_channels,
unsigned int reuse_texture_ID,
unsigned int flags,
unsigned int cubemapflag
);


that can work either this way

SOIL_load_OGL_texture
(
"img.png",
SOIL_LOAD_AUTO,
SOIL_CREATE_NEW_ID,
SOIL_FLAG_MIPMAPS | SOIL_FLAG_INVERT_Y | SOIL_FLAG_COMPRESS_TO_DXT
);


or this way

SOIL_load_OGL_texture
(
"img.png",
SOIL_LOAD_AUTO,
SOIL_CREATE_NEW_ID,
SOIL_FLAG_MIPMAPS | SOIL_FLAG_INVERT_Y | SOIL_FLAG_COMPRESS_TO_DXT, SOIL_FLAG_SPLIT_CUBEMAPS
);



so you have one function 'name' only that can work ordinarily without specifying the flag or using the cubemap if the last parameter is added
similarly you can make 2 versions of the soil load ogl cube map function

unsigned int
SOIL_load_OGL_cubemap
(
const char *x_pos_file,
const char *x_neg_file,
const char *y_pos_file,
const char *y_neg_file,
const char *z_pos_file,
const char *z_neg_file,
int force_channels,
unsigned int reuse_texture_ID,
unsigned int flags
);
unsigned int
SOIL_load_OGL_cubemap
(
const char *filename,
int force_channels,
unsigned int reuse_texture_ID,
unsigned int flags
);


and you have two different definitions of the function, the one with one char* prameter only will have to be split.
hope its clear

forest

#25 Martins Mozeiko   Crossbones+   -  Reputation: 1422

Like
0Likes
Like

Posted 25 August 2007 - 07:30 AM

ForestMaster: I think author is making SOIL as C not C++ library. So function overloading is not available.

#26 ForestMaster   Members   -  Reputation: 164

Like
0Likes
Like

Posted 25 August 2007 - 09:24 AM

Quote:
Original post by bubu LV
ForestMaster: I think author is making SOIL as C not C++ library. So function overloading is not available.


oh what a pity :D in this case id vote for the separate function

#27 DeathCarrot   Members   -  Reputation: 188

Like
0Likes
Like

Posted 28 August 2007 - 09:36 PM

How much work do you think it would be to add functions for loading images from raw data?

I'm asking as I'm implementing my game's data file access using physfs, which means I need to extract the file's raw data into a char[] before I can do anything with it. I know stb_image has functions for loading from data, but it looks like SOIL keeps the filename around through most of the process.
I'll have a look to see if I can find an easy way to abstract the back end from whether the input type, but I'm doubting it's going to be trivial.

Thanks.

EDIT: I guess I could just use stb_image myself to convert the image data and then call SOIL_create_OGL_texture =)

[Edited by - DeathCarrot on August 29, 2007 5:36:49 AM]

#28 lonesock   Members   -  Reputation: 803

Like
0Likes
Like

Posted 29 August 2007 - 03:19 AM

Quote:
Original post by DeathCarrot
How much work do you think it would be to add functions for loading images from raw data?
...I guess I could just use stb_image myself to convert the image data and then call SOIL_create_OGL_texture =)

That works [8^)

Also, the newest version of stb_image allows you to register your own file-loader. If you can wait till this weekend I should be able to upgrade SOIL by then to use the newest version, and the DDS loader will be implemented using that interface, so there should be a decent bit of example code.

In other news, the single file to cubemap function is almost done...I just need to read DDS cubemaps...so that should be out this weekend too (thanks for casting the deciding vote, ForestMaster ;-)


#29 lonesock   Members   -  Reputation: 803

Like
0Likes
Like

Posted 01 September 2007 - 09:29 AM

SOIL can now load cubemaps from a single image file, either a DDS cubemap or any other image type with the six cube faces stitched together. It can now handle uncompressed DDS files too.

Sorry to anyone who downloaded SOIL between yesterday afternoon and now, I had a temp version up with some bugs, fixed now.

I really appreciate everyone who has tested SOIL, thanks for trying it out. Has anyone tried compiling SOIL under OS X?

#30 shotgunnutter   Banned   -  Reputation: 102

Like
0Likes
Like

Posted 02 September 2007 - 02:36 PM

Quote:
Original post by lonesock
SOIL can now load cubemaps from a single image file, either a DDS cubemap or any other image type with the six cube faces stitched together. It can now handle uncompressed DDS files too.

Sorry to anyone who downloaded SOIL between yesterday afternoon and now, I had a temp version up with some bugs, fixed now.

I really appreciate everyone who has tested SOIL, thanks for trying it out. Has anyone tried compiling SOIL under OS X?


HI,

I've got SOIL compiling under OS X on gcc 4.2. I'm going to test the different file format loaders, and will probably use calls to these functions in my resource loader library.

Many thanks for an excellent library.






#31 lonesock   Members   -  Reputation: 803

Like
0Likes
Like

Posted 02 September 2007 - 07:07 PM

Quote:
Original post by shotgunnutter
I've got SOIL compiling under OS X on gcc 4.2. I'm going to test the different file format loaders, and will probably use calls to these functions in my resource loader library.

Great, thanks! I have 0 access to any Mac machines, so thanks for verifying it at least compiles [8^)

Quote:
Original post by shotgunnutter
Many thanks for an excellent library.

You're welcome! Feel free to hit me with any suggestions or requests for making it better.

#32 cow_in_the_well   GDNet+   -  Reputation: 622

Like
0Likes
Like

Posted 02 September 2007 - 07:36 PM

Looks like a very interesting library, I'll have to try it out when I get home :). D3DX-esque texture loading for OpenGL, yay!

I, too, am using PhysFS, so being able to load from a custom file source would be great. :)

Good work.
- Thomas Cowellwebsite | journal | engine video

#33 lonesock   Members   -  Reputation: 803

Like
0Likes
Like

Posted 03 September 2007 - 04:37 AM

Quote:
Original post by DeathCarrot
How much work do you think it would be to add functions for loading images from raw data?

Quote:
Original post by cow_in_the_well
I, too, am using PhysFS, so being able to load from a custom file source would be great. :)

Ah, sorry I misunderstood you earlier, DeathCarrot. As you saw, stb_image already supports decoding images from a block of RAM, so this feature will not be too hard to implement. I'll add in the interface to decompress images from memory as I upgrade to stb_image 0.98, so expect the next SOIL release in a few days.

Thanks so much for your feedback!

#34 shotgunnutter   Banned   -  Reputation: 102

Like
0Likes
Like

Posted 05 September 2007 - 04:31 PM

Quote:
Original post by lonesock
Quote:
Original post by shotgunnutter
I've got SOIL compiling under OS X on gcc 4.2. I'm going to test the different file format loaders, and will probably use calls to these functions in my resource loader library.

Great, thanks! I have 0 access to any Mac machines, so thanks for verifying it at least compiles [8^)

Quote:
Original post by shotgunnutter
Many thanks for an excellent library.

You're welcome! Feel free to hit me with any suggestions or requests for making it better.


Your library is so easy to use that I would like to rate you up again, if only I hadn't done so twice already.

Ok, initial tests on my MBP running OS X 10.4.10, and gcc 4.0.2 are successful. I can load .tga files, and .bmp files. I haven't yet tested screen shots, I'll do that next.

Here is an OS generated screen shot from my quake 3 clone:



























OK, I cheated. Here is what I actually managed to do:



I'm writing my own renderer; My code at the moment is the result of a year of reading tutorials and copy / pasting code from examples on the web. The class which handles the MD2 character also renders him. Thanks to your library, I can now design a better system far more quickly.


I did have to make a change to the compiler macros in soil.c, to ensure platform cross- compatibility:

in soil.c, where you have

#ifdef _MSC_VER
#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#endif

#include "SOIL.h"
#include "stb_image.h"
#include "image_helper.h"

#include <stdlib.h>
#include <string.h>
#include <GL/gl.h>

// for using DXT compression
#define SOIL_RGB_S3TC_DXT1_EXT 0x83F0
#define SOIL_RGBA_S3TC_DXT1_EXT 0x83F1
#define SOIL_RGBA_S3TC_DXT3_EXT 0x83F2
#define SOIL_RGBA_S3TC_DXT5_EXT 0x83F3







i changed this to


#ifdef _MSC_VER

#define WIN32_LEAN_AND_MEAN
#include <windows.h>
#include <GL/gl.h>
#else
#include <OpenGL/gl.h>
#include <OpenGL/glu.h>
#endif

#include "SOIL.h"
#include "stb_image.h"
#include "image_helper.h"
#include <stdlib.h>
#include <string.h>

// for using DXT compression

#define SOIL_RGB_S3TC_DXT1_EXT 0x83F0
#define SOIL_RGBA_S3TC_DXT1_EXT 0x83F1
#define SOIL_RGBA_S3TC_DXT3_EXT 0x83F2
#define SOIL_RGBA_S3TC_DXT5_EXT 0x83F3







This will allow the code to compile on gcc 4.0.2 and on MSC. I haven't tested it on a Linux system but the headers are the same as for OS X.

[update: png files work. Alpha transparency on .tga and .png also works]

[Edited by - shotgunnutter on September 5, 2007 11:31:27 PM]

#35 RSC_x   Banned   -  Reputation: 100

Like
0Likes
Like

Posted 06 September 2007 - 03:17 AM

hey good library but i was solwed image loading problem.
so we need a 3d image loader like 3ds or any other.

can you do that.
but anyway i dont need it but dds support is good.
i can use your source for this.
but i like open source things.

© Loading... !!!
Please Wait...!

#36 shotgunnutter   Banned   -  Reputation: 102

Like
0Likes
Like

Posted 06 September 2007 - 04:07 AM

Quote:
Original post by RSC_x
hey good library but i was solwed image loading problem.
so we need a 3d image loader like 3ds or any other.

can you do that.
but anyway i dont need it but dds support is good.
i can use your source for this.
but i like open source things.


Why not write your own?

#37 lonesock   Members   -  Reputation: 803

Like
0Likes
Like

Posted 06 September 2007 - 08:40 AM

Hi, All.

SOIL has 2 updates:
* it can now handle some non-compliant DDS files (which did not specify a pitch or linear size)
* it can now decompress images from memory for you PhysicsFS users (note, this is mostly untested, especially the DDS direct upload version...I'd really appreciate any feedback!)

@shotgunnutter: Thanks for the heads-up regarding the includes. I think the includes you mentioned were from a previous version, would you mind testing the latest version? If there are still issues I'd be happy to make changes [8^)

@RSC_x: I'm not sure I understood. Are you requesting that SOIL be able to load DDS files with 3D (volume) textures in them? Or are you looking for some mesh-loading libraries with licenses similar to Public Domain? (if so, there are many libraries out there, like Trimeshloader...I recommend checking this list as a first step).

#38 shotgunnutter   Banned   -  Reputation: 102

Like
0Likes
Like

Posted 06 September 2007 - 12:52 PM

Quote:
Original post by lonesock

@RSC_x: I'm not sure I understood. Are you requesting that SOIL be able to load DDS files with 3D (volume) textures in them? Or are you looking for some mesh-loading libraries with licenses similar to Public Domain? (if so, there are many libraries out there, like Trimeshloader...I recommend checking this list as a first step).


Nobody except me and a few other people understand RSC_x. he was asking you could write him a loader for a 3d model format, and gave .3ds as an example.
I told him to write his own.


#39 lonesock   Members   -  Reputation: 803

Like
0Likes
Like

Posted 11 September 2007 - 11:26 AM

@shotgunnutter: Thanks for the clarification. Quick question, did the new includes work for you on your various platforms?

Has anybody tried SOIL with PhysicsFS? I'd like to verify that it works, or fix it in the other case [8^)

#40 Davian_   Members   -  Reputation: 163

Like
0Likes
Like

Posted 11 September 2007 - 05:34 PM

Hi. The library is looking good so far. Thanks!

I'm having a small problem, though, and I was hoping you could point me in the right direction. I'm using VS.NET 2003, have the project linked to libSOIL.a, and the file in question includes SOIL.h. When I build the project, the following linker error comes up:

error LNK2019: unresolved external symbol _sqrtf referenced in function _compute_color_line_STDEV

The error goes away when I comment out the SOIL_load_OGL_texture_from_memory line. Are there any other libraries I need to link to or settings I need to change to get it working? The code for the function in question is below.

Thanks a lot!

const unsigned int getTexture(string fileName) {
PHYSFS_File* filePtr;
int fileLength;
unsigned char* imageData;
unsigned int textureID;
map<unsigned int, PNTexture>::iterator textureIter;

textureIter = loadedTextures.begin();
while (textureIter->second.fileName != fileName) {
textureIter++;
}

if (textureIter != loadedTextures.end()) {
textureIter->second.refCount++;
textureID = textureIter->first;
}
else {
filePtr = PHYSFS_openRead(fileName.c_str());
fileLength = PHYSFS_fileLength(filePtr);
PHYSFS_read(filePtr, imageData, 1, fileLength);

textureID = SOIL_load_OGL_texture_from_memory(imageData, fileLength, 0, 0, NULL);
if (textureID > 0) {
loadedTextures[textureID].fileName = fileName;
loadedTextures[textureID].width = 320; //TODO: Read the dimensions from the data file, along with the
loadedTextures[textureID].height = 320; //texture coordinates for each tile
loadedTextures[textureID].refCount = 1;
}
PHYSFS_close(filePtr);
}

return textureID;
}





Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS