While i would love being able to have a custom texture pack able to make/save my own blocks pixel by pixel....
Seems like its reaching too far. However they could easily do a all texture pack where you can use any block from any existing texture pack at any time in creative. Sure would be nice to have 5 or more diff types of wooden doors to choose from when doing city builds. Hell i would pay 20 bucks for this option with no hesitation.
the more I research it, the more I am concerned that Minecraft is not using shared textures, at least in the xbox version.
Shared textures means that placing 1 or 10 million of the same block uses the same amount of RAM, making it possible to make larger and more vibrant worlds with ease. It would make a custom texture pack, or better yet all texture packs combined easily possible, and at the same time make the worlds load and run faster with consistently less lag.
I have experience with this creating custom assets in a very similar game, Roller Coaster Tycoon 3. Users could (still can) create their own models in google sketchup and import them into the game, in most cases the new assets (if using shared textures) were actually less resource intensive than the original art assets created by the game developer.
I am interested in finding out more about this to see if amateurs such as myself could push a movement to help MC get not only shared textures, but some of these giant texture packs containing all objects from all textures packs in one giant one to rule them all. It is not only possible, it is actually somewhat concerning that it is not already this way. It should already be like this.
As said, I already have experience with this if anyone would like to discuss it in further detail.
It's an interesting idea that is similar to the Mix 'N Match TP ideas that have been thrown around recently... but I do see some challenges to this, just to highlight a few:
Currently each Block ID is mapped to 1 and only 1 texture set. By changing out the TP that is being used, this changes the core graphics used for all blocks that share that Block ID type.
To implement this suggestion, it would require each block ID to be assigned a different Texture individually (or it would have to be tabularly tracked, or by generating new distinct block ID's or sub ID's for each distinct texture used.)
This is the easier part... the harder part that I see comes in 4 parts:
Building the User Interface to allow the end user/player to be able to selectively choose between one block and the next in both Creative and in Survival modes.
How would this variance be handled in World Generation to incorporate all these textures?
How would this system handle changing textures (one block at a time only, en mass somehow)?
What sort of lag would this additional processing cause in the game due to video rendering, and how will that be overcome?
Otherwise, the basic idea of more texture options available for the same blocks for building appeals to me.
I think using a 6 face Block Sub-ID system would be optimal for this idea as it would allow for different textures for each face of the block, and would open the door to allow for upgrades to allow for concepts like Painting the Face of a Block a different color than the rest.
Yes, having each block ID be assigned a different texture individually is what I would have in mind. Original Grass, Natural Grass, City Grass etc. The point I was curious about is for each unique block ID placing 1 or millions of those blocks should in theory take the same amount of graphical power, if it is using shared textures.
1) I would still have it remain the same in Survival, pick one texture pack perhaps make an interface (via main menu) to make a custom one, but multiple instances of the same blocks is not the point of Survival. That is what Creative is for, and an updated user interface and renaming and copying variables would be most of the work in that regard.
2) Keep it the same as it already is. Pick one texture pack for the world generation, then you are free to build from there.
3) Not sure exactly what you mean, if by loading the textures themselves, yes you do that upon map initialization, most games are like that. It could possibly increase load/save times but that would likely be the only consequence. If you mean by loading chunks as you explore, I am unfamiliar with those processes, and if you mean as in grass blocks and other blocks that can change it would likely be one of the tougher challenges I can think of, but I think people smarter than me could figure it out.
4) Well, if the game is currently not using shared textures (a theory I am unsure of), and then everything was converted to shared textures, if would actually render much much faster.
Even easier than using a 6 face block id would be just to add a recolorable flat object, similar to carpet, except it could be put on the side of blocks or underneath. The concept is already well established in Roller Coaster Tycoon 3 with custom path covers, even adding curves of varying degrees (using opacity to mask the object, making only parts of it visible, though it still renders as a square), diagonals, half, and quarter blocks and every single object within a pack can use the same singular texture. The individual packs of these can contain a wide array of textures, and entirely new packs can be made by just swapping the texture file and the links in the models. Something like this can be done with a 1 dimension model making it very resource friendly.
3) Not sure exactly what you mean, if by loading the textures themselves, yes you do that upon map initialization, most games are like that. It could possibly increase load/save times but that would likely be the only consequence. If you mean by loading chunks as you explore, I am unfamiliar with those processes, and if you mean as in grass blocks and other blocks that can change it would likely be one of the tougher challenges I can think of, but I think people smarter than me could figure it out.
#3 was from the Player/UI perspective, what design mechanisms would be in place to make it simple and easy to use for the end user if they wanted to change block textures after the world was generated?
Even easier than using a 6 face block id would be just to add a recolorable flat object, similar to carpet, except it could be put on the side of blocks or underneath. The concept is already well established in Roller Coaster Tycoon 3 with custom path covers, even adding curves of varying degrees (using opacity to mask the object, making only parts of it visible, though it still renders as a square), diagonals, half, and quarter blocks and every single object within a pack can use the same singular texture. The individual packs of these can contain a wide array of textures, and entirely new packs can be made by just swapping the texture file and the links in the models. Something like this can be done with a 1 dimension model making it very resource friendly.
Carpet is registered as a separate Block ID that is occupying the block space above the block that it is set on top of (like redstone dust), which precludes anything else in sharing the same block space (like a fence post or the threshold of a door, or a fence gate, or a torch, etc).
If a Flat Block is used for a painted surface, 'like carpet', then there are issues where wall paint meets floor carpet when both of these blocks would need to occupy the same block space in order to look right, or when trying to hang a torch off a painted wall...etc.
The biggest challenge is creating the UI to be able to select which textures to use. The simplest (and I use the word lightly) is to have the UI "off-world", as part of the title screen options. The interface will allow the user/player to select textures from their purchased texture packs and then save the configuration as a new (possibly nameable) TP, which will show up as a selection when loading a world. The game will only choose textures from that pack, exactly how it does now. In layman's terms, think of a world like a color-by-number picture with each block as a wire frame with the Block ID number floating within it. When a TP is selected that number is replaced by whatever image is assigned to it.
I don't think being able to change textures "on-the-fly" from within a world is even an option. We don't even have the option to change TPs without exiting the map first. As a matter of fact, the PC doesn't even let you change textures "on-the-fly". At least not en mass, where every block of that ID changes.
#3 was from the Player/UI perspective, what design mechanisms would be in place to make it simple and easy to use for the end user if they wanted to change block textures after the world was generated?
It would certainly be a challenge. Perhaps have any blocks that were part of the world generation have a flag so that when you for example selected a different texture pack, all of those blocks that were flagged for being part of world generation would be the only ones that change. As Deskepticon mentioned, this would only happen at the main menu prior to loading up the world.
Carpet is registered as a separate Block ID that is occupying the block space above the block that it is set on top of (like redstone dust), which precludes anything else in sharing the same block space (like a fence post or the threshold of a door, or a fence gate, or a torch, etc).
If a Flat Block is used for a painted surface, 'like carpet', then there are issues where wall paint meets floor carpet when both of these blocks would need to occupy the same block space in order to look right, or when trying to hang a torch off a painted wall...etc.
Ah, I forgot about that. That is where RCT3 and MC differ. Objects in MC collide. They cannot occupy the same space. This is how all of the original art assets were from RCT3 as well. Modders and Custom scenery makers were able to overcome that by making the objects not collide, where multiple objects can actually occupy the same space. It could possibly require an addition flag, but that is a relatively simple fix for a major developer.
This could be done easily, for purely decorative objects such as carpet. I would not recommend doing so for normal blocks however.
Ah, I forgot about that. That is where RCT3 and MC differ. Objects in MC collide. They cannot occupy the same space. This is how all of the original art assets were from RCT3 as well. Modders and Custom scenery makers were able to overcome that by making the objects not collide, where multiple objects can actually occupy the same space. It could possibly require an addition flag, but that is a relatively simple fix for a major developer.
This could be done easily, for purely decorative objects such as carpet. I would not recommend doing so for normal blocks however.
That's why I brought up tracking the face of all six sides of a block separately.
That way you could 'overwrite' any surface with a 'surface treatment' that could exists between blocks, but I suppose the default state would have to be tracked as well (in case the surface treatment was removed and it had to revert back to it's original state.
It doesn't allow multiple flat surface treatments to occupy the same space, but I don't think there is any real value/point to having multiple surfaces occupy the same surface space as it is.
But it does open up a new way to look at applying surfaces such as redstone dust, carpet, paint (if implemented), snow, etc. This can then be applied to irregular shapes (top of fence posts, half slabs, top of stairs, top of the block underneath a fence post, etc.)
bah it could be done, we put a dummy on the moon in the sixties....
I want fully rotatable blocks too, stained glass, stained wood, npc pathing, writable chat bubbles for making quests in game, music options for default music other than being on a TP, wires, and while we are at it lets put in the ability to make entire selectable builds such as boats or airships to where we can set pathing for them as well. And an engine block or something that lets rotation of block sets attached to it spin (ie propllers, windmills, waterwheels.....get busy programmers and shut up and take my money! I want it!
bah it could be done, we put a dummy on the moon in the sixties....
I want fully rotatable blocks too, stained glass, stained wood, npc pathing, writable chat bubbles for making quests in game, music options for default music other than being on a TP, wires, and while we are at it lets put in the ability to make entire selectable builds such as boats or airships to where we can set pathing for them as well. And an engine block or something that lets rotation of block sets attached to it spin (ie propllers, windmills, waterwheels.....get busy programmers and shut up and take my money! I want it!
Seems like its reaching too far. However they could easily do a all texture pack where you can use any block from any existing texture pack at any time in creative. Sure would be nice to have 5 or more diff types of wooden doors to choose from when doing city builds. Hell i would pay 20 bucks for this option with no hesitation.
Shared textures means that placing 1 or 10 million of the same block uses the same amount of RAM, making it possible to make larger and more vibrant worlds with ease. It would make a custom texture pack, or better yet all texture packs combined easily possible, and at the same time make the worlds load and run faster with consistently less lag.
I have experience with this creating custom assets in a very similar game, Roller Coaster Tycoon 3. Users could (still can) create their own models in google sketchup and import them into the game, in most cases the new assets (if using shared textures) were actually less resource intensive than the original art assets created by the game developer.
I am interested in finding out more about this to see if amateurs such as myself could push a movement to help MC get not only shared textures, but some of these giant texture packs containing all objects from all textures packs in one giant one to rule them all. It is not only possible, it is actually somewhat concerning that it is not already this way. It should already be like this.
As said, I already have experience with this if anyone would like to discuss it in further detail.
Currently each Block ID is mapped to 1 and only 1 texture set. By changing out the TP that is being used, this changes the core graphics used for all blocks that share that Block ID type.
To implement this suggestion, it would require each block ID to be assigned a different Texture individually (or it would have to be tabularly tracked, or by generating new distinct block ID's or sub ID's for each distinct texture used.)
This is the easier part... the harder part that I see comes in 4 parts:
- Building the User Interface to allow the end user/player to be able to selectively choose between one block and the next in both Creative and in Survival modes.
- How would this variance be handled in World Generation to incorporate all these textures?
- How would this system handle changing textures (one block at a time only, en mass somehow)?
- What sort of lag would this additional processing cause in the game due to video rendering, and how will that be overcome?
Otherwise, the basic idea of more texture options available for the same blocks for building appeals to me.I think using a 6 face Block Sub-ID system would be optimal for this idea as it would allow for different textures for each face of the block, and would open the door to allow for upgrades to allow for concepts like Painting the Face of a Block a different color than the rest.
1) I would still have it remain the same in Survival, pick one texture pack perhaps make an interface (via main menu) to make a custom one, but multiple instances of the same blocks is not the point of Survival. That is what Creative is for, and an updated user interface and renaming and copying variables would be most of the work in that regard.
2) Keep it the same as it already is. Pick one texture pack for the world generation, then you are free to build from there.
3) Not sure exactly what you mean, if by loading the textures themselves, yes you do that upon map initialization, most games are like that. It could possibly increase load/save times but that would likely be the only consequence. If you mean by loading chunks as you explore, I am unfamiliar with those processes, and if you mean as in grass blocks and other blocks that can change it would likely be one of the tougher challenges I can think of, but I think people smarter than me could figure it out.
4) Well, if the game is currently not using shared textures (a theory I am unsure of), and then everything was converted to shared textures, if would actually render much much faster.
Even easier than using a 6 face block id would be just to add a recolorable flat object, similar to carpet, except it could be put on the side of blocks or underneath. The concept is already well established in Roller Coaster Tycoon 3 with custom path covers, even adding curves of varying degrees (using opacity to mask the object, making only parts of it visible, though it still renders as a square), diagonals, half, and quarter blocks and every single object within a pack can use the same singular texture. The individual packs of these can contain a wide array of textures, and entirely new packs can be made by just swapping the texture file and the links in the models. Something like this can be done with a 1 dimension model making it very resource friendly.
#3 was from the Player/UI perspective, what design mechanisms would be in place to make it simple and easy to use for the end user if they wanted to change block textures after the world was generated?
Carpet is registered as a separate Block ID that is occupying the block space above the block that it is set on top of (like redstone dust), which precludes anything else in sharing the same block space (like a fence post or the threshold of a door, or a fence gate, or a torch, etc).
If a Flat Block is used for a painted surface, 'like carpet', then there are issues where wall paint meets floor carpet when both of these blocks would need to occupy the same block space in order to look right, or when trying to hang a torch off a painted wall...etc.
The biggest challenge is creating the UI to be able to select which textures to use. The simplest (and I use the word lightly) is to have the UI "off-world", as part of the title screen options. The interface will allow the user/player to select textures from their purchased texture packs and then save the configuration as a new (possibly nameable) TP, which will show up as a selection when loading a world. The game will only choose textures from that pack, exactly how it does now. In layman's terms, think of a world like a color-by-number picture with each block as a wire frame with the Block ID number floating within it. When a TP is selected that number is replaced by whatever image is assigned to it.
I don't think being able to change textures "on-the-fly" from within a world is even an option. We don't even have the option to change TPs without exiting the map first. As a matter of fact, the PC doesn't even let you change textures "on-the-fly". At least not en mass, where every block of that ID changes.
It would certainly be a challenge. Perhaps have any blocks that were part of the world generation have a flag so that when you for example selected a different texture pack, all of those blocks that were flagged for being part of world generation would be the only ones that change. As Deskepticon mentioned, this would only happen at the main menu prior to loading up the world.
Ah, I forgot about that. That is where RCT3 and MC differ. Objects in MC collide. They cannot occupy the same space. This is how all of the original art assets were from RCT3 as well. Modders and Custom scenery makers were able to overcome that by making the objects not collide, where multiple objects can actually occupy the same space. It could possibly require an addition flag, but that is a relatively simple fix for a major developer.
This could be done easily, for purely decorative objects such as carpet. I would not recommend doing so for normal blocks however.
That's why I brought up tracking the face of all six sides of a block separately.
That way you could 'overwrite' any surface with a 'surface treatment' that could exists between blocks, but I suppose the default state would have to be tracked as well (in case the surface treatment was removed and it had to revert back to it's original state.
It doesn't allow multiple flat surface treatments to occupy the same space, but I don't think there is any real value/point to having multiple surfaces occupy the same surface space as it is.
But it does open up a new way to look at applying surfaces such as redstone dust, carpet, paint (if implemented), snow, etc. This can then be applied to irregular shapes (top of fence posts, half slabs, top of stairs, top of the block underneath a fence post, etc.)
I want fully rotatable blocks too, stained glass, stained wood, npc pathing, writable chat bubbles for making quests in game, music options for default music other than being on a TP, wires, and while we are at it lets put in the ability to make entire selectable builds such as boats or airships to where we can set pathing for them as well. And an engine block or something that lets rotation of block sets attached to it spin (ie propllers, windmills, waterwheels.....get busy programmers and shut up and take my money! I want it!
LOL, I've seen all of those suggestions before.