Hi all,
I'm in the process of creating a procedural texture generator, based on Irrlicht, for a small game that I'm slowly developing.
The idea is you basically string together various building blocks, like noise functions, blend function, etc to create the texture. That is then exported to an XML file which is used by the game to re-build the texture at load-time at whatever resolution it needs.
It saves having to bundle a lot of large texture files with the game. An example I had was a 1Mb 2048x2048 PNG texture file vs a <1Kb XML file to create the same texture.
It's still very much a work in progress but I'd thought I'd announce it here if anyone is interested.
My blog for it is here: http://sourceforge.net/apps/wordpress/blockplanet/ (BlockPlanet is the game I'm working on although most of my time at the moment is on TexGen).
And the downloads are here: http://sourceforge.net/projects/blockpl ... Gen/Alpha/
Readme included in the zip file contains brief instructions on how to use the editor.
Visual C++ 2010 runtimes are needed for the Windows version.
There is also a Linux binary that I managed to get working only 2 hours ago on my Linux Virtual PC. First time I ever tried any of my projects on Linux. Not tested on any other PC so not sure if it works... (I'm a linux noob, so not really sure what I'm doing )
Source is also available via the SourceForge CVS if anyone wants to take a look at it. (beware, it's messy)
TexGen: A Procedural texture generator
-
- Posts: 3
- Joined: Wed May 19, 2010 10:18 pm
- Contact:
-
- Admin
- Posts: 14143
- Joined: Wed Apr 19, 2006 9:20 pm
- Location: Oldenburg(Oldb), Germany
- Contact:
Texture manipulators (as the super class of texture generators) are also one of my larger TODO topics that I always wanted to work on once I have some more time. I've spend some time already to think about proper interfaces. So I was keen to look into yours.
I like the process chains you can built with your interface. This offers a great flexibility. I guess some convenience methods (such as refresh() instead of !isProcessed()&&process() ) would make the code even cleaner. But besides that it should fulfill most things one needs to do.
The parameter handling is a little strange, though. Doing it all via C-arrays and new/delete is a bit old fashioned and definitely harder to use than going via an irrArray with input parameters or output images. Moreover, it could be necessary to not only create output images, but also reuse existing ones.
So please keep us informed, and maybe let your design decisions guide by the face that we'd like to integrate this factory into the engine at some point
I like the process chains you can built with your interface. This offers a great flexibility. I guess some convenience methods (such as refresh() instead of !isProcessed()&&process() ) would make the code even cleaner. But besides that it should fulfill most things one needs to do.
The parameter handling is a little strange, though. Doing it all via C-arrays and new/delete is a bit old fashioned and definitely harder to use than going via an irrArray with input parameters or output images. Moreover, it could be necessary to not only create output images, but also reuse existing ones.
So please keep us informed, and maybe let your design decisions guide by the face that we'd like to integrate this factory into the engine at some point
-
- Posts: 3
- Joined: Wed May 19, 2010 10:18 pm
- Contact:
Thanks for your comments.
I like the idea of the refresh() function, I'll look into doing that tonight if I get the chance.
I want to go over a lot of the code again and clean it up sometime soon. Some of the code in there was written in a hurry early on when I just wanted to get it working. The input and output parameters will be one of the things I clean up.
With reusing existing images, do you mean, taking an existing image and running it through the process to manipulate it? I think that should be farly simple to implement. I just need to create a new element that loads the existing image and sets it as it's output.
One thing I'm not sure on is what I should refer to the individual "building blocks" as. I mean at the moment I refer to them as "Image Processes" in the TextureFactory class and "Devices" in the editor itself. To make things clear I think I need to give them a single name like "Elements" or something.
I like the idea of the refresh() function, I'll look into doing that tonight if I get the chance.
I want to go over a lot of the code again and clean it up sometime soon. Some of the code in there was written in a hurry early on when I just wanted to get it working. The input and output parameters will be one of the things I clean up.
With reusing existing images, do you mean, taking an existing image and running it through the process to manipulate it? I think that should be farly simple to implement. I just need to create a new element that loads the existing image and sets it as it's output.
One thing I'm not sure on is what I should refer to the individual "building blocks" as. I mean at the moment I refer to them as "Image Processes" in the TextureFactory class and "Devices" in the editor itself. To make things clear I think I need to give them a single name like "Elements" or something.
-
- Posts: 3
- Joined: Wed May 19, 2010 10:18 pm
- Contact:
Thought I'd post a quick update.
I've updated TexGen quite a bit since I first posted here. There's a lot of new elements to use in creating a texture like an RGB channel splitter, a filter element and pixel point field.
I've still got to work on implementing an image loading element. I need to decide whether it should be the actual texture script itself that has the name of the existing image built into it or if it should be somehow specified as an input for the texture script before it's run. I've also got to sort out if and how the image should be resized depending upon the requested texture size.
Code wise I've moved over to a class factory design to make it easier to create new elements, there's less editing of the actual texture factory class when adding new elements. There's still some work I need to do on this but it's working well.
Other things: I've abstracted the CTextureFactory class out into an ITextureFactory interface class, implemented the much simpler Refresh() function as suggested and generally cleaned up and documented the code a bit.
Here's some images I made with the generator so far (click for bigger images):
I've updated TexGen quite a bit since I first posted here. There's a lot of new elements to use in creating a texture like an RGB channel splitter, a filter element and pixel point field.
I've still got to work on implementing an image loading element. I need to decide whether it should be the actual texture script itself that has the name of the existing image built into it or if it should be somehow specified as an input for the texture script before it's run. I've also got to sort out if and how the image should be resized depending upon the requested texture size.
Code wise I've moved over to a class factory design to make it easier to create new elements, there's less editing of the actual texture factory class when adding new elements. There's still some work I need to do on this but it's working well.
Other things: I've abstracted the CTextureFactory class out into an ITextureFactory interface class, implemented the much simpler Refresh() function as suggested and generally cleaned up and documented the code a bit.
Here's some images I made with the generator so far (click for bigger images):