02-12-2023, 01:45 PM
(This post was last modified: 02-12-2023, 02:27 PM by Kain Nobel.)
Confession : I use semi-automated systems to generate graphics, dubbed KAD; Kain Assisted Drafting.
I do not consider this "AI" but it does utilize some machine learning. Also, it does more work than I do (at this point in time.)
Most screenshots posted after 2012 have utilized this system to assist in the design of tilesets (and other miscellaneous resources). Not all, but most. I use it more frequently than I use GraphicsGale. To be fair, most of that use is in perfecting the system and experimentation, but yes, I do use it as much as I can. It was designed to draw like Kain.
Pictured : KAD assisted trees.
Left sample is hand drawn (trunk only), KAD drew all the leaves and applied all the proper shading in regards to foliage.
Right sample is 95% KAD generated tree, based on a rules file and machine interpreted photographic tree foliage.
(Please note that not all samples wind up turning out this good; they usually need some sort of last minute touch up. These two samples are the most successful / least intervention, as far as trees go.)
Pictured : KAD generated dirt, extracted and reinterpreted from a megapixel photograph. In theory, these should each be a 32x32 seamless tile. This is what the system thinks dirt looks like. After extracting photograph RGB data from a race track, this is how the system would draw the dirt from the race track. It interprets highlights and shadows and attempts to make as many seamless 32x32 tiles as it can muster up from the resampled photo.
The data is actually stored internally as a marshalled table of generic number values (short integers) but, if converted into a grayscale PNG format, this is essentially what the data would look like visually.
This is not the result of noise generation and there are thousands of these tiles embedded within the data suite for which the system can use to generate colorized textures.
The KAD TextureMate system is only designed to interpret and re-create the most primitive of textures; grass, dirt, cement, blacktop, sand, rock, roof shingles, clouds, etc. This aspect of the system is not designed for abstract objects such as cars, trucks, dogs, cats, basketballs, mailboxes, etc. However, if you decided to draw an animated kitty cat, you could probably tell the system to texturize it using "Grass" (and point it to the Siamese color profile) and I think it would look good (or it might look "noisy"...)
Let's generate something...
Pictured : KAD generated Cave sample. Please note that we're borrowing RMXP's Cave02 wall texture in this sample only because it is something familiar to everybody here; however, I don't typically use RMXP resources with these systems. It took 0.0134 seconds to generate 64000 individual tiles for a complete tileset. In other words, this tileset is a complete tileset (but I've cut it down to just a small sample for example's sake.)
The "Cave" recipes are fairly mature, so all I have to do is fill in some data and hit "compile and run". Other resource types aren't as mature, but they're still effective too.
Video : Project BEAST Nagivation Demo. Tilesets used in this demo are KAD generated tilesets. Also, texture mismatches in one of the maps is user error, not system error.
KAD TextureMate was very lightly used in the creation of these tilesets, but it does have the capability to extract, examine and reinterpret primitive textures from megapixel photographs such as the dirt posted above. Some of that dirt from the earlier sample may or may not be present in this demo.
Is it AI? No, not in it's current state. Is it machine learning? Yes, absolutely. Does it still require human input? For now, yes, but in the future it should require it less and less.
This system would never be able to replace a human designer, but it does automate a great chunk of work. It would probably be an 80/20 split insofar as it could generate 80% of the RMXP default set of tilesets on it's own with no human assistance, but the other 20% would be adding all the little doodads such as signs, mailboxes, fencing, special windows, etc. which would need a human designer.
That could change (and, in the case of fences, is changing.)
Pictured : Precursor to training KAD how to make RMXP style picket fencing. This sample is hand-drawn, not KAD generated. Once it is properly trained, it should be able to generate fences with minimal human intervention. Once I've done some brainstorming, this image will be used to guide in the making of a json KAD recipe file (fence.json).
This is not a new system. This predates ChatGPT, Dall E, StyleGAN, TensorFlow, Project BEAST, RPG Maker VX Ace and even the 1st attempt at REGAL (Qt era). The system was started as a JavaScript project written in IntelliJ IDEA, but is now being re-written to C++ OpenGL standards (with ImageMagick).
Current Capabilities
I don't consider it AI just as I don't consider RPG Maker's character generation suite to be AI. It is an automation tool and requires specialized training and plenty of image data. If I was to train it to draw fireworks, I would need to submit many stills from a video of fireworks in action. Maybe it could reverse engineer the animation of fireworks, maybe not. Haven't tried (yet) but I'm curious to see how well it would actually do. In the future, it may train on video, but it's only ever trained on still image photographs. As such, it can't interpret an animated GIF reliably or an MP4 or anything else but PNG and BMP (JPEG not recommended).
I have mixed feelings on AI, but I feel it would be way too risky to institute a ban on it. Policies like RPGMakerWeb are a slippery slope towards banning non-AI developments like this one. Systems like mine could be misconstrued and misinterpreted as AI, but it is not. Machine learning could be misconstrued and misinterpreted to be AI; again, it could be a component of AI, but it is not AI itself. Like a child, it needs training, supervision and intervention to be most effective.
(Much love to RPGMakerWeb, but I tend to disagree on certain things. I doth not protest though, let them institute whatever policy they feel they need to institute.)
However, once everything comes full circle, it designs very nice looking tilesets on par with what I would attempt to do by hand. Also, this is not intended to be part of the REGAL suite of software (but that may change as it becomes more mature.)
I never even intended to tell people about it but I figure it's time to come clean, especially now that AI is a mainstream topic. Special thanks to Poccil, Selwyn, and Raitame for early inspiration behind the system as they were experimenting with image manipulation via programming long before I ever attempted.
I do not consider this "AI" but it does utilize some machine learning. Also, it does more work than I do (at this point in time.)
Most screenshots posted after 2012 have utilized this system to assist in the design of tilesets (and other miscellaneous resources). Not all, but most. I use it more frequently than I use GraphicsGale. To be fair, most of that use is in perfecting the system and experimentation, but yes, I do use it as much as I can. It was designed to draw like Kain.
Pictured : KAD assisted trees.
Left sample is hand drawn (trunk only), KAD drew all the leaves and applied all the proper shading in regards to foliage.
Right sample is 95% KAD generated tree, based on a rules file and machine interpreted photographic tree foliage.
(Please note that not all samples wind up turning out this good; they usually need some sort of last minute touch up. These two samples are the most successful / least intervention, as far as trees go.)
Pictured : KAD generated dirt, extracted and reinterpreted from a megapixel photograph. In theory, these should each be a 32x32 seamless tile. This is what the system thinks dirt looks like. After extracting photograph RGB data from a race track, this is how the system would draw the dirt from the race track. It interprets highlights and shadows and attempts to make as many seamless 32x32 tiles as it can muster up from the resampled photo.
The data is actually stored internally as a marshalled table of generic number values (short integers) but, if converted into a grayscale PNG format, this is essentially what the data would look like visually.
This is not the result of noise generation and there are thousands of these tiles embedded within the data suite for which the system can use to generate colorized textures.
The KAD TextureMate system is only designed to interpret and re-create the most primitive of textures; grass, dirt, cement, blacktop, sand, rock, roof shingles, clouds, etc. This aspect of the system is not designed for abstract objects such as cars, trucks, dogs, cats, basketballs, mailboxes, etc. However, if you decided to draw an animated kitty cat, you could probably tell the system to texturize it using "Grass" (and point it to the Siamese color profile) and I think it would look good (or it might look "noisy"...)
Let's generate something...
Pictured : KAD generated Cave sample. Please note that we're borrowing RMXP's Cave02 wall texture in this sample only because it is something familiar to everybody here; however, I don't typically use RMXP resources with these systems. It took 0.0134 seconds to generate 64000 individual tiles for a complete tileset. In other words, this tileset is a complete tileset (but I've cut it down to just a small sample for example's sake.)
The "Cave" recipes are fairly mature, so all I have to do is fill in some data and hit "compile and run". Other resource types aren't as mature, but they're still effective too.
Video : Project BEAST Nagivation Demo. Tilesets used in this demo are KAD generated tilesets. Also, texture mismatches in one of the maps is user error, not system error.
KAD TextureMate was very lightly used in the creation of these tilesets, but it does have the capability to extract, examine and reinterpret primitive textures from megapixel photographs such as the dirt posted above. Some of that dirt from the earlier sample may or may not be present in this demo.
Is it AI? No, not in it's current state. Is it machine learning? Yes, absolutely. Does it still require human input? For now, yes, but in the future it should require it less and less.
This system would never be able to replace a human designer, but it does automate a great chunk of work. It would probably be an 80/20 split insofar as it could generate 80% of the RMXP default set of tilesets on it's own with no human assistance, but the other 20% would be adding all the little doodads such as signs, mailboxes, fencing, special windows, etc. which would need a human designer.
That could change (and, in the case of fences, is changing.)
Pictured : Precursor to training KAD how to make RMXP style picket fencing. This sample is hand-drawn, not KAD generated. Once it is properly trained, it should be able to generate fences with minimal human intervention. Once I've done some brainstorming, this image will be used to guide in the making of a json KAD recipe file (fence.json).
This is not a new system. This predates ChatGPT, Dall E, StyleGAN, TensorFlow, Project BEAST, RPG Maker VX Ace and even the 1st attempt at REGAL (Qt era). The system was started as a JavaScript project written in IntelliJ IDEA, but is now being re-written to C++ OpenGL standards (with ImageMagick).
Current Capabilities
- Examine and reinterpret texture profile chunks from megapixel photographs.
- Colorize learned texture styles based on user defined limited color palette profiles.
- Can generate animated water tiles (unreliable, I still recommend hand-drawn. Sometimes does well though.)
- Generates cave / mountain tilesets (very mature.)
- Generates house exterior tilesets (semi-mature.)
- Generates house interior tilesets (feature is currently in development / largely undefined.)
- Generates trees, bushes and foliage (experimental.)
- Generates targeted particle effects (such as the flames in the Belly of the Beast title screen. Experimental.)
- Generates prefabricated light and shadow effects (experimental.)
I don't consider it AI just as I don't consider RPG Maker's character generation suite to be AI. It is an automation tool and requires specialized training and plenty of image data. If I was to train it to draw fireworks, I would need to submit many stills from a video of fireworks in action. Maybe it could reverse engineer the animation of fireworks, maybe not. Haven't tried (yet) but I'm curious to see how well it would actually do. In the future, it may train on video, but it's only ever trained on still image photographs. As such, it can't interpret an animated GIF reliably or an MP4 or anything else but PNG and BMP (JPEG not recommended).
I have mixed feelings on AI, but I feel it would be way too risky to institute a ban on it. Policies like RPGMakerWeb are a slippery slope towards banning non-AI developments like this one. Systems like mine could be misconstrued and misinterpreted as AI, but it is not. Machine learning could be misconstrued and misinterpreted to be AI; again, it could be a component of AI, but it is not AI itself. Like a child, it needs training, supervision and intervention to be most effective.
(Much love to RPGMakerWeb, but I tend to disagree on certain things. I doth not protest though, let them institute whatever policy they feel they need to institute.)
However, once everything comes full circle, it designs very nice looking tilesets on par with what I would attempt to do by hand. Also, this is not intended to be part of the REGAL suite of software (but that may change as it becomes more mature.)
I never even intended to tell people about it but I figure it's time to come clean, especially now that AI is a mainstream topic. Special thanks to Poccil, Selwyn, and Raitame for early inspiration behind the system as they were experimenting with image manipulation via programming long before I ever attempted.